This patch introduces the parity errors handling code for 57710 and 57711 chips.

HW is configured to stop all DMA transactions to the host and sending packets to the network
once parity error is detected, which is meant to prevent silent data corruption.
At the same time HW generates the attention interrupt to every function of the device where parity
has been detected so that driver can start the recovery flow.

The recovery is actually resetting the chip and restarting the driver on all active functions
of the chip where the parity error has been reported.
Signed-off-by: NVladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ixgbe driver was setting up 82598 hardware correctly, so that
when promiscuous mode was enabled hardware stripping was turned
off.  But on 82599 the logic to disable/enable hardware stripping
is different, and the code was not updated correctly when the
hardware vlan stripping was enabled as default.

This change comprises the creation of two new helper functions
and calling them from the right locations to disable and enable
hardware stripping of vlan tags at appropriate times.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb)
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A very useful information was provided by Sitecom R&D guys:

Please find the information regarding our latest Ralink adapters below;

WL-302    -    VID: 0x0DF6,    PID: 0x002D    -    Ralink RT2771
WL-315    -    VID: 0x0DF6,    PID: 0x0039    -    Ralink RT2770
WL-319    -    VID: 0x182D,    PID: 0x0037    -    Ralink RT2860
WL-321    -    VID: 0x0DF6,    PID: 0x003B    -    Ralink RT2770
WL-324    -    VID: 0x0DF6,    PID: 0x003D    -    Ralink RT2870
WL-329    -    VID: 0x0DF6,    PID: 0x0041    -    Ralink RT3572
WL-343    -    VID: 0x0DF6,    PID: 0x003E    -    Ralink RT3070
WL-344    -    VID: 0x0DF6,    PID: 0x0040    -    Ralink RT3071
WL-345    -    VID: 0x0DF6,    PID: 0x0042    -    Ralink RT3072
WL-608    -    VID: 0x0DF6,    PID: 0x003F    -    Ralink RT2070

Note:
PID: 0x003C, 0x004A, and 0x004D:   --these products do not exist; devices were never produced/shipped--

The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds the following 5 entries to the usbid device table:

 * Netgear WNA1000
 * Proxim ORiNOCO Dual Band 802.11n USB Adapter
 * 3Com Dual Band 802.11n USB Adapter
 * H3C Dual Band 802.11n USB Adapter
 * WNC Generic 11n USB dongle

CC: <stable@kernel.org>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If EEPROM is used, NVS data is now loaded but ignored.
Stop loading it to avoid need of dummy NVS file for modules with EEPROM.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Acked-by: NKalle Valo <kvalo@adurom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes two warnings below after unplugging ar9271 usb device:
	-one is a kernel warning[1]
	-another is a lockdep warning[2]

The root reason is that __skb_queue_purge can't be executed in hardirq
context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge),
which frees skb with dev_kfree_skb_any which can be run in hardirq
context safely, then prevent the lockdep warning and kernel warning after
unplugging ar9271 usb device.

[1] kernel warning
[  602.894005] ------------[ cut here ]------------
[  602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87()
[  602.894005] Hardware name: 6475EK2
[  602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath]
[  602.894005] Pid: 2506, comm: ping Tainted: G        W  2.6.34-rc3-wl #20
[  602.894005] Call Trace:
[  602.894005]  <IRQ>  [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94
[  602.894005]  [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc]
[  602.894005]  [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16
[  602.894005]  [<ffffffff813269c1>] skb_release_head_state+0x71/0x87
[  602.894005]  [<ffffffff8132829a>] __kfree_skb+0x16/0x81
[  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
[  602.894005]  [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc]
[  602.894005]  [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc]
[  602.894005]  [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc]
[  602.894005]  [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
[  602.894005]  [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
[  602.894005]  [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
[  602.894005]  [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
[  602.894005]  [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd]
[  602.894005]  [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
[  602.894005]  [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df
[  602.894005]  [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2
[  602.894005]  [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
[  602.894005]  [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
[  602.894005]  [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce
[  602.894005]  [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
[  602.894005]  [<ffffffff8100c4fb>] handle_irq+0x88/0x91
[  602.894005]  [<ffffffff8100baed>] do_IRQ+0x63/0xc9
[  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
[  602.894005]  [<ffffffff813ba993>] ret_from_intr+0x0/0x16
[  602.894005]  <EOI>  [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1
[  602.894005]  [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e
[  602.894005]  [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e
[  602.894005]  [<ffffffff811095fe>] __delete_object+0x5a/0xb1
[  602.894005]  [<ffffffff81109814>] delete_object_full+0x25/0x31
[  602.894005]  [<ffffffff813a60c0>] kmemleak_free+0x26/0x45
[  602.894005]  [<ffffffff810ff517>] kfree+0xaa/0x149
[  602.894005]  [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89
[  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
[  602.894005]  [<ffffffff813285ce>] skb_release_data+0xc9/0xce
[  602.894005]  [<ffffffff813282a2>] __kfree_skb+0x1e/0x81
[  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
[  602.894005]  [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c
[  602.894005]  [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709
[  602.894005]  [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d
[  602.894005]  [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf
[  602.894005]  [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9
[  602.894005]  [<ffffffff810e13b4>] ? might_fault+0x68/0xb8
[  602.894005]  [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8
[  602.894005]  [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31
[  602.894005]  [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91
[  602.894005]  [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241
[  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
[  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
[  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
[  602.894005]  [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63
[  602.894005]  [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9
[  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
[  602.894005]  [<ffffffff810357fe>] ? need_resched+0x23/0x2d
[  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
[  602.894005]  [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  602.894005]  [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
[  602.894005] ---[ end trace 91ba2d8dc7826839 ]---

[2] lockdep warning
[  169.363215] ======================================================
[  169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[  169.366334] 2.6.34-rc3-wl #20
[  169.366872] ------------------------------------------------------
[  169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[  169.366872]  (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89
[  169.366872]
[  169.366872] and this task is already holding:
[  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc]
[  169.366872] which would create a new lock dependency:
[  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..}
[  169.366872]
[  169.366872] but this new dependency connects a HARDIRQ-irq-safe lock:
[  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}
[  169.366872] ... which became HARDIRQ-irq-safe at:
[  169.366872]   [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b
[  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
[  169.366872]   [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73
[  169.366872]   [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc]
[  169.366872]   [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
[  169.366872]   [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
[  169.366872]   [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
[  169.366872]   [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
[  169.366872]   [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
[  169.366872]   [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
[  169.366872]   [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
[  169.366872]   [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
[  169.366872]   [<ffffffff8100c4fb>] handle_irq+0x88/0x91
[  169.366872]   [<ffffffff8100baed>] do_IRQ+0x63/0xc9
[  169.366872]   [<ffffffff813ba993>] ret_from_intr+0x0/0x16
[  169.366872]   [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115
[  169.366872]   [<ffffffff81008c4f>] cpu_idle+0x68/0xc4
[  169.366872]   [<ffffffff813a41e0>] rest_init+0x104/0x10b
[  169.366872]   [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc
[  169.366872]   [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7
[  169.366872]   [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107
[  169.366872]
[  169.366872] to a HARDIRQ-irq-unsafe lock:
[  169.366872]  (clock-AF_INET){++.?..}
[  169.366872] ... which became HARDIRQ-irq-unsafe at:
[  169.366872] ...  [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b
[  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
[  169.366872]   [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a
[  169.366872]   [<ffffffff8135cf14>] tcp_close+0x165/0x34d
[  169.366872]   [<ffffffff8137aced>] inet_release+0x55/0x5c
[  169.366872]   [<ffffffff81321350>] sock_release+0x1f/0x6e
[  169.366872]   [<ffffffff813213c6>] sock_close+0x27/0x2b
[  169.366872]   [<ffffffff8110dd45>] __fput+0x125/0x1ca
[  169.366872]   [<ffffffff8110de04>] fput+0x1a/0x1c
[  169.366872]   [<ffffffff8110adc9>] filp_close+0x68/0x72
[  169.366872]   [<ffffffff8110ae80>] sys_close+0xad/0xe7
[  169.366872]   [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b

(Trimmed at the "other info that might help us debug this" line in
the interest of brevity... -- JWL)
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In ath9k-htc register out path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.

This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In ath9k-htc register in path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.

This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.

This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We get RXORN interrupts when all receive buffers are full. This is not
necessarily a fatal situation. It can also happen when the bus is busy or the
CPU is not fast enough to process all frames.

Older chipsets apparently need a reset to come out of this situration, but on
newer chips we can treat RXORN like RX, as going thru a full reset does more
harm than good, there.

The exact chip revisions which need a reset are unknown - this guess
AR5K_SREV_AR5212 ("venice") is copied from the HAL.

Inspired by openwrt 413-rxorn.patch:
"treat rxorn like rx, reset after rxorn seems to do more harm than good"
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways. Cleared the
confusion and added some documentation.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pointed out by Stephen Rothwell.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed. This happens because
tun/tap devices can hang on to skbs undefinitely.

As noted by Herbert, possible solutions include a timeout followed by a
copy/change of ownership of the skb, or always copying/changing
ownership if we're going into a hostile device.

This patch implements the second approach.

Note: one issue still remaining is that since skbs
keep reference to tun socket and tun socket has a
reference to tun device, we won't flush backlog,
instead simply waiting for all skbs to get transmitted.
At least this is not user-triggerable, and
this was not reported in practice, my assumption is
other devices besides tap complete an skb
within finite time after it has been queued.

A possible solution for the second issue
would not to have socket reference the device,
instead, implement dev->destructor for tun, and
wait for all skbs to complete there, but this
needs some thought, probably too risky for 2.6.34.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NYan Vugenfirer <yvugenfi@redhat.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Moved STMMAC_VLAN_TAG_USED from stmmac.h to common.h header
because it is used within the device and descriptor cores.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Output for chip that uses the Enhanced descriptors:
[snip]
STMMAC driver:
	platform registration... done!
	DWMAC1000 - user ID: 0x10, Synopsys ID: 0x33
	Enhanced descriptor structure
	no valid MAC address;please, use ifconfig or nwhwconfig!
	eth0 - (dev. name: stmmaceth - id: 0, IRQ #134
	IO base addr: 0xfd110000)
STMMAC MII Bus: probed
[snip]
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix the Transmit FIFO flush operation; it was
disabled while reworking the descriptor structures.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently the driver assumes that the mac10/100 can only use the
normal descriptor structure and the gmac can only use the
enhanced structures.
This patch removes the descriptor's code from the dma files
and adds two new files just for handling the normal and enhanced
descriptors.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The patch splits core and dma parts for the mac10/100 device.
This was already done for the GMAC device.
It should make more flexible the driver to support other chips.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is a fix for bug 572201 @ bugs.debian.org

This patch fixes the TX_LIMIT feature flag. The previous logic check
for TX_LIMIT2 also took into account a device that only had TX_LIMIT
set.
Reported-by: NStephen Mulcahu <stephen.mulcahy@deri.org>
Reported-by: NBen Huchings <ben@decadent.org.uk>
Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The promiscous cmd config code gives an impression that
setting a port to promisc mode will unset the other port.
This is not the case and is clarified with a comment.
Signed-off-by: NSathya Perla <sathyap@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Network drivers do not have to update last_rx, unless they need it for
their private use.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the current implementation, CAN drivers need to #include <linux/can.h>
_before_ they #include <linux/can/dev.h>, which is both ugly and
unnecessary.

Fix this by including <linux/can.h> in <linux/can/dev.h> and remove the
#include <linux/can.h> lines from drivers.
Signed-off-by: NHans J. Koch <hjk@linutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

bcm_enet_hw_preinit will correctly set values in ENET_CTL_REG for internal
or external MII operations, however, bcm_enet_open will blindly overwrite the
ENET_CTL_REG register value and thus we will loose any changes to it that
were made in bcm_enet_hw_preinit, rendering external MII operations non-working.

This would lead to the driver not being able to check for link availability on
external PHY setups, and thus we would never get to sending packets because
link was down from the driver side.

This was completely un-noticed because all boards out there but BCM6338-based
ones use internal phy on their enet0 interface.
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

GCC warns that:

drivers/net/chelsio/sge.c:463:11: warning: operation on 's->port' may be undefined

Better to eliminate the side effects in the calculation and
express what was intended here.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

smc91c92_cs:
  * define multicast_table as unsigned char
  * remove unnecessary "#ifndef final_version"
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Tx ring buffers after tx_ring->next_to_use are volatile and could
change, possibly causing a crash.  Stop cleaning when we hit
tx_ring->next_to_use.
Signed-off-by: NTerry Loftin <terry.loftin@hp.com>
Acked-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Restrict Wake-on-LAN to first port on 82576 ET2 quad port NICs, as it is
only supported there.
Signed-off-by: NStefan Assmann <sassmann@redhat.com>
Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

used a modified checkstack to get the 56 number
(normally checkstack wouldn't show this low a value)

checkstack before:
0x0000012f e1000e_check_options [e1000e]:               272

after:
0x0000012f e1000e_check_options [e1000e]:                56
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The registers for RDLEN/TDLEN on i350 have the first 7 bits as read only.
This is a change from previous hardware in which it was only the first 4
bits that were read only.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.

No functional change.

For further information about the background:

http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Andrew Gallatin <gallatin@myri.com>
Cc: Brice Goglin <brice@myri.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.

No functional change.

For further information about the background:

http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.

No functional change.

For further information about the background:

http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Divy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.

No functional change.

For further information about the background:

http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Divy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.

No functional change.

For further information about the background:

http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc:  Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.

No functional change.

For further information about the background:

http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Matt Carlson <mcarlson@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch updates the tg3 version to 3.110.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes the following checkpatch errors:

* return is not a function, parentheses are not required
* space prohibited between function name and open parenthesis '('
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>