linux-toradex.git/drivers/net, branch v3.2.6

8139cp: fix missing napi_gro_flush.

2012-02-13T19:16:56+00:00

commit b189e810619a676e6b931a942a3e8387f3d39c21 upstream.

The driver uses __napi_complete and napi_gro_receive. Without it, the
driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.

Signed-off-by: Francois Romieu 
Tested-by: Marin Glibic 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: fix a possible use after free

2012-02-03T17:22:19+00:00

[ Upstream commit 4ec7ac1203bcf21f5e3d977c9818b1a56c9ef40d ]

Commit bc416d9768 (macvlan: handle fragmented multicast frames) added a
possible use after free in macvlan_handle_frame(), since
ip_check_defrag() uses pskb_may_pull() : skb header can be reallocated.

Signed-off-by: Eric Dumazet 
Cc: Ben Greear 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: fix enslaving in alb mode when link down

2012-02-03T17:22:19+00:00

[ Upstream commit b924551bed09f61b64f21bffe241afc5526b091a ]

bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC
address. This is done differently for TLB and ALB modes.
bond->alb_info.rlb_enabled is used to discriminate between the two modes but
this flag may be uninitialized if the slave is being enslaved prior to calling
bond_open() -> bond_alb_initialize() on the master.

It turns out all the callers of alb_set_slave_mac_addr() pass
bond->alb_info.rlb_enabled as the hw parameter.

This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and
makes the function decide based on the bonding mode instead, which fixes the
above problem.

Reported-by: Narendra K 
Signed-off-by: Jiri Bohac 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix PCI-E transport "inta" race

2012-02-03T17:22:07+00:00

commit b49ba04a3a0382e7314d990707c21094c410425a upstream.

When an interrupt comes in, we read the reason
bits and collect them into "trans_pcie->inta".
This happens with the spinlock held. However,
there's a bug resetting this variable -- that
happens after the spinlock has been released.
This means that it is possible for interrupts
to be missed if the reset happens after some
other interrupt reasons were already added to
the variable.

I found this by code inspection, looking for a
reason that we sometimes see random commands
time out. It seems possible that this causes
such behaviour, but I can't say for sure right
now since it happens extremely infrequently on
my test systems.

Signed-off-by: Johannes Berg 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

brcmsmac: fix tx queue flush infinite loop

2012-02-03T17:21:31+00:00

commit f96b08a7e6f69c0f0a576554df3df5b1b519c479 upstream.

This patch workaround live deadlock problem caused by infinite loop
in brcms_c_wait_for_tx_completion(). I do not consider the patch as
the proper fix, which should fix the real reason of tx queue flush
failure, but patch helps with system lockup.

Reference:
https://bugzilla.kernel.org/show_bug.cgi?id=42576

Reported-and-tested-by: Patrick 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: 3945: fix hw passive scan on radar channels

2012-01-26T00:13:59+00:00

commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream.

Patch fix firmware error on "iw dev wlan0 scan passive" for
hardware scanning (with disable_hw_scan=0 module parameter).

 iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
 iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9
 iwl3945 0000:03:00.0: Start IWL Error Log Dump:
 iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
 iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
 iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
 iwl3945 0000:03:00.0: Can't stop Rx DMA.

We have disable ability to change passive scanning to active on
particular channel when traffic is detected on that channel. Otherwise
firmware will report error, when we try to do passive scan on radar
channels.

Reported-and-debugged-by: Pedro Francisco 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlagn: check for SMPS mode

2012-01-26T00:13:59+00:00

commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream.

Check and report WARN only when its invalid

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=42621
https://bugzilla.redhat.com/show_bug.cgi?id=766071

Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2800pci: fix spurious interrupts generation

2012-01-26T00:13:55+00:00

commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream.

Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.

We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci
device).

This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451

We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
as thing, that will prevent to detect real spurious interrupts.

Reported-and-tested-by: Amir Hedayaty 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix interpretation of the rx KeyMiss flag

2012-01-26T00:13:55+00:00

commit 7a532fe7131216a02c81a6c1b1f8632da1195a58 upstream.

Documentation states that the KeyMiss flag is only valid if RxFrameOK is
unset, however empirical evidence has shown that this is false.
When KeyMiss is set (and RxFrameOK is 1), the hardware passes a valid frame
which has not been decrypted. The driver then falsely marks the frame
as decrypted, and when using CCMP this corrupts the rx CCMP PN, leading
to connection hangs.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: Fix regression in channelwidth switch at the same channel

2012-01-26T00:13:23+00:00

commit 1a19f77f3642b8194ad9cf55548cc5d92e841766 upstream.

The commit "ath9k: Fix invalid noisefloor reading due to channel update"
preserves the current channel noisefloor readings before updating
channel type at the same channel index. It is also updating the curchan
pointer. As survey updation is also referring curchan pointer to fetch
the appropriate index, which might leads to invalid memory access. This
patch partially reverts the change and stores the noise floor history
buffer before updating channel type w/o updating curchan.

Cc: Gary Morain 
Cc: Paul Stewart 
Reported-by: Mohammed Shafi Shajakhan 
Signed-off-by: Rajkumar Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman