linux-toradex.git/drivers/net/wireless, branch v2.6.24.4

b43: Backport bcm4311 fix

2008-03-24T18:47:31+00:00

This is a backport of upstream commit 013978b6 ("b43: Changes to enable
BCM4311 rev 02 with wireless core revision 13") and the changes include
the following:

(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Change the 2-bit routing code for address extensions to 0b10 rather
    than the 0b01 used for the 32-bit case.
(4) Remove some magic numbers in the DMA setup.

The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to "Bias the placement of kernel pages at lower PFNs". When
commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.

Signed-off-by: Michael Buesch 
Cc: Larry Finger 
Cc: John W. Linville 
Cc: Alexey Zaytsev 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

b43: Reject new firmware early

2008-02-08T19:46:29+00:00

(not in mainline, as it is not applicable.)

We must reject new incompatible firmware early to avoid
running into strange transmission failures.

The current development tree supports newer firmware revisions.
These revisions cause strange failures on the stable 2.6.24 kernel.
Add a check to avoid confusing users a lot.

Signed-off-by: Michael Buesch 
Signed-off-by: Greg Kroah-Hartman

b43legacy: fix DMA slot resource leakage

2008-02-08T19:46:28+00:00

patch 8dd0100ce9511e52614ecd0a6587c13ce5769c8b in mainline.

This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.

This patch by Michael Buesch has been ported to b43legacy.

Cc: Michael Buesch 
Signed-off-by: Stefano Brivio 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: drop packets we are not able to encrypt

2008-02-08T19:46:28+00:00

patch 9eca9a8e81928685b4de00ecef83a7c13c340fc9 in mainline.

We must drop any packets we are not able to encrypt.
We must not send them unencrypted or with an all-zero-key (which
basically is the same as unencrypted, from a security point of view).

This might only trigger shortly after resume before mac80211 reassociated
and reconfigured the keys.

It is safe to drop these packets, as the association they belong to
is not guaranteed anymore anyway.
This is a security fix in the sense that it prevents information leakage.

This patch by Michael Buesch has been ported to b43legacy.

Cc: Michael Buesch 
Signed-off-by: Stefano Brivio 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: fix suspend/resume

2008-02-08T19:46:28+00:00

patch ada50731c0346bf900dc387edd3a6961297bf2d3 in mainline.

This patch makes suspend/resume work with the b43legacy driver.
We must not overwrite the MAC addresses in the init function, as this
would also overwrite the MAC on resume. With an all-zero MAC the device
firmware is not able to ACK any received packets anymore.
Fix this by moving the initializion stuff that must be done on init but
not on resume to the start function.
Also zero out filter_flags to make sure we don't have some flags
from a previous instance for a tiny timeframe until mac80211 reconfigures
them.

This patch by Michael Buesch has been ported to b43legacy.

Cc: Michael Buesch 
Signed-off-by: Stefano Brivio 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: fix PIO crash

2008-02-08T19:46:28+00:00

patch 0cd67d48b519c3d8d89d238fab1cf68a5289638a in mainline.

Fix the crash reported below, which seems to happen on bcm4306 rev. 2 devices
only while using PIO:

Oops: 0000 [#1] PREEMPT
Modules linked in: b43(F) rfkill(F) led_class(F) input_polldev(F) arc4 b43legacy mac80211 cfg80211 i915 drm snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device ohci1394 ieee1394 ssb pcmcia snd_intel8x0m ehci_hcd uhci_hcd evdev

Pid: 0, comm: swapper Tainted: GF	(2.6.24st3 #2)
EIP: 0060:[] EFLAGS: 00010002 CPU: 0
EIP is at b43legacy_pio_handle_txstatus+0xbb/0x210 [b43legacy]
EAX: 0000049b EBX: f11f8044 ECX: 00000001 EDX: 00000000
ESI: f1ff8000 EDI: 00000000 EBP: f11f8040 ESP: c04f4ef4
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c04f4000 task=c0488300 task.ti=c04b8000)
Stack: f90f2788 c05009f0 c0500900 000010f7 f1053823 c04f4f24 dfb8e800 00000003
       f1368000 00000007 00000296 f90f1975 00001000 010c0800 01000000 00000007
       f90f6391 f11f8000 00000082 c04f4f4a 00000000 00004fd0 10f70000 8c061000
Call Trace:
 [] b43legacy_debugfs_log_txstat+0x48/0xb0 [b43legacy]
 [] b43legacy_handle_hwtxstatus+0x75/0x80 [b43legacy]
 [] b43legacy_pio_rx+0x201/0x280 [b43legacy]
 [] b43legacy_interrupt_tasklet+0x2e3/0x870 [b43legacy]
 [] tasklet_action+0x27/0x60
 [] __do_softirq+0x54/0xb0
 [] do_softirq+0x7b/0xe0
 [] handle_level_irq+0x0/0x110
 [] handle_level_irq+0x0/0x110
 [] irq_exit+0x38/0x40
 [] do_IRQ+0x83/0xd0
 [] __update_rq_clock+0x4f/0x180
 [] common_interrupt+0x23/0x28
 [] wakeup_code+0x7b/0xde
 [] acpi_processor_idle+0x24a/0x3c9
 [] cpu_idle+0x47/0x80
 [] start_kernel+0x205/0x290
 [] unknown_bootoption+0x0/0x1f0
 =======================
Code: 0f 00 00 81 fb ff 00 00 00 0f 87 36 01 00 00 8d 04 db 85 ff 8d 6c c6 40 8d 5d 04 0f 85 ef 00 00 00 fe 4e 0e 0f b7 46 0c 8b 53 04 <8b> 4a 50 29 c8 83 e8 52 66 89 46 0c 8b 54 24 14 80 7a 0b 00 74
EIP: [] b43legacy_pio_handle_txstatus+0xbb/0x210 [b43legacy] SS:ESP 0068:c04f4ef4
Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Stefano Brivio 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43: Fix dma-slot resource leakage

2008-02-08T19:46:28+00:00

patch 8dd0100ce9511e52614ecd0a6587c13ce5769c8b in mainline.

This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.

Signed-off-by: Michael Buesch 
Signed-off-by: Stefano Brivio 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43: Drop packets we are not able to encrypt

2008-02-08T19:46:26+00:00

patch 09552ccd8277e6382097e93a40f7311a09449367 in mainline

We must drop any packets we are not able to encrypt.
We must not send them unencrypted or with an all-zero-key (which
basically is the same as unencrypted, from a security point of view).

This might only trigger shortly after resume before mac80211 reassociated
and reconfigured the keys.

It is safe to drop these packets, as the association they belong to
is not guaranteed anymore anyway.
This is a security fix in the sense that it prevents information leakage.

Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

b43: Fix suspend/resume

2008-02-08T19:46:26+00:00

patch 7be1bb6b798d506693d2d8668e801951996b5a4a in mainline.

This patch makes suspend/resume work with the b43 driver.
We must not overwrite the MAC addresses in the init function, as this
would also overwrite the MAC on resume. With an all-zero MAC the device
firmware is not able to ACK any received packets anymore.
Fix this by moving the initializion stuff that must be done on init but
not on resume to the start function.
Also zero out filter_flags to make sure we don't have some flags
from a previous instance for a tiny timeframe until mac80211 reconfigures
them.

Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix possible read attempt on ucode that is not available

2008-01-23T11:11:41+00:00

This fixes a NULL pointer dereference that can occur when the
ucode is not loaded at the time __iwl_up is called.

The problem was reported at http://kerneloops.org/raw.php?rawid=2765&msgid=

Signed-off-by: Reinette Chatre 
Signed-off-by: John W. Linville