This patch configures the beacon timers with beacon interval
and beacon period passed through vif.bss_conf. Also cache the
currecnt beacon configuration which will be used to configure
the beacon timers when the driver triggers it after reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Sun, 17 May 2009 09:40:42 +0000 (11:40 +0200)]
mac80211: cancel/restart all timers across suspend/resume
We forgot to cancel all timers in mac80211 when suspending.
In particular we forgot to deal with some things that can
cause hardware reconfiguration -- while it is down.
While at it we go ahead and add a warning in ieee80211_sta_work()
if its run while the suspend->resume cycle is in effect. This
should not happen and if it does it would indicate there is
a bug lurking in either mac80211 or mac80211 drivers.
With this now wpa_supplicant doesn't blink when I go to suspend
and resume where as before there where issues with some timers
running during the suspend->resume cycle. This caused a lot of
incorrect assumptions and would at times bring back the device
in an incoherent, but mostly recoverable, state.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 15 May 2009 09:52:31 +0000 (11:52 +0200)]
mac80211: move channel switch code
The channel switch code is currently in the spectrum
management file, where arguably it belongs. However,
it is for managed mode only and uses the structures
for that mode only so having it in a more generic
file can be confusing. Additionally, my next patch
gets simpler with the code here.
When/if we ever implement this for IBSS or mesh then
we will need to rework the structures it uses anyway
at which point we could move the code back.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Thu, 14 May 2009 18:28:48 +0000 (21:28 +0300)]
ath9k: Fix PS mode operation to receive buffered broadcast/multicast frames
The previous implementation was moving back to NETWORK SLEEP state
immediately after receiving a Beacon frame. This means that we are
unlikely to receive all the buffered broadcast/multicast frames that
would be sent after DTIM Beacon frames. Fix this by parsing the Beacon
frame and remaining awake, if needed, to receive the buffered
broadcast/multicast frames. The last buffered frame will trigger the
move back into NETWORK SLEEP state.
If the last broadcast/multicast frame is not received properly (or if
the AP fails to send it), the next Beacon frame will work as a backup
trigger for returning into NETWORK SLEEP.
A new debug type, PS (debug=0x800 module parameter), is added to make
it easier to debug potential power save issues in the
future. Currently, this is only used for the Beacon frame and buffered
broadcast/multicast receiving.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Thu, 14 May 2009 18:28:47 +0000 (21:28 +0300)]
ath9k: Clean up RX processing a bit
This makes use of the local fc variable in bit more places and uses a
common helper macro. The part of RX process that delivers skb's to
mac80211 is moved to a separate function in preparation for future
changes that will need to do this from two places. The modifications
here should not result in any functional changes.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Thu, 14 May 2009 18:15:36 +0000 (21:15 +0300)]
mac80211: Cancel pending probereq poll on beacon RX
While the probe request poll is expected to work, it looks like it
does not always result in getting a response. The exact reason for
this is unclear, but anyway, if we do receive a Beacon frame from our
AP, there is no need to disconnect based on the probereq poll. This
seems to help keep the connection bit more stable in cases where
beacon loss is occurring semi-frequently.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Gábor Stefanik [Thu, 14 May 2009 17:34:59 +0000 (17:34 +0000)]
zd1211rw: Replace ZD_CS_MULTICAST with ZD_CS_NO_ACK
According to my tests, all that ZD_CS_MULTICAST does is to
disable retrying/waiting for an ACK. Reflect this by renaming
the bit to ZD_CS_NO_ACK and setting it based on
IEEE80211_TX_CTL_NO_ACK, instead of is_multicast_ether_addr.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Initialize RX's last received sequence number
The STA may drop the very first frame if it happens to be a retried
frame. This is because we maintian the last received sequence number
per TID for QoS frames and it is initialized to zero through kzalloc
during sta_info_alloc and the sequence number of the very first date
frame received would be ZERO (as per IEEE 802.11-2007, 7.1.3.4.1).
If the frame dropped happens to be an EAP Request Identity(very first
frame from the AP), then wpa_supplicnat disconnects the STA and the
whole procedure starts again.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
cfg80211: check allowed channel type upon userspace requests
Thanks to nl80211 userspace can be very specific upon device
configuration. Before processing the request for the new HT40
channel types (HT40- or HT40+) we need to ensure we can use them
regulatory-wise. This wasn't required with wireless extensions as
specifying the channel type wasn't not available and configuration
was done towards the end implicitly upon association or reception
of beacons from the AP. For the new nl80211 we have to check this
when configuring the interfaces explicitly.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
cfg80211: Process regulatory max bandwidth checks for HT40
We are not correctly listening to the regulatory max bandwidth
settings. To actually make use of it we need to redesign things
a bit. This patch does the work for that. We do this to so we
can obey to regulatory rules accordingly for use of HT40.
We end up dealing with HT40 by having two passes for each channel.
The first check will see if a 20 MHz channel fits into the channel's
center freq on a given frequency range. We check for a 20 MHz
banwidth channel as that is the maximum an individual channel
will use, at least for now. The first pass will go ahead and
check if the regulatory rule for that given center of frequency
allows 40 MHz bandwidths and we use this to determine whether
or not the channel supports HT40 or not. So to support HT40 you'll
need at a regulatory rule that allows you to use 40 MHz channels
but you're channel must also be enabled and support 20 MHz by itself.
The second pass is done after we do the regulatory checks over
an device's supported channel list. On each channel we'll check
if the control channel and the extension both:
o exist
o are enabled
o regulatory allows 40 MHz bandwidth on its frequency range
This work allows allows us to idependently check for HT40- and
HT40+.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sascha Hlusiak [Tue, 19 May 2009 12:56:52 +0000 (12:56 +0000)]
sit: stateless autoconf for isatap
be sent periodically. The rs_delay can be speficied when adding the
PRL entry and defaults to 15 minutes.
The RS is sent from every link local adress that's assigned to the
tunnel interface. It's directed to the (guessed) linklocal address
of the router and is sent through the tunnel.
Better: send to ff02::2 encapsuled in unicast directed to router-v4.
Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Sascha Hlusiak [Tue, 19 May 2009 12:56:51 +0000 (12:56 +0000)]
addrconf: refuse isatap eui64 for INADDR_ANY
A tunnel with no local ipv4 endpoint would otherwise use the
ISATAP linklocal address fe80::5efe:0:0, which is invalid. Rather not
add a linklocal address at all.
Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Sascha Hlusiak [Tue, 19 May 2009 12:56:48 +0000 (12:56 +0000)]
sit: Fail to create tunnel, if it already exists
When locating the tunnel, do not continue if it is found. Otherwise
a different tunnel with similar configuration would be returned and
parts could be overwritten.
Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Chris Friesen [Tue, 19 May 2009 22:31:50 +0000 (15:31 -0700)]
ipv4: teach ipconfig about the MTU option in DHCP
The DHCP spec allows the server to specify the MTU. This can be useful
for netbooting with UDP-based NFS-root on a network using jumbo frames.
This patch allows the kernel IP autoconfiguration to handle this option
correctly.
It would be possible to use initramfs and add a script to set the MTU,
but that seems like a complicated solution if no initramfs is otherwise
necessary, and would bloat the kernel image more than this code would.
This patch was originally submitted to LKML in 2003 by Hans-Peter Jansen.
Signed-off-by: Chris Friesen <cfriesen@nortel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: use NLMSG_DEFAULT_SIZE in nlmsg_new() allocations
nlmsg_new() adds the size of the netlink header to the value
that has been passed as parameter. If NLMSG_GOODSIZE is selected,
we request an allocation of one memory page plus the size of the
header. Instead, NLMSG_DEFAULT_SIZE should be used since it
already substracts the size of the Netlink header.
I have the impression that the similar naming in both constant
is error prone when using it with nlmsg_new(). This is already
documented in include/net/netlink.h
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 19 May 2009 22:16:34 +0000 (15:16 -0700)]
sch_teql: Use net_device internal stats
We can slightly reduce size of teqlN structure, not duplicating stats
structure in teql_master but using stats field from net_device.stats
for tx_errors and from netdev_queue for tx_bytes/tx_packets/tx_dropped
values.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jesse Brandeburg [Tue, 19 May 2009 09:19:11 +0000 (09:19 +0000)]
ixgbe: Cleanup feature setup code to make the code more readable
This is purely a cleanup patch. This collapses some of the code required
when we configure our Tx and Rx feature sets, and makes the code more
readable and maintainable.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Change Direct Attach Twinax cable detection for SFP+ NICs
The SFF specification for Direct Attach cable detection has now been
ratified. Previously, DA cable detect was looking at the Twinaxial bit in
byte 9 of the SFP+ EEPROM. The spec now defines active and passive DA
cables in byte 8 of the SFP+ EEPROM. This patch changes the cable
detection for both 82598 and 82599 SFP+ adapters to conform to the new
spec.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Add semaphore access for PHY initialization for 82599
The SFP+ NIC (device id 0x10fb) needs a semaphore to serialize
PHY access, so our PHY init code must honor that same semaphore.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
françois romieu [Tue, 19 May 2009 10:46:48 +0000 (10:46 +0000)]
r8169: allow true forced mode setting
Due to mostly historic reasons, including a lack of reliability
of the link handling (especially with the older 8169), the
current r8169 driver emulates forced mode setting by limiting
the advertised modes.
With this change the driver allows real 10/100 forced mode
settings on the 8169 and 8101/8102.
Original idea by Vincent Steenhoute. The RTL_GIGA_MAC_VER_03
tweak was extracted from Realtek's r8169 v6.010.00 driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Jean Delvare <jdelvare@suse.de> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 19 May 2009 05:19:19 +0000 (22:19 -0700)]
net: release dst entry in dev_hard_start_xmit()
One point of contention in high network loads is the dst_release() performed
when a transmited skb is freed. This is because NIC tx completion calls
dev_kree_skb() long after original call to dev_queue_xmit(skb).
CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this is
quite visible if one CPU is 100% handling softirqs for a network device,
since dst_clone() is done by other cpus, involving cache line ping pongs.
It seems right place to release dst is in dev_hard_start_xmit(), for most
devices but ones that are virtual, and some exceptions.
David Miller suggested to define a new device flag, set in alloc_netdev_mq()
(so that most devices set it at init time), and carefuly unset in devices
which dont want a NULL skb->dst in their ndo_start_xmit().
List of devices that must clear this flag is :
- loopback device, because it calls netif_rx() and quoting Patrick :
"ip_route_input() doesn't accept loopback addresses, so loopback packets
already need to have a dst_entry attached."
- appletalk/ipddp.c : needs skb->dst in its xmit function
- And all devices that call again dev_queue_xmit() from their xmit function
(as some classifiers need skb->dst) : bonding, vlan, macvlan, eql, ifb, hdlc_fr
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sysfs files for a network device can not unconditionally take the
rtnl_lock as the bonding sysfs files do. If someone accesses those
sysfs files while the network device is being unregistered with the
rtnl_lock held we will deadlock.
So use trylock and restart_syscall to avoid this problem.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Network device sysfs files that grab the rtnl_lock unconditionally
will deadlock if accessed when the network device is being
unregistered. So use trylock and syscall_restart to avoid this
deadlock.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Holding rtnl_lock when we are unregistering the sysfs files can
deadlock if we unconditionally take rtnl_lock in a sysfs file. So fix
it with the now familiar patter of: rtnl_trylock and syscall_restart()
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
sysctls are unregistered with the rntl_lock held making
it unsafe to unconditionally grab the the rtnl_lock. Instead
we need to call rtnl_trylock and restart the system call
if we can not grab it. Otherwise we could deadlock at unregistration
time.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Just returning -ERESTARTSYS without a signal pending is not
good that will just leak it to userspace. We need return
-ERESTARTNOINTR so we always restart and set signal pending
so that we fall of the fast path of syscall return and setup
the system call restart.
So use restart_syscall() which does all of this for us.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The earlier patch to fix the deadlock between a network device going
away and writing to sysfs attributes was incomplete.
- It did not set signal_pending so we would leak ERSTARTSYS to user space.
- It used ERESTARTSYS which only restarts if sigaction configures it to.
- It did not cover store and show for ifalias.
So fix all of these up and use the new helper restart_syscall so we get
the details correct on what it takes.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
syscall: Implement a convinience function restart_syscall
Currently when we have a signal pending we have the functionality
to restart that the current system call. There are other cases
such as nasty lock ordering issues where it makes sense to have
a simple fix that uses try lock and restarts the system call.
Buying time to figure out how to rework the locking strategy.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johann Baudy [Tue, 19 May 2009 05:11:22 +0000 (22:11 -0700)]
net: TX_RING and packet mmap
New packet socket feature that makes packet socket more efficient for
transmission.
- It reduces number of system call through a PACKET_TX_RING mechanism,
based on PACKET_RX_RING (Circular buffer allocated in kernel space
which is mmapped from user space).
- It minimizes CPU copy using fragmented SKB (almost zero copy).
Signed-off-by: Johann Baudy <johann.baudy@gnu-log.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 19 May 2009 02:26:37 +0000 (19:26 -0700)]
pkt_sched: gen_estimator: use 64 bit intermediate counters for bps
gen_estimator can overflow bps (bytes per second) with Gb links, while
it was designed with a u32 API, with a theorical limit of 34360Mbit
(2^32 bytes)
Using 64 bit intermediate avbps/brate counters can allow us to reach
this theorical limit.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The patch adds support for the PCI cards: PCIcan and PCIcanx (1, 2 or 4 channel) from Kvaser (http://www.kvaser.com).
Signed-off-by: Per Dalen <per.dalen@cnw.se> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The patch adds support for the one or two channel CPC-PCI and CPC-PCIe
cards from EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
Signed-off-by: Sebastian Haas <haas@ems-wuensche.com> Signed-off-by: Markus Plessing <plessing@ems-wuensche.com> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This driver adds support for the SJA1000 chips connected to the
"platform bus", which can be found on various embedded systems.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the generic Socket-CAN driver for the Philips SJA1000
full CAN controller.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
can: CAN Network device driver and Netlink interface
The CAN network device driver interface provides a generic interface to
setup, configure and monitor CAN network devices. It exports a set of
common data structures and functions, which all real CAN network device
drivers should use. Please have a look to the SJA1000 or MSCAN driver
to understand how to use them. The name of the module is can-dev.ko.
Furthermore, it adds a Netlink interface allowing to configure the CAN
device using the program "ip" from the iproute2 utility suite.
For further information please check "Documentation/networking/can.txt"
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
can: Documentation for the CAN device driver interface
This patch documents the CAN netowrk device drivers interface, removes
obsolete documentation and adds some useful links to CAN resources.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Anant Gole [Mon, 18 May 2009 22:19:01 +0000 (15:19 -0700)]
net: Add TI DaVinci EMAC driver
Add support for TI DaVinci EMAC driver.
TI DaVinci Ethernet Media Access Controller module is based upon
TI CPPI 3.0 DMA engine and supports 10/100 Mbps on all and Gigabit modes on
some TI devices. It supports MII/RMII and has up to 8Kbytes of internal
descriptor memory. This driver has been working on several TI devices including
DM644x, DM646x and DA830 platforms. The specs of this device are available at:
http://www.ti.com/litv/pdf/sprue24a
Signed-off-by: Anant Gole <anantgole@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Network drivers that touch dev->stats.tx_packets/stats.tx_bytes in their
tx path can slow down SMP operations, since they dirty a cache line
that should stay shared (dev->features is needed in rx and tx paths)
We could move away stats field in net_device but it wont help that much.
(Two cache lines dirtied in tx path, we can do one only)
Better solution is to add tx_packets/tx_bytes/tx_dropped in struct
netdev_queue because this structure is already touched in tx path and
counters updates will then be free (no increase in size)
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Marching along, let's bump the version number to indicate things actually
have happened to the driver.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the generic XAUI device support for 82599 controllers.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Sun, 17 May 2009 20:57:47 +0000 (20:57 +0000)]
ixgbe: set max desc to prevent total RSC packet size of 64K
The performance of hardware RSC is greatly reduced if the total for max rsc
descriptors multiplied by the buffer size is greater than 65535. To
prevent this we need to adjust the max rsc descriptors appropriately.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 10 May 2009 20:32:34 +0000 (20:32 +0000)]
tcp: fix MSG_PEEK race check
Commit 518a09ef11 (tcp: Fix recvmsg MSG_PEEK influence of
blocking behavior) lets the loop run longer than the race check
did previously expect, so we need to be more careful with this
check and consider the work we have been doing.
I tried my best to deal with urg hole madness too which happens
here:
if (!sock_flag(sk, SOCK_URGINLINE)) {
++*seq;
...
by using additional offset by one but I certainly have very
little interest in testing that part.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Tested-by: Frans Pop <elendil@planet.nl> Tested-by: Ian Zimmermann <itz@buug.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Gabriel Paubert [Mon, 18 May 2009 04:16:47 +0000 (21:16 -0700)]
mv643xx_eth: fix PPC DMA breakage
After 2.6.29, PPC no more admits passing NULL to the dev parameter of
the DMA API. The result is a BUG followed by solid lock-up when the
mv643xx_eth driver brings an interface up. The following patch makes
the driver work on my Pegasos again; it is mostly a search and replace
of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
functions.
Signed-off-by: Gabriel Paubert <paubert@iram.es> Acked-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
One of the purposes of bonding is to allow for redundant links, and failover
correctly if the cable is pulled. If all the members of a bonded device have
no carrier present, the bonded device itself needs to report no carrier present
to user space so management tools (like routing daemons) can respond.
Bonding in 802.3ad mode does not work correctly for this because it incorrectly
chooses a link that is down as a possible aggregator.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
If bridge is configured with no STP and forwarding delay of 0 (which
is typical for virtualization) then when link starts it will flood all
packets for the first 20 seconds.
This bug was introduced by a combination of earlier changes:
* forwarding database uses hold time of zero to indicate
user wants to always flood packets
* optimzation of the case of forwarding delay of 0 avoids the initial
timer tick
The fix is to just skip all the topology change detection code if
kernel STP is not being used.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Currently the bridge catches all STP packets; even if STP is turned
off. This prevents other systems (which do have STP turned on)
from being able to detect loops in the network.
With this patch, if STP is off, then any packet sent to the STP
multicast group address is forwarded to all ports.
Based on earlier patch by Joakim Tjernlund with changes
to go through forwarding (not local chain), and optimization
that only last octet needs to be checked.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ralf Baechle [Sat, 16 May 2009 01:21:58 +0000 (01:21 +0000)]
NET: Meth: Fix unsafe mix of irq and non-irq spinlocks.
Mixing of normal and irq spinlocks results in the following lockdep messages
on bootup on IP32:
[...]
Sending DHCP requests .
======================================================
[ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] 2.6.30-rc5-00164-g41baeef #30
------------------------------------------------------
swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire:
(&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c
and this task is already holding:
(_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
which would create a new lock dependency:
(_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...}
Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Tested-by: Andrew Randrianasulu <randrik_a@yahoo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Don't reset the hardware when switching between LFC and PFC
When running in DCB mode, switching between link flow control and priority
flow control shouldn't need to reset the hardware. This removes that
reset.
This also extends the set_all() dcbnl callback to return a value indicating
that the HW config changed, however a reset was not required.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: When in DCB mode with PFC enabled, show LFC is disabled
Ethtool should report that link flow control is disabled when in priority
flow control mode.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Allow link flow control in DCB mode for 82599 adapters
82599 supports using either link flow control or priority flow control when
in DCB mode. The dcbnl interface already supports sending down
configurations through rtnetlink that can enable LFC when DCB is enabled,
so the driver should take advantage of this.
82598 does not support using LFC when DCB is enabled, so explicitly disable
it when we're in DCB mode. This means we always run in PFC mode when DCB
is enabled.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Set Priority Flow Control low water threshhold for DCB
This sets the low water threshhold for priority flow control for 82598
and 82599 controllers in DCB mode.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Yi Zou [Sun, 17 May 2009 12:34:35 +0000 (12:34 +0000)]
ixgbe: Enable jumbo frame for FCoE feature in 82599
Enable jumbo frame when FCoE feature is enabled in 82599. Use 3K
as the receive queue buffer size for receive queues used by FCoE
to address for max Fiber Channel frame size as 2148 bytes (with
max 2112 bytes of payload).
Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Yi Zou [Sun, 17 May 2009 12:34:14 +0000 (12:34 +0000)]
ixgbe: Enable FCoE redirection table feature in 82599
Enable using FCoE redirection table feature in 82599. The FCoE
redirection table has maximum of eight entries, corresponding
to maximum of eight receive queues to be used for distributing
incoming FCoE packets. This patch sets up the FCoE redirection
table when multiple receive queues are available for FCoE.
Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Yi Zou [Sun, 17 May 2009 12:33:52 +0000 (12:33 +0000)]
ixgbe: Add RING_F_FCOE for FCoE feature in 82599
Add ring feature for FCoE to make use of the FCoE redirection
table in 82599. The FCoE redirection table is a receive side
scaling feature for Fiber Channel over Ethernet feature in 82599,
enabling distributing FCoE packets to different receive queues
based on the exchange id.
Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vasu Dev [Sun, 17 May 2009 12:33:28 +0000 (12:33 +0000)]
fcoe: adds spma mode support
If we can find a type NETDEV_HW_ADDR_T_SAN mac address from the
corresponding netdev for a fcoe interface then sets up added the
fc->ctlr.spma flag and stores spma mode address in ctl_src_addr.
In case the spma flag is set then:-
1. Adds spma mode MAC address in ctl_src_addr as secondary
MAC address, the FLOGI for FIP and pre-FIP will go out
using this address.
2. Cleans up stored spma MAC address in ctl_src_addr in
fcoe_netdev_cleanup.
3. Sets up spma bit in fip_flags for FIP solicitations along
with exiting FPMA bit setting.
4. Initialize the FLOGI FIP MAC descriptor to stored spma
MAC address in ctl_src_addr. This is used as proposed
FCoE MAC address from initiator along with both SPMA
and FPMA bit set in FIP solicitation, in response the
switch may grant any FPMA or SPMA mode MAC address to
initiator.
Removes FIP descriptor type checking against ELS type
ELS_FLOGI in fcoe_ctlr_encaps to update a FIP MAC descriptor,
instead now checks against FIP_DT_FLOGI.
I've tested this with available FPMA-only FCoE switch but
since data_src_addr is updated using same old code for
both FPMA and SPMA modes with FIP or pre-FIP links, so added
SPMA mode will work with SPMA-only switch also provided that
switch grants a valid MAC address.
Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vasu Dev [Sun, 17 May 2009 12:33:08 +0000 (12:33 +0000)]
fcoe: consolidates netdev related config and cleanup for spma mode
Currently fcoe_netdev_config adds netdev pkt handler for fcoe pkts,
fcoe_if_create adds netdev pkt handler for fip packets, a secondary
MAC address is added by fcoe_netdev_config and then later cleanup
for these netdev related config/adds is done only during
fcoe_if_destroy and no cleanup done on error during fcoe interface
creation after above netdev config calling in fcoe_if_create.
So this patch adds single func for above mentioned cleanup the
fcoe_netdev_cleanup and then calls this func on either fcoe interface
destroy or exiting from fcoe_if_create due to an error after fcoe/fip
related above netdev config is done.
Moved netdev pkt handler addition code blocks for fip pkts close to
similar code block for foce pkt in fcoe_netdev_config, so that added
fcoe_netdev_cleanup could be called on error from fcoe_netdev_config
to undo these both additions for fcoe/fip pkt handlers. This move
required reference to fcoe_fip_recv in fcoe_netdev_config, so moved
fip related functions fcoe_fip_recv, fcoe_fip_send and
fcoe_update_src_mac above fcoe_netdev_config.
This consolidation will enable spma mode support in next patch to
easily add or delete spma mode mac address beside fixing current
no cleanup issue during error.
Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Add SAN MAC address to the RAR, return the address to DCB
After acquiring the SAN MAC address from the EEPROM, we need to program it
into one of the RARs. Also, DCB will use this MAC address to run DCBX
commands, so it doesn't have to play musical MAC addresses when things like
bonding enter the picture. So we need to return the MAC address through
the netlink interface to userspace.
This also moves the init_rx_addrs() call out of start_hw() and into
reset_hw(). We shouldn't try to read any of the RAR information before
initializing our internal accounting of the RAR table, which was what
was happening.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
PJ Waskiewicz [Sun, 17 May 2009 12:32:25 +0000 (12:32 +0000)]
ixgbe: Add FCoE Storage MAC Address support
This patch implements the Storage Address entrypoint from the net device.
It will read the SAN MAC addresses from the EEPROM of the 82599 hardware,
and make them available to the FCoE stack through the net device.
Also, add/del the SAN MAC address to the netdev dev_addr_list via the
kernel api dev_addr_add()/dev_addr_del() when there is a valid SAN MAC
supported by the HW.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Peter Korsgaard [Wed, 13 May 2009 10:10:41 +0000 (10:10 +0000)]
smsc95xx: strip ethernet fcs (crc) on receive path
The smsc95xx driver was forwarding the trailing fcs on received frames
up the stack leading to confusion in tcpdump.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Tested-by: Steve Glendinning <steve.glendinning@smsc.com> Acked-by: Steve Glendinning <steve.glendinning@smsc.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Mon, 18 May 2009 03:55:16 +0000 (20:55 -0700)]
net: tx scalability works : trans_start
struct net_device trans_start field is a hot spot on SMP and high performance
devices, particularly multi queues ones, because every transmitter dirties
it. Is main use is tx watchdog and bonding alive checks.
But as most devices dont use NETIF_F_LLTX, we have to lock
a netdev_queue before calling their ndo_start_xmit(). So it makes
sense to move trans_start from net_device to netdev_queue. Its update
will occur on a already present (and in exclusive state) cache line, for
free.
We can do this transition smoothly. An old driver continue to
update dev->trans_start, while an updated one updates txq->trans_start.
Further patches could also put tx_bytes/tx_packets counters in
netdev_queue to avoid dirtying dev->stats (vlan device comes to mind)
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Tilman Schmidt [Wed, 13 May 2009 12:44:18 +0000 (12:44 +0000)]
gigaset: remove UNDOCREQ config option
Drop the kernel config option GIGASET_UNDOCREQ, permanently
activating the code it controlled, as there have been no reports
of problems caused by its activation but many problems caused by
it being disabled.
Also fix a few bad comments while we're at it.
Impact: cleanup Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
Tilman Schmidt [Wed, 13 May 2009 12:44:18 +0000 (12:44 +0000)]
gigaset: move up Kconfig inclusion point
In preparation for porting to kernel CAPI subsystem, include the
Gigaset driver's Kconfig directly from ISDN's instead of I4L's.
Impact: Kconfig reorganisation, no functional change Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux-beck.git / log