iwlwifi: drop iwl3945_tid_data

This patch is one of the incremental steps for unifying iwl_station_entry
for all HWs, i.e. removing of iwl3945_station_entry
This patch drops iwl3945_tid_data and use iwl_tid_data instead.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: drop struct iwl3945_hw_key

This patch replaces struct iwl3945_hw_key by struct iwl_hw_key.
It's not used directly with any host command therefore removal is trivial

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43legacy: Remove unnecessary MMIO in interrupt hotpath

This removes unnecessary MMIO accesses in the interrupt hotpath. The
patch by Michael Buesch for b43 has been ported to b43legacy.

Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: cleanup beacon parameters configuration

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>

ath9k: Remove unused parameters which are passed to ath_beacon_config_X()

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Print hw reset failure status as signed int

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

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>

nl80211: Validate NL80211_ATTR_KEY_SEQ length

Validate RSC (NL80211_ATTR_KEY_SEQ) length in nl80211/cfg80211 instead
of having to do this in all the drivers.

Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

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>

ath9k: Fix a check for multicast address for virtual wiphy

The broadcast bit is in the first, not the last octet..

Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

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: add debugfs HT40 allow map

Here's a screenshot of what this looks like with ath9k:

mcgrof@pogo /debug/ieee80211/phy0 $ cat ht40allow_map
2412 HT40  +
2417 HT40  +
2422 HT40  +
2427 HT40  +
2432 HT40 -+
2437 HT40 -+
2442 HT40 -+
2447 HT40 -
2452 HT40 -
2457 HT40 -
2462 HT40 -
2467 Disabled
2472 Disabled
2484 Disabled
5180 HT40  +
5200 HT40 -+
5220 HT40 -+
5240 HT40 -+
5260 HT40 -+
5280 HT40 -+
5300 HT40 -+
5320 HT40 -
5500 HT40  +
5520 HT40 -+
5540 HT40 -+
5560 HT40 -+
5580 HT40 -+
5600 HT40 -+
5620 HT40 -+
5640 HT40 -+
5660 HT40 -+
5680 HT40 -+
5700 HT40 -
5745 HT40  +
5765 HT40 -+
5785 HT40 -+
5805 HT40 -+
5825 HT40 -

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211/cfg80211: move wiphy specific debugfs entries to cfg80211

This moves the cfg80211 specific stuff to new cfg80211 debugfs
entries. Non-mac80211 will also get these entries now. There were
only 4 which we take:

rts_threshold
fragmentation_threshold
short_retry_limit
long_retry_limit

Signed-off-by: Luis R. Rodriguez <lrodriguez@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>

mac80211: check if HT40+/- is allowed before sending assoc

We weren't checking this at all.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

wireless: rename IEEE80211_CHAN_NO_FAT_* to HT40-/+

This is more consistent with our nl80211 naming convention
for HT40-/+.

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>

sfc: Remove lro module parameter

GRO/LRO can be controlled through ethtool so this is unnecessary.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

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>

sit: ipip6_tunnel_del_prl: return err

Typo. When deleting a PRL entry, return status to userspace
instead of success.

Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

sit: strictly restrict incoming traffic to tunnel link device

Check link device when looking up a tunnel. When a tunnel is
linked to a interface, traffic from a different interface must not
reach the tunnel.

This also allows creating of multiple tunnels with the same
endpoints, if the link device differs.

Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

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>

myri10ge: update version to 1.5.0-1.415

Update myri10ge driver version to 1.5.0-1.415.

Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

myri10ge: allow LRO to be enabled via ethtool

Allow myri10ge LRO to be enabled/disabled via ethtool
(and by the stack for packet forwarding).

Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

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>

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>

r8169: remove useless struct member

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: David S. Miller <davem@davemloft.net>

ppp: unset IFF_XMIT_DST_RELEASE in ppp_setup()

Jarek pointed pppoe can call back dev_queue_xmit(), and might need
skb->dst, so its safer to unset IFF_XMIT_DST_RELEASE on ppp devices.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

net: FIX bonding sysfs rtnl_lock deadlock

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>

net: Fix ipoib rtnl_lock sysfs deadlock.

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>

net: Fix bridgeing sysfs handling of rtnl_lock

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>

net: Fix devinet_sysctl_forward

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>

net: FIX ipv6_forward sysctl restart

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>

net-sysfs: Use rtnl_trylock in sysfs methods.

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>

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>

netxen: fix msi irq setup

The pdev->irq was not saved in netxen_adapter, causing request_irq()
with invalid irq number.

This was broken in commit be339aee634d5cb98a8df8d6febe04002ec497f3
("netxen: fix irq tear down and msix leak.").

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of /linux/kernel/git/davem/net-2.6

Conflicts:
drivers/scsi/fcoe/fcoe.c

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 (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>

can: SJA1000 driver for EMS PCI cards

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>

can: SJA1000 generic platform bus driver

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>

can: Driver for the SJA1000 CAN controller

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: Update MAINTAINERS and CREDITS file

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
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>

be2net: add two new pci device ids to pci device table

Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

ipv4: cleanup: remove unnecessary include.

There is no need for net/icmp.h header in net/ipv4/fib_frontend.c.
This patch removes the #include net/icmp.h from it.

Signed-off-by: Rami Rosen <ramirose@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv4: cleanup - remove two unused parameters from fib_semantic_match().

Signed-off-by: Rami Rosen <ramirose@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

vlan: use struct netdev_queue counters instead of dev->stats

We can update netdev_queue tx_bytes/tx_packets/tx_dropped counters instead
of dev->stats ones, to reduce number of cache lines dirtied in xmit path.

This fixes a performance problem on SMP when many different cpus take
vlan tx path.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: add tx_packets/tx_bytes/tx_dropped counters in struct netdev_queue

offsetof(struct net_device, features)=0x44
offsetof(struct net_device, stats.tx_packets)=0x54
offsetof(struct net_device, stats.tx_bytes)=0x5c
offsetof(struct net_device, stats.tx_dropped)=0x6c

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>

sch_teql: should not dereference skb after ndo_start_xmit()

It is illegal to dereference a skb after a successful ndo_start_xmit()
call. We must store skb length in a local variable instead.

Bug was introduced in 2.6.27 by commit 0abf77e55a2459aa9905be4b226e4729d5b4f0cb
(net_sched: Add accessor function for packet length for qdiscs)

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ixgbe: Increase the driver version number

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>

ixgbe: Add generic XAUI support to 82599

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>

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>

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>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-next-2.6

Doc: fixed descriptions on /proc/sys/net/core/* and /proc/sys/net/unix/*

Signed-off-by: Wang Tinggong <wangtinggong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR?

FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Ram Vepa <ram.vepa@neterion.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

bonding: fix link down handling in 802.3ad mode

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>

Merge branch 'linux-2.6.30.y' of git://git./linux/kernel/git/inaky/wimax

bridge: fix initial packet flood if !STP

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>

bridge: relay bridge multicast pkgs if !STP

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>

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){+.+...}

but this new dependency connects a SOFTIRQ-irq-safe lock:
 (_xmit_ETHER#2){+.-...}
... which became SOFTIRQ-irq-safe at:
  [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
  [<ffffffff800627e0>] lock_acquire+0xf8/0x150
  [<ffffffff800128d0>] _spin_lock+0x30/0x44
  [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
  [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
  [<ffffffff8003da5c>] __do_softirq+0xec/0x208
  [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
  [<ffffffff8003dda0>] irq_exit+0x54/0x9c
  [<ffffffff80004420>] ret_from_irq+0x0/0x4
  [<ffffffff80004720>] r4k_wait+0x20/0x40
  [<ffffffff80015418>] cpu_idle+0x30/0x60
  [<ffffffff804cd934>] start_kernel+0x3ec/0x404

to a SOFTIRQ-irq-unsafe lock:
 (&priv->meth_lock){+.+...}
... which became SOFTIRQ-irq-unsafe at:
...  [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
  [<ffffffff800627e0>] lock_acquire+0xf8/0x150
  [<ffffffff800128d0>] _spin_lock+0x30/0x44
  [<ffffffff80263f20>] meth_reset+0x118/0x2d8
  [<ffffffff8026424c>] meth_open+0x28/0x140
  [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
  [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
  [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
  [<ffffffff80012e68>] do_one_initcall+0x58/0x170
  [<ffffffff804cd190>] kernel_init+0x98/0x104
  [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18

other info that might help us debug this:

2 locks held by swapper/1:
 #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0
 #1:  (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c

the SOFTIRQ-irq-safe lock's dependencies:
-> (_xmit_ETHER#2){+.-...} ops: 0 {
   HARDIRQ-ON-W at:
                        [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                        [<ffffffff800128d0>] _spin_lock+0x30/0x44
                        [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                        [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                        [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                        [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                        [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                        [<ffffffff80004420>] ret_from_irq+0x0/0x4
                        [<ffffffff80004720>] r4k_wait+0x20/0x40
                        [<ffffffff80015418>] cpu_idle+0x30/0x60
                        [<ffffffff804cd934>] start_kernel+0x3ec/0x404
   IN-SOFTIRQ-W at:
                        [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
                        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                        [<ffffffff800128d0>] _spin_lock+0x30/0x44
                        [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                        [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                        [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                        [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                        [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                        [<ffffffff80004420>] ret_from_irq+0x0/0x4
                        [<ffffffff80004720>] r4k_wait+0x20/0x40
                        [<ffffffff80015418>] cpu_idle+0x30/0x60
                        [<ffffffff804cd934>] start_kernel+0x3ec/0x404
   INITIAL USE at:
                       [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                       [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                       [<ffffffff800128d0>] _spin_lock+0x30/0x44
                       [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                       [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                       [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                       [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                       [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                       [<ffffffff80004420>] ret_from_irq+0x0/0x4
                       [<ffffffff80004720>] r4k_wait+0x20/0x40
                       [<ffffffff80015418>] cpu_idle+0x30/0x60
                       [<ffffffff804cd934>] start_kernel+0x3ec/0x404
 }
 ... key      at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8

the SOFTIRQ-irq-unsafe lock's dependencies:
-> (&priv->meth_lock){+.+...} ops: 0 {
   HARDIRQ-ON-W at:
                        [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                        [<ffffffff800128d0>] _spin_lock+0x30/0x44
                        [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                        [<ffffffff8026424c>] meth_open+0x28/0x140
                        [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                        [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                        [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                        [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                        [<ffffffff804cd190>] kernel_init+0x98/0x104
                        [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
   SOFTIRQ-ON-W at:
                        [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
                        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                        [<ffffffff800128d0>] _spin_lock+0x30/0x44
                        [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                        [<ffffffff8026424c>] meth_open+0x28/0x140
                        [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                        [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                        [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                        [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                        [<ffffffff804cd190>] kernel_init+0x98/0x104
                        [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
   INITIAL USE at:
                       [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                       [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                       [<ffffffff800128d0>] _spin_lock+0x30/0x44
                       [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                       [<ffffffff8026424c>] meth_open+0x28/0x140
                       [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                       [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                       [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                       [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                       [<ffffffff804cd190>] kernel_init+0x98/0x104
                       [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
 }
 ... key      at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8

stack backtrace:
Call Trace:
[<ffffffff8000ed0c>] dump_stack+0x8/0x34
[<ffffffff80060b74>] check_usage+0x470/0x4a0
[<ffffffff80060c34>] check_irq_usage+0x90/0x130
[<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84
[<ffffffff8026388c>] meth_tx+0x48/0x43c
[<ffffffff802d3a38>] __qdisc_run+0x150/0x30c
[<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0
[<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28
[<ffffffff80012e68>] do_one_initcall+0x58/0x170
[<ffffffff804cd190>] kernel_init+0x98/0x104
[<ffffffff8001520c>] kernel_thread_helper+0x10/0x18

..... timed out!
IP-Config: Retrying forever (NFS root)...
Sending DHCP requests ., OK
[...]

Fixed by converting all locks to irq locks.

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>

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>

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>

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>

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>

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>

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>

skfddi: convert PRINTK() to pr_debug()

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mac89x0: remove PRINTK()

There are no users of it.

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

de620: convert PRINTK() to pr_debug() and cleanup

Also remove DE620_DEBUG and de620_debug.

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

de600: convert PRINTK() to pr_debug()

Also remove de600_debug as it is not needed.

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

de620: fix forgotten semicolon

It seems it always was here.

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

drivers/net: Convert #ifdef DEBUG printk(KERN_DEBUG to pr_debug(

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sfc: Use generic XENPAK register definitions

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mdio: Add XENPAK LASI register definitions

These registers were originally defined for XENPAK modules, but are
also implemented by many other 10G PHYs.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mdio: Add 10GBASE-T SNR register definition

These do not have an in-kernel user but may be useful to user-space.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>

dm9601: trivial comment fixes

The comments describing the rx/tx headers used a combination of zero-
and 1-based indexing, leading to confusion.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

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>