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

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

rtl8192se: Fix BUG caused by failure to check skb allocation

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

commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream.

When downloading firmware into the device, the driver fails to check the
return when allocating an skb. When the allocation fails, a BUG can be
generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

asix: fix setting custom MAC address on Asix 88772 devices

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

commit 8ef66bdc4bda6aac2dae73b84d79dc8c2db33637 upstream.

In kernel v3.2 initialization sequence for Asix 88772 devices was changed so
that hardware is reseted on every time interface is brought up (ifconfig up),
instead just at USB probe time. This causes problem with setting custom MAC
address to device as ax88772_reset causes reload of MAC address from EEPROM.

This patch fixes the issue by rewriting MAC address at end of ax88772_reset.

Signed-off-by: Jussi Kivilinna 
Acked-by: Grant Grundler 
Cc: Allan Chou 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

asix: fix setting custom MAC address on Asix 88178 devices

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

commit 71bc5d94061516c4e70303570128797bcf768b10 upstream.

In kernel v3.2 initialization sequence for Asix 88178 devices was changed so
that hardware is reseted on every time interface is brought up (ifconfig up),
instead just at USB probe time. This causes problem with setting custom MAC
address to device as ax88178_reset causes reload of MAC address from EEPROM.

This patch fixes the issue by rewriting MAC address at end of ax88178_reset.

Signed-off-by: Jussi Kivilinna 
Acked-by: Grant Grundler 
Cc: Allan Chou 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: fix error handling if slave is busy (v2)

2012-01-12T19:29:45+00:00

commit f7d9821a6a9c83450ac35e76d3709e32fd38b76f upstream.

If slave device already has a receive handler registered, then the
error unwind of bonding device enslave function is broken.

The following will leave a pointer to freed memory in the slave
device list, causing a later kernel panic.
# modprobe dummy
# ip li add dummy0-1 link dummy0 type macvlan
# modprobe bonding
# echo +dummy0 >/sys/class/net/bond0/bonding/slaves

The fix is to detach the slave (which removes it from the list)
in the unwind path.

Signed-off-by: Stephen Hemminger 
Reviewed-by: Nicolas de Pesloüan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

asix: fix infinite loop in rx_fixup()

2012-01-12T19:29:44+00:00

commit 6c15d74defd38e7e7f8805392578b7a1d508097e upstream.

At this point if skb->len happens to be 2, the subsequant skb_pull(skb, 4)
call won't work and the skb->len won't be decreased and won't ever reach 0,
resulting in an infinite loop.

With an ASIX 88772 under heavy load, without this patch, rx_fixup() reaches
an infinite loop in less than a minute. With this patch applied,
no infinite loop even after hours of heavy load.

Signed-off-by: Aurelien Jacobs 
Cc: Jussi Kivilinna 
Signed-off-by: David S. Miller