Using the scan_sdata variable here is terribly wrong,
if there has never been a scan then we fail. However,
we need a bandaid...
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org [2.6.29]
Signed-off-by: John W. Linville <linville@tuxdriver.com>

arm will pad even between u8's, so mark the structs/unions
packed. Fixes a build bug on arm due to BUILD_BUG_ON tests
in the code.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If the value read from HERMES_RID_TXQUEUEEMPTY becomes 0 after exactly
100 readings, we wrongly consider it a timeout.  Rewrite the clever
while loop as a for loop that does the right thing and looks simpler.

Reported by Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: Fragmentation threshold (typo)

ieee80211_ioctl_siwfrag() sets the fragmentation_threshold to 2352
when frame fragmentation is to be disabled, yet the corresponding
'get' function tests for 2353 bytes instead.

This causes user-space tools to display a fragmentation threshold
of 2352 bytes even if fragmentation has been disabled.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In a scenario where there isn't any firmware available, we will have a
double kfree of rt2x00dev->spec.channels_info when ieee80211_register_hw
returns an error status inside rt2x00lib_probe_hw.

The problem is that if ieee80211_register_hw fails, we call
rt2x00lib_remove_hw twice:
* first inside rt2x00lib_probe_hw upon failure of ieee80211_register_hw
* error status is returned to rt2x00lib_probe_dev, which then sees it and
  calls in this case rt2x00lib_remove_dev that will again run
  rt2x00lib_remove_hw

Prevent this avoiding calling rt2x00lib_remove_hw inside
rt2x00lib_probe_hw

Problem was detected with CONFIG_DEBUG_PAGEALLOC=y, CONFIG_SLUB_DEBUG=y,
CONFIG_SLUB_DEBUG_ON=y, that dumps this with no firmware available:

rt61pci 0000:00:07.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
wmaster0 (rt61pci): not using net_device_ops yet
phy0: Selected rate control algorithm 'pid'
phy0: Failed to initialize wep: -2
phy0 -> rt2x00lib_probe_dev: Error - Failed to initialize hw.
=============================================================================
BUG kmalloc-128: Object already free
-----------------------------------------------------------------------------

INFO: Allocated in rt61pci_probe_hw+0x3e5/0x6e0 [rt61pci] age=340 cpu=0 pid=21
INFO: Freed in rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib] age=0 cpu=0 pid=21
INFO: Slab 0xc13ac3e0 objects=23 used=10 fp=0xdd59f6e0 flags=0x400000c3
INFO: Object 0xdd59f6e0 @offset=1760 fp=0xdd59f790

Bytes b4 0xdd59f6d0:  15 00 00 00 b2 8a fb ff 5a 5a 5a 5a 5a 5a 5a 5a ....².ûÿZZZZZZZZ
  Object 0xdd59f6e0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f6f0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f700:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f710:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f720:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f730:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f740:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xdd59f750:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk¥
 Redzone 0xdd59f760:  bb bb bb bb                                     »»»»
 Padding 0xdd59f788:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ
Pid: 21, comm: stage1 Not tainted 2.6.29.1-desktop-1.1mnb #1
Call Trace:
 [<c01abbb3>] print_trailer+0xd3/0x120
 [<c01abd37>] object_err+0x37/0x50
 [<c01acf57>] __slab_free+0xe7/0x2f0
 [<c01ad1de>] kfree+0x7e/0xd0
 [<e0e4a239>] ? rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
 [<e0e4a239>] ? rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
 [<e0e4a239>] rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
 [<e0e4acc7>] rt2x00lib_remove_dev+0x37/0x50 [rt2x00lib]
 [<e0e4b087>] rt2x00lib_probe_dev+0x1a7/0x3b0 [rt2x00lib]
 [<e0eb288f>] rt2x00pci_probe+0xdf/0x1ee [rt2x00pci]
 [<c026b9ee>] local_pci_probe+0xe/0x10
 [<c026c750>] pci_device_probe+0x60/0x80
 [<c02d5c2a>] driver_probe_device+0x9a/0x2e0
 [<c02d5ef9>] __driver_attach+0x89/0x90
 [<c02d541b>] bus_for_each_dev+0x4b/0x70
 [<c026c690>] ? pci_device_remove+0x0/0x40
 [<c02d59d9>] driver_attach+0x19/0x20
 [<c02d5e70>] ? __driver_attach+0x0/0x90
 [<c02d4cef>] bus_add_driver+0x1cf/0x2a0
 [<c026c690>] ? pci_device_remove+0x0/0x40
 [<c02d60c9>] driver_register+0x69/0x140
 [<c026c9b0>] __pci_register_driver+0x40/0x80
 [<e0ecc000>] ? rt61pci_init+0x0/0x19 [rt61pci]
 [<e0ecc017>] rt61pci_init+0x17/0x19 [rt61pci]
 [<c0101116>] do_one_initcall+0x26/0x1c0
 [<c01ab90c>] ? slab_pad_check+0x3c/0x120
 [<c01ab90c>] ? slab_pad_check+0x3c/0x120
 [<c01ac8da>] ? check_object+0xda/0x210
 [<c01b0026>] ? percpu_free+0x46/0x50
 [<c01ad09e>] ? __slab_free+0x22e/0x2f0
 [<c01b0026>] ? percpu_free+0x46/0x50
 [<c01b0026>] ? percpu_free+0x46/0x50
 [<c01b0026>] ? percpu_free+0x46/0x50
 [<c01687ec>] ? stop_machine_destroy+0x3c/0x40
 [<c015e515>] ? load_module+0xa5/0x1c50
 [<e0ec5000>] ? rt61pci_eepromregister_read+0x0/0x40 [rt61pci]
 [<e0eb2000>] ? rt2x00pci_write_tx_data+0x0/0x90 [rt2x00pci]
 [<c03ac2fb>] ? mutex_lock+0xb/0x20
 [<c03ac2fb>] ? mutex_lock+0xb/0x20
 [<c017ad16>] ? tracepoint_update_probe_range+0x76/0xa0
 [<c017ad6f>] ? tracepoint_module_notify+0x2f/0x40
 [<c03b02ed>] ? notifier_call_chain+0x2d/0x70
 [<c014f0ed>] ? __blocking_notifier_call_chain+0x4d/0x60
 [<c014f11a>] ? blocking_notifier_call_chain+0x1a/0x20
 [<c0160156>] sys_init_module+0x96/0x1d0
 [<c019dad6>] ? sys_munmap+0x46/0x60
 [<c0105546>] syscall_call+0x7/0xb
FIX kmalloc-128: Object at 0xdd59f6e0 not freed
rt61pci 0000:00:07.0: PCI INT A disabled
rt61pci: probe of 0000:00:07.0 failed with error -2
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

I forgot that iwl3945 registration is separate from iwlagn.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

On Sunday 05 April 2009 11:29:38 Michael Buesch wrote:
> On Sunday 05 April 2009 11:23:59 Jaswinder Singh Rajput wrote:
> > With latest linus tree I am getting, .config file attached:
> >
> > [   22.895051] r8169: eth0: link down
> > [   22.897564] ADDRCONF(NETDEV_UP): eth0: link is not ready
> > [   22.928047] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > [   22.982292] libvirtd used greatest stack depth: 4200 bytes left
> > [   63.709879] wlan0: authenticate with AP 00:11:95:9e:df:f6
> > [   63.712096] wlan0: authenticated
> > [   63.712127] wlan0: associate with AP 00:11:95:9e:df:f6
> > [   63.726831] wlan0: RX AssocResp from 00:11:95:9e:df:f6 (capab=0x471 status=0 aid=1)
> > [   63.726855] wlan0: associated
> > [   63.730093] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> > [   74.296087] wlan0: no IPv6 routers present
> > [   79.349044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  119.358200] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  179.354292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  259.366044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  359.348292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  361.953459] packagekitd used greatest stack depth: 4160 bytes left
> > [  478.824258] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  598.813343] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  718.817292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  838.824567] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [  958.815402] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1078.848434] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1198.822913] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1318.824931] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1438.814157] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1558.827336] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1678.823011] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1798.830589] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1918.828044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2038.827224] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2116.517152] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2158.840243] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2278.827427] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
>
>
> I think this message should only show if CONFIG_MAC80211_VERBOSE_DEBUG is set.
> It's kind of expected that we lose a beacon once in a while, so we shouldn't print
> verbose messages to the kernel log (even if they are KERN_DEBUG).
>
> And besides that, I think one can easily remotely trigger this message and flood the logs.
> So it should probably _also_ be ratelimited.

Something like this:
Signed-off-by: Michael Buesch <mb@bu3sch.de>

The assertion of the lock-bit in the hardware register is unreliable,
because there are devices with quirks that will randomly set the bit.

Do the assertion in software, only.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch adds a new device to ar9170usb.
Reported-by: Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Code was clearly wrong, plus callers expect the mode change to happen as
soon as possible, not dropped on the floor until the next time some
other config value changes and a commit happens.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add USB device ID for OQO 01+'s internal wireless LAN

An OQO employee mentions the chip's true identity here:-
    ftp://ftp.oqo.com/unsupported/linux/OQOLinux.htmlSigned-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Don't lead memory when receive errors
Signed-off-by: Philip Rakity <prakity@yahoo.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Wext makes no assumptions about the contents of
data->txpower.fixed and data->txpower.value when
data->txpower.disabled is set, so do not update
the user-requested power level while disabling.

Also, when wext configures a really _fixed_ power
output [1], we should reject it instead of limiting it
to the regulatory constraint. If the user wants to set
a _limit_ [2] then we should honour that.

[1] iwconfig wlan0 txpower 20dBm fixed
[2] iwconfig wlan0 txpower 10dBm

This fixes
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1942Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch fixes the bug that the driver tries to continue to
connect(associate) to AP even if gelic_wl_do_{wpa,wep}_setup() fails,
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch fixes the following waring:
> ------------[ cut here ]------------
>WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
>Modules linked in: p54spi
>[<c0034ff8>] (dump_stack+0x0/0x14)
>[<c005b1a4>] (warn_on_slowpath+0x0/0x68)
>[<c00604c8>] (local_bh_enable+0x0/0xbc)
>[<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi])
>[<c01a4d34>] (p54_sta_unlock+0x0/0x78)

p54spi_op_tx needs to be called from different locking contexts.
Therefore we have to protect the linked list with irqsave spinlocks.
Reported-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

I'm very sorry, as this change belongs to the other patch:
"[PATCH] p54: fix SoftLED compile dependencies".
however I must have somehow lost "git add" for that file.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
because it might be (partially) overwritten by some DMA operations.

Cc: stable@kernel.org
Cc: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch adds poisoning and sanity checking to the RX DMA buffers.
This is used for protection against buggy hardware/firmware that raises
RX interrupts without doing an actual DMA transfer.

This mechanism protects against rare "bad packets" (due to uninitialized skb data)
and rare kernel crashes due to uninitialized RX headers.

The poison is selected to not match on valid frames and to be cheap for checking.

The poison check mechanism _might_ trigger incorrectly, if we are voluntarily
receiving frames with bad PLCP headers. However, this is nonfatal, because the
chance of such a match is basically zero and in case it happens it just results
in dropping the packet.
Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen
to the latest news broadcasted by your microwave oven.

This patch also moves the initialization of the RX-header "length" field in front of
the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it.

Cc: stable@kernel.org
Reported-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Currently rx status for frames which are completed from reorder buffer
is taken from it's cb area which is not always right, cb is not holding
the rx status when driver uses mac80211's non-irq rx handler to pass it's
received frames. This results in dropping almost all frames from reorder
buffer when security is enabled by doing double decryption (first in hw,
second in sw because of wrong rx status). This patch copies rx status into
cb area before the frame is put into reorder buffer. After this patch,
there is a significant improvement in throughput with ath9k + WPA2(AES).
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We won't ever get here as regulatory_hint_core() can only fail
on -ENOMEM and in that case we don't initialize cfg80211 but this is
technically correct code.

This is actually good for stable, where we don't check for -ENOMEM
failure on __regulatory_hint()'s failure.

Cc: stable@kernel.org
Reported-by: Quentin Armitage <Quentin@armitage.org.uk>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The commit a390d1f3 ("phylib: convert state_queue work to
delayed_work") missed converting 'expires' value to 'delay' value.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Acked-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Prevent ixgbe from putting the adapter into D3 during shutdown except when
we're going to power off the system, since doing that may generally cause
problems with kexec to happen (such problems were observed for igb and
forcedeth).  For this purpose seperate ixgbe_shutdown() from ixgbe_suspend()
and use the appropriate PCI PM callbacks in both of them.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Prevent e1000e from putting the adapter into D3 during shutdown except when
we're going to power off the system, since doing that may generally cause
problems with kexec to happen (such problems were observed for igb and
forcedeth).  For this purpose seperate e1000e_shutdown() from e1000e_suspend()
and use the appropriate PCI PM callbacks in both of them.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Prevent e1000 from putting the adapter into D3 during shutdown except when
we're going to power off the system, since doing that may generally cause
problems with kexec to happen (such problems were observed for igb and
forcedeth).  For this purpose seperate e1000_shutdown() from e1000_suspend()
and use the appropriate PCI PM callbacks in both of them.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Latest tcpdump/libpcap triggers annoying messages because of high order page
allocation failures (when lowmem exhausted or fragmented)

These allocation errors are correctly handled so could be silent.

[22660.208901] tcpdump: page allocation failure. order:5, mode:0xc0d0
[22660.208921] Pid: 13866, comm: tcpdump Not tainted 2.6.30-rc2 #170
[22660.208936] Call Trace:
[22660.208950]  [<c04e2b46>] ? printk+0x18/0x1a
[22660.208965]  [<c02760f7>] __alloc_pages_internal+0x357/0x460
[22660.208980]  [<c0276251>] __get_free_pages+0x21/0x40
[22660.208995]  [<c04cc835>] packet_set_ring+0x105/0x3d0
[22660.209009]  [<c04ccd1d>] packet_setsockopt+0x21d/0x4d0
[22660.209025]  [<c0270400>] ? filemap_fault+0x0/0x450
[22660.209040]  [<c0449e34>] sys_setsockopt+0x54/0xa0
[22660.209053]  [<c044b97f>] sys_socketcall+0xef/0x270
[22660.209067]  [<c0202e34>] sysenter_do_call+0x12/0x26
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

After a transmit timed out, the reset task will be called, which will free the
allocated resources(stop_gfar). If gfar_poll will be called before the
resources get allocated again gfar_clean_tx_ring will call
dev_kfree_skb_any(NULL).

Example crash:

ops: Kernel access of bad area, sig: 11 [#1]
PREEMPT RSBBA100
Modules linked in:
NIP: c01a10c4 LR: c013b254 CTR: c013c038
REGS: c02e7d20 TRAP: 0300   Not tainted  (2.6.27.20)
MSR: 00001032 <ME,IR,DR>  CR: 24000082  XER: 20000000
DAR: 000000a0, DSISR: 20000000
TASK = c02ce578[0] 'swapper' THREAD: c02e6000
GPR00: 000000a0 c02e7dd0 c02ce578 00000000 00000040 00000001 c02ec1c0 
00001032
GPR08: c080d1e0 df9ea800 00000000 00000000 24000082 ffffffff 0404f000 
00000000
GPR16: ffffffbf ffffffff ffffffff ffdff7ff ffffffff c02d0fd4 00100100 
00200200
GPR24: c031220c 00000001 00000001 00000000 00000000 df849800 ff109000 
df849b80
NIP [c01a10c4] dev_kfree_skb_irq+0x18/0x70
LR [c013b254] gfar_clean_tx_ring+0x70/0x11c
Call Trace:
[c02e7dd0] [c003e978] update_wall_time+0x730/0x744 (unreliable)
[c02e7df0] [c013b254] gfar_clean_tx_ring+0x70/0x11c
[c02e7e10] [c013c07c] gfar_poll+0x44/0x150
[c02e7e30] [c01a064c] net_rx_action+0xa8/0x19c
[c02e7e70] [c00251d4] __do_softirq+0x64/0xc0
[c02e7e90] [c0006384] do_softirq+0x40/0x58
[c02e7ea0] [c00250a8] irq_exit+0x40/0x9c
[c02e7eb0] [c000642c] do_IRQ+0x90/0xac
[c02e7ec0] [c0010ab4] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x9c/0xf8
    LR = cpu_idle+0x9c/0xf8
[c02e7f80] [c0009820] cpu_idle+0x58/0xf8 (unreliable)
[c02e7fa0] [c01fb8c8] __got2_end+0x7c/0x90
[c02e7fc0] [c026c794] start_kernel+0x2c0/0x2d4
[c02e7ff0] [00003438] 0x3438
Instruction dump:
7fa00124 80010024 bba10014 38210020 7c0803a6 4e800020 9421ffe0 7c0802a6
7c6b1b78 90010024 380300a0 bfa10014 <7d200028> 3129ffff 7d20012d 40a2fff4
Kernel panic - not syncing: Fatal exception in interrupt

This Patch calls netif_stop_queue before calling stop_gfar.
Signed-off-by: Markus Brunner <super.firetwister@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add LRO alignment initially committed in
621544eb ("[LRO]: fix lro_gen_skb()
alignment") and removed in 0dcffac1
("myri10ge: add multislices support") during conversion to
multi-slice.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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

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

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

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

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

Move the update of real_num_tx_queues from
ixgbe_acquire_msix_vectors() to ixgbe_set_num_queues(), to ensure it
be always in sync with num_tx_queues.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Don't do the num_tx_queues based masking on calculating tx queue
index.

 1) num_tx_queues is not always power-of-2, because it also depends on
    the online cpu numbers. So the masking could be a performance bug
    on a 6 cpu system.
 2) queue_mapping will be limited by real_num_tx_queues=num_tx_queues
    in the generic netdev function set_cur_queue_map(). So the bound
    limiting here is not necessary.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This reverts commit 244f46ae.

Alan Cox did the research, and just like the other radio protocols
zero-length frames have meaning because at the top level ROSE is
X.25 PLP.

So this zero-length filtering is invalid.
Signed-off-by: David S. Miller <davem@davemloft.net>

falcon_sim_phy_event() used EFX_OWORD_FIELD, which operates on
bitfields in 128-bit values, on an event, which is a 64-bit value.
This should be harmless - these macros always use little-endian
ordering, so it would read and write back the following 8 bytes
unchanged - but it is obviously wrong.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sfc could call netif_napi_add() multiple times for the same
napi_struct, corrupting the list of napi_structs for the associated
device and leading to a busy-loop on device removal.  Move the call to
netif_napi_add() and add a call to netif_napi_del() in the obvious
places.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>