linux.git/drivers/net/wireless, branch v2.6.19 Linux kernel source tree [PATCH] bcm43xx: Add error checking in bcm43xx_sprom_write() 2006-11-08T01:05:07+00:00 Adrian Bunk bunk@stusta.de 2006-11-06T15:48:48+00:00 3406118cd34762a7bf6b1a4f1095f9ea7576a354 The Coverity checker noted that these "if (err)"'s couldn't ever be true. It seems the intention was to check the return values of the bcm43xx_pci_write_config32()'s? Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The Coverity checker noted that these "if (err)"'s couldn't ever be
true.

It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] bcm43xx: Drain TX status before starting IRQs 2006-11-08T01:05:06+00:00 Michael Buesch mb@bu3sch.de 2006-11-06T15:45:31+00:00 ecac598bcd1f151ee4760489bded625c147fb366 Drain the Microcode TX-status-FIFO before we enable IRQs. This is required, because the FIFO may still have entries left from a previous run. Those would immediately fire after enabling IRQs and would lead to an oops in the DMA TXstatus handling code. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] bcm43xx: fix unexpected LED control values in BCM4303 sprom 2006-11-01T03:15:41+00:00 Larry Finger Larry.Finger@lwfinger.net 2006-10-18T04:38:26+00:00 df6d7c94b0c3ae6a1185c9e5fa8ee3368e4a5efb The bcm43xx driver uses 4 locations in the devices sprom to determine the behavior of the leds. Certain defaults are assigned if all bits are set in those locations. On at least one BCM4303 chip, the sprom contains values other than the default, which executes an assertion placed in the default case of a following switch statement. This patch makes the leds on the above mentioned interface behave correctly. In addition, it limits the number of logged messages to 20 for the case of unexpected values in the sprom locations. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The bcm43xx driver uses 4 locations in the devices sprom to determine
the behavior of the leds. Certain defaults are assigned if all bits are
set in those locations. On at least one BCM4303 chip, the sprom contains
values other than the default, which executes an assertion placed in the
default case of a following switch statement. This patch makes the leds
on the above mentioned interface behave correctly. In addition, it limits
the number of logged messages to 20 for the case of unexpected values in
the sprom locations.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] bcm43xx: Fix low-traffic netdev watchdog TX timeouts 2006-11-01T03:15:40+00:00 Michael Buesch mb@bu3sch.de 2006-10-28T22:52:34+00:00 81e171b95d2d06a64465a1e6ab1e2fb864ea2448 This fixes a netdev watchdog timeout problem. The software needs to call netif_tx_disable before running the hardware calibration code. The problem condition can be shown by the following timegraph. |---5secs - ~10 jiffies time---|---|OOPS ^ ^ last real TX periodic work stops netif At OOPS, the following happens: The watchdog timer triggers, because the timeout of 5secs is over. The watchdog first checks for stopped TX. _Usually_ TX is only stopped from the TX handler to indicate a full TX queue. But this is different. We need to stop TX here, regardless of the TX queue state. So the watchdog recognizes the stopped device and assumes it is stopped due to full TX queues (Which is a _wrong_ assumption in this case). It then tests how far the last TX has been in the past. If it's more than 5secs (which is the case for low or no traffic), it will fire a TX timeout. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
This fixes a netdev watchdog timeout problem.
The software needs to call netif_tx_disable before running the
hardware calibration code. The problem condition can be shown by the
following timegraph.

|---5secs - ~10 jiffies time---|---|OOPS
^                              ^
last real TX                   periodic work stops netif

At OOPS, the following happens:
The watchdog timer triggers, because the timeout of 5secs
is over. The watchdog first checks for stopped TX.
_Usually_ TX is only stopped from the TX handler to indicate
a full TX queue. But this is different. We need to stop TX here,
regardless of the TX queue state. So the watchdog recognizes
the stopped device and assumes it is stopped due to full
TX queues (Which is a _wrong_ assumption in this case). It then
tests how far the last TX has been in the past. If it's more than
5secs (which is the case for low or no traffic), it will fire
a TX timeout.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] hostap_plx: fix CIS verification 2006-11-01T03:15:39+00:00 Pavel Roskin proski@gnu.org 2006-10-25T02:41:27+00:00 115e222d538e7838bffa0f76409acd9816a0ef32 The length of the manfid CIS should be at least 4, and it's normally 4. It's incorrect to require it to be at least 5. This breaks support for most (if not all) cards. The right place to ensure that we don't access beyond the CIS buffer is to strengthen another check. Make sure that the next tuple begins at least at the CIS buffer end (in which case we stop processing) or before that. Reported by ph35sm@free.fr Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The length of the manfid CIS should be at least 4, and it's normally 4.
It's incorrect to require it to be at least 5.  This breaks support for
most (if not all) cards.

The right place to ensure that we don't access beyond the CIS buffer is
to strengthen another check.  Make sure that the next tuple begins at
least at the CIS buffer end (in which case we stop processing) or
before that.

Reported by ph35sm@free.fr

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] pcmcia: add more IDs to hostap_cs.c 2006-10-26T01:59:38+00:00 Dominik Brodowski linux@dominikbrodowski.net 2006-07-02T19:21:51+00:00 01918d16c837485ceba92d48fb734cf520e61144 As a replacement for the broad manufactor/card ID match we commented out because of conflicts with pcnet_cs, add two product ID matches. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> 
As a replacement for the broad manufactor/card ID match we commented out
because of conflicts with pcnet_cs, add two product ID matches.

Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
[PATCH] missing include of dma-mapping.h 2006-10-25T05:01:11+00:00 Al Viro viro@ftp.linux.org.uk 2006-10-24T10:17:37+00:00 016002312d50004908a79df37174b336e3682e18 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] zd1211rw: fix build-break caused by association race fix 2006-10-17T17:47:40+00:00 John W. Linville linville@tuxdriver.com 2006-10-17T17:47:40+00:00 41072a1be57f63bf83afc31c44d72de018d800fa The break was caused by 7c28ad2d83ecc637237fe684659a6afbce0bb2a8. Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The break was caused by 7c28ad2d83ecc637237fe684659a6afbce0bb2a8.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] airo: check if need to freeze 2006-10-17T00:09:49+00:00 Dave Kleikamp shaggy@austin.ibm.com 2006-10-10T21:45:46+00:00 5bb85f18087b10a908bd793e9fd3ccd63aebb724 The airo driver used to break out of while loop if there were any signals pending. Since it no longer checks for signals, it at least needs to check if it needs to be frozen. Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Cc: Jean Tourrilhes <jt@hpl.hp.com> Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The airo driver used to break out of while loop if there were any signals
pending.  Since it no longer checks for signals, it at least needs to check
if it needs to be frozen.

Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: Jean Tourrilhes <jt@hpl.hp.com>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] wireless: More WE-21 potential overflows... 2006-10-17T00:09:48+00:00 Jean Tourrilhes jt@hpl.hp.com 2006-10-10T21:45:46+00:00 53077944f119808df3d1c6be07241f17a87e7c28 After the Orinoco issue, I did an audit of other drivers for the same issue. Three drivers were NULL terminating the ESSID, which could cause an overflow in WE-21 when the ESSID has maximum size. Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
After the Orinoco issue, I did an audit of other drivers for the same
issue.  Three drivers were NULL terminating the ESSID, which could cause an
overflow in WE-21 when the ESSID has maximum size.

Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>