[PATCH V2] bcm43xx: Interrogate hardware-enable switch and update LEDs
The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
and mini-PCI-E cards. This patch implements a new routine to interrogate the
radio hardware enabled bit in the interface, logs the initial state and any
changes in the switch (if debugging enabled), activates the LED to show the
state, and changes the periodic work handler to provide 1 second response
to switch changes and to account for changes in the periodic work specs.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This should be applied to wireless-2.6. It is a new feature and is
not appropriate for 2.6.20-rcX. These changes have been tested on
a PCMCIA card with no wireless switch, A BCM4306 mini-PCI card, and
a BCM4311 mini-PCIE card. Michael's comment regarding V1 of this patch
has been addressed by changing the code.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
if (err)
goto err_gpio_cleanup;
bcm43xx_radio_turn_on(bcm);
+ bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
+ dprintk(KERN_INFO PFX "Radio %s by hardware\n",
+ (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
bcm43xx_write16(bcm, 0x03E6, 0x);
err = bcm43xx_phy_init(bcm);
@@ -3174,9 +3177,24 @@ static void bcm43xx_periodic_every30sec(
static void bcm43xx_periodic_every15sec(struct bcm43xx_private *bcm)
{
+ bcm43xx_phy_xmitpower(bcm); //FIXME: unless scanning?
+ //TODO for APHY (temperature?)
+}
+
+static void bcm43xx_periodic_every1sec(struct bcm43xx_private *bcm)
+{
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
+ int radio_hw_enable;
+ /* check if radio hardware enabled status changed */
+ radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
+ if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) {
+ bcm->radio_hw_enable = radio_hw_enable;
+ dprintk(KERN_INFO PFX "Radio hardware status changed to %s\n",
+ (radio_hw_enable == 0) ? "disabled" : "enabled");
+ bcm43xx_leds_update(bcm, 0);
+ }
if (phy->type == BCM43xx_PHYTYPE_G) {
//TODO: update_aci_moving_average
if (radio->aci_enable && radio->aci_wlan_automatic) {
@@ -3200,21 +3218,21 @@ static void bcm43xx_periodic_every15sec(
//TODO: implement rev1 workaround
}
}
- bcm43xx_phy_xmitpower(bcm); //FIXME: unless scanning?
- //TODO for APHY (temperature?)
}
static void do_periodic_work(struct bcm43xx_private *bcm)
{
- if (bcm->periodic_state % 8 == 0)
+ if (bcm->periodic_state % 120 == 0)
bcm43xx_periodic_every120sec(bcm);
- if (bcm->periodic_state % 4 == 0)
+ if (bcm->periodic_state % 60 == 0)
bcm43xx_periodic_every60sec(bcm);
- if (bcm->periodic_state % 2 == 0)
+ if (bcm->periodic_state % 30 == 0)
bcm43xx_periodic_every30sec(bcm);
- bcm43xx_periodic_every15sec(bcm);
+ if (bcm->periodic_state % 15 == 0)
+ bcm43xx_periodic_every15sec(bcm);
+ bcm43xx_periodic_every1sec(bcm);
- schedule_delayed_work(&bcm->periodic_work, HZ * 15);
+ schedule_delayed_work(&bcm->periodic_work, HZ);
}
static void bcm43xx_periodic_work_handler(struct work_struct *work)
@@ -3227,7 +3245,7 @@ static void bcm43xx_periodic_work_handle
unsigned long orig_trans_start = 0;
mutex_lock(&bcm->mutex);
- if (unlikely(bcm->periodic_state % 4 == 0)) {
+ if (unlikely(bcm->periodic_state % 60 == 0)) {
/* Periodic work will take a long time, so we want it to
* be preemtible.
*/
@@ -3259,7 +3277,7 @@ static void bcm43xx_periodic_work_handle
do_periodic_work(bcm);
- if (unlikely(bcm->periodic_state % 4 == 0)) {
+ if (unlikely(bcm->periodic_state % 60 == 0)) {
spin_lock_irqsave(&bcm->irq_lock, flags);
tasklet_enable(&bcm->isr_tasklet);
bcm43xx_interrupt_enable(bcm, savedirqs);
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
@@ -65,6 +65,22 @@ void bcm43xx_radio_init2060(struct bcm43
void bcm43xx_radio_turn_on(struct bcm43xx_private *bcm);
void bcm43xx_radio_turn_off(struct bcm43xx_private *bcm);
+static inline
+int bcm43xx_is_hw_radio_enabled(struct bcm43xx_private *bcm)
+{
+ /
[PATCH] bcm43xx-d80211: Interrogate hardware-enable switch and update LEDs
The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
and mini-PCI-E cards. This patch implements a new routine to interrogate the
radio hardware enabled bit in the interface, logs the initial state and any
changes in the switch (if debugging enabled), activates the LED to show the
state, and changes the periodic work handler to provide 1 second response
to switch changes and to account for changes in the periodic work specs. It
also incorporates changes in the LED state that were accepted into mainline
some time ago.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Michael,
This patch is for wireless-idev, and is the same as the patch recently
submitted for bcm43xx-softmac. These changes have been tested on
a PCMCIA card with no wireless switch, A BCM4306 mini-PCI card, and
a BCM4311 mini-PCIE card.
Larry
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
@@ -26,6 +26,7 @@
*/
#include "bcm43xx_leds.h"
+#include "bcm43xx_radio.h"
#include "bcm43xx.h"
#include
@@ -108,6 +109,7 @@ static void bcm43xx_led_init_hardcoded(s
switch (led_index) {
case 0:
led->behaviour = BCM43xx_LED_ACTIVITY;
+ led->activelow = 1;
if (bcm->board_vendor == PCI_VENDOR_ID_COMPAQ)
led->behaviour = BCM43xx_LED_RADIO_ALL;
break;
@@ -189,26 +191,31 @@ void bcm43xx_leds_update(struct bcm43xx_
case BCM43xx_LED_INACTIVE:
continue;
case BCM43xx_LED_OFF:
+ case BCM43xx_LED_BCM4303_3:
break;
case BCM43xx_LED_ON:
turn_on = 1;
break;
case BCM43xx_LED_ACTIVITY:
+ case BCM43xx_LED_BCM4303_0:
turn_on = activity;
break;
case BCM43xx_LED_RADIO_ALL:
- turn_on = radio->enabled;
+ turn_on = radio->enabled &&
bcm43xx_is_hw_radio_enabled(bcm);
break;
case BCM43xx_LED_RADIO_A:
- turn_on = (radio->enabled && phy->type ==
BCM43xx_PHYTYPE_A);
+ case BCM43xx_LED_BCM4303_2:
+ turn_on = (radio->enabled &&
bcm43xx_is_hw_radio_enabled(bcm) &&
+ phy->type == BCM43xx_PHYTYPE_A);
break;
case BCM43xx_LED_RADIO_B:
- turn_on = (radio->enabled &&
+ case BCM43xx_LED_BCM4303_1:
+ turn_on = (radio->enabled &&
bcm43xx_is_hw_radio_enabled(bcm) &&
(phy->type == BCM43xx_PHYTYPE_B ||
phy->type == BCM43xx_PHYTYPE_G));
break;
case BCM43xx_LED_MODE_BG:
- if (phy->type == BCM43xx_PHYTYPE_G &&
+ if (phy->type == BCM43xx_PHYTYPE_G &&
bcm43xx_is_hw_radio_enabled(bcm) &&
1/*FIXME: using G rates.*/)
turn_on = 1;
break;
@@ -257,7 +264,8 @@ void bcm43xx_leds_update(struct bcm43xx_
continue;
#endif /* CONFIG_BCM43XX_DEBUG */
default:
- assert(0);
+ dprintkl(KERN_INFO PFX "Bad value in leds_update,"
+ " led->behaviour: 0x%x\n", led->behaviour);
};
if (led->activelow)
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
@@ -46,6 +46,12 @@ enum { /* LED behaviour values */
BCM43xx_LED_TEST_BLINKSLOW,
BCM43xx_LED_TEST_BLINKMEDIUM,
BCM43xx_LED_TEST_BLINKFAST,
+
+ /* Misc values for BCM4303 */
+ BCM43xx_LED_BCM4303_0 = 0x2B,
+ BCM43xx_LED_BCM4303_1 = 0x78,
+ BCM43xx_LED_BCM4303_2 = 0x2E,
+ BCM43xx_LED_BCM4303_3 = 0x19,
};
int bcm43xx_leds_init(struct bcm43xx_private *bcm);
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -2243,6 +2243,9 @@ static int bcm43xx_chip_init(struct bcm4
if (err)
goto err_gpio_cleanup;
bcm43xx_radio_turn_on(bcm);
+ bcm->radio_hw_enable = bcm43xx_is_hw_radio_e
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
Aaron Sethman wrote: > > On Sat, 30 Dec 2006, Adrian Bunk wrote: > >> On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: >>> >>> Just was loading the bcm43xx module and got the following oops. Note >>> that >>> this card is one of the newer PCI-E cards. If any other info is needed >>> let me know. >> >> Is this issue still present in 2.6.10-rc2-git1? >> >> If yes, was 2.6.19 working fine? >> > > This seems to be fixed in 2.6.20-rc2-git1. Still having other issues > with the driver, but the oops in the SoftMAC code is resolved now at least. I have just started working with the PCI-E BCM4311 that is in my new computer. It receives data OK, but there is something wrong with the DMA out stuff in bcm43xx-softmac - at least for x86_64. All the slots get full but nothing is ever transmitted. FWIW, the wireless-dev git tree works. I'm using it for communications now. I'm using openSUSE 10.2 which uses NetworkManager to configure my WPA-PSK TKIP encrypted network. The signal strengths are roughly the same as I got for my old BCM4306 card. I will post any fixes for the DMA problem as soon as they are available, but it may be a while. I will be off-line until Thursday while I attend a funeral. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
On Sat, 30 Dec 2006, Adrian Bunk wrote: On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: Just was loading the bcm43xx module and got the following oops. Note that this card is one of the newer PCI-E cards. If any other info is needed let me know. Is this issue still present in 2.6.10-rc2-git1? If yes, was 2.6.19 working fine? This seems to be fixed in 2.6.20-rc2-git1. Still having other issues with the driver, but the oops in the SoftMAC code is resolved now at least. -Aaron - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
TCP_DEFER_ACCEPT brokenness?
hi... i'm having troubles matching up the tcp(7) man page description of
TCP_DEFER_ACCEPT versus some comments in the kernel (2.6.20-rc2) versus
how the kernel actually acts.
the man page says this:
TCP_DEFER_ACCEPT
Allows a listener to be awakened only when data arrives on
the socket. Takes an integer value (seconds), this can bound
the maximum number of attempts TCP will make to complete the
connection. This option should not be used in code intended to
be portable.
which is a bit confusing because it talks both about seconds and
"attempts". (and doesn't mention what happens when the timeout finishes
-- i could see dropping the socket or passing it to userland anyhow as
possibilities... but in fact the socket is dropped).
the setsockopt code in tcp.c does this:
case TCP_DEFER_ACCEPT:
icsk->icsk_accept_queue.rskq_defer_accept = 0;
if (val > 0) {
/* Translate value in seconds to number of
* retransmits */
while (icsk->icsk_accept_queue.rskq_defer_accept < 32 &&
val > ((TCP_TIMEOUT_INIT / HZ) <<
icsk->icsk_accept_queue.rskq_defer_accept))
icsk->icsk_accept_queue.rskq_defer_accept++;
icsk->icsk_accept_queue.rskq_defer_accept++;
}
break;
so at least the comment agrees with the man page -- however the code
doesn't... the code finds the least n such that val < (3< 127.0.0.1.53846: S
1792609127:1792609127(0) win 32792
1167532741.446899 IP 127.0.0.1.53846 > 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768
1167532741.446122 IP 127.0.0.1.56733 > 127.0.0.1.53846: . ack 1 win 1025
1167532745.249902 IP 127.0.0.1.53846 > 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768
1167532745.249912 IP 127.0.0.1.56733 > 127.0.0.1.53846: . ack 1 win 1025
1167532751.648046 IP 127.0.0.1.53846 > 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768
1167532751.648058 IP 127.0.0.1.56733 > 127.0.0.1.53846: . ack 1 win 1025
1167532764.448456 IP 127.0.0.1.53846 > 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768
1167532764.448473 IP 127.0.0.1.56733 > 127.0.0.1.53846: . ack 1 win 1025
1167532788.452409 IP 127.0.0.1.53846 > 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768
1167532788.452430 IP 127.0.0.1.56733 > 127.0.0.1.53846: . ack 1 win 1025
1167532836.453520 IP 127.0.0.1.53846 > 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768
1167532836.453539 IP 127.0.0.1.56733 > 127.0.0.1.53846: . ack 1 win 1025
now honestly i don't mind if 1s works correctly (because
apache 2.2.x is broken and sets TCP_DEFER_ACCEPT to 1 ... see
).
but even if i use more reasonable timeouts like 30s it doesn't
behave as expected based on the docs.
not sure which way this should be resolved -- or how long the code has
been like this... perhaps the current behaviour should just become the
documented behaviour (whatever the current behaviour is :).
-dean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc2: known unfixed regressions (v2)
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: USB keyboard unresponsive after some time References : http://lkml.org/lkml/2006/12/25/35 http://lkml.org/lkml/2006/12/26/106 Submitter : Florin Iucha <[EMAIL PROTECTED]> Status : unknown Subject: BUG: scheduling while atomic References : http://lkml.org/lkml/2006/12/26/105 Submitter : Jon Smirl <[EMAIL PROTECTED]> Status : unknown Subject: ALSA: No sound in KDE with intel hda References : http://lkml.org/lkml/2006/12/30/73 Submitter : Ismail Dönmez <[EMAIL PROTECTED]> Status : unknown Subject: SPARC64: Can't mount / References : http://lkml.org/lkml/2006/12/13/181 Submitter : Horst H. von Brand <[EMAIL PROTECTED]> Status : unknown Subject: ftp: get or put stops during file-transfer References : http://lkml.org/lkml/2006/12/16/174 Submitter : Komuro <[EMAIL PROTECTED]> Caused-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]> commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc Handled-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Status : problem is being debugged Subject: forcedeth.c 0.59: problem with sideband managment References : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Submitter : Michael Reske <[EMAIL PROTECTED]> Handled-By : Ayaz Abdulla <[EMAIL PROTECTED]> Status : problem is being debugged Subject: x86_64 boot failure: "IO-APIC + timer doesn't work" References : http://lkml.org/lkml/2006/12/16/101 Submitter : Tobias Diedrich <[EMAIL PROTECTED]> Caused-By : Andi Kleen <[EMAIL PROTECTED]> commit b026872601976f666bae77b609dc490d1834bf77 Handled-By : Yinghai Lu <[EMAIL PROTECTED]> Eric W. Biederman <[EMAIL PROTECTED]> Status : problem is being debugged Subject: kernel panics on boot (libata-sff) References : http://lkml.org/lkml/2006/12/3/99 http://lkml.org/lkml/2006/12/14/153 http://lkml.org/lkml/2006/12/24/33 Submitter : Alessandro Suardi <[EMAIL PROTECTED]> Caused-By : Alan Cox <[EMAIL PROTECTED]> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Handled-By : Alan Cox <[EMAIL PROTECTED]> Status : people are working on a fix Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system References : http://lkml.org/lkml/2006/12/25/40 Submitter : Berthold Cogel <[EMAIL PROTECTED]> Status : submitter was asked for more information - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
> Can you reproduce it with other ftp client and/or server? O.K. I wiil try to test other ftp client and server. > Please provide the output of "netstat -na" command during the > transfer, and the output of "lsmod | grep conntrack" (just for > sure). Please see the output of "netstat -na" when stuck. (below) CONFIG_NETFILER is diabled in my test configuration ,conntrack modules is not loaded. (CONFIG_IP_DCCP, CONFIG_IP_SCTP, CONFIG_TIPC, CONFIG_IPV6 is also disabled) > What kind of mode do you use? e.g. PORT/EPRT/LPRT/PASV/EPSV/LPSV PASV mode. > When the transfer get stuck, are other communication still working? Other communication works properly. Actually, I can start other ftp session on other console of the same PC. > Are there any workaround? > e.g. stop-start vsftpd cycle, ifdown-ifup cycle, rmmod/insmod cycle etc. I only need to do the killall command. >> output of netstat -na Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:873 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp0 0 192.168.0.6:35737 192.168.0.2:26827 TIME_WAIT tcp0 0 192.168.0.6:51036 192.168.0.2:21 ESTABLISHED udp0 0 0.0.0.0:68 0.0.0.0:* udp0 0 0.0.0.0:867 0.0.0.0:* udp0 0 0.0.0.0:870 0.0.0.0:* udp0 0 0.0.0.0:111 0.0.0.0:* Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 5056 /tmp/.font-unix/fs7100 unix 2 [ ] DGRAM1234 @/org/kernel/udev/udevd unix 5 [ ] DGRAM4748 /dev/log unix 2 [ ACC ] STREAM LISTENING 4917 /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 4989 /var/run/acpid.socket unix 2 [ ] DGRAM5390 unix 3 [ ] STREAM CONNECTED 4920 unix 3 [ ] STREAM CONNECTED 4919 unix 2 [ ] DGRAM4866 unix 2 [ ] DGRAM4756 Thanks, Best Regards Komuro - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zd1211rw: Add ID for Linksys WUSBF54G
Tested by Henrik Hjelte
zd1211b chip 13b1:0024 v4802 high 00-14-bf AL2230_RF pa0
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linux-2.6.orig/drivers/net/wireless/zd1211rw/zd_usb.c
+++ linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -60,6 +60,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x050d, 0x705c), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x083a, 0x4505), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0471, 0x1236), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x13b1, 0x0024), .driver_info = DEVICE_ZD1211B },
/* "Driverless" devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] zd1211rw: 2 new ZD1211B device ID's
Philips SNU5600, tested by unibrow
zd1211b chip 0471:1236 v4810 high 00-12-bf AL2230_RF pa0 g--
SMC Ez Connect 802.11g (SMCWUSB-G), tested by Victorino Sanz Prat
zd1211b chip 083a:4505 v4810 ful l 00-13-f7 AL2230_RF pa0 g--N
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_usb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Sent this on December 11th but looks like it got lost.
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linux-2.6.orig/drivers/net/wireless/zd1211rw/zd_usb.c
+++ linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -58,6 +58,8 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x079b, 0x0062), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x1582, 0x6003), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x050d, 0x705c), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x083a, 0x4505), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x0471, 0x1236), .driver_info = DEVICE_ZD1211B },
/* "Driverless" devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
Adrian Bunk wrote: > On Sat, Dec 30, 2006 at 03:23:42PM -0600, Larry Finger wrote: >> Adrian Bunk wrote: >>> On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: Just was loading the bcm43xx module and got the following oops. Note that this card is one of the newer PCI-E cards. If any other info is needed let me know. >>> Is this issue still present in 2.6.10-rc2-git1? >>> >>> If yes, was 2.6.19 working fine? >> ... >> >> Any oops involving wireless extensions is due to 2.6.20-rc1 and -rc2 not >> having the fix for softmac >> that is necessitated by the 2.6.20 changes in the work structure. > > "Any oops" are very strong words. Yes - but I have seen at least 7 or 8 different occurrences of that bug since the patch was first made available on Dec. 10, and I have seen no bcm43xx oopses from any other cause. > It wouldn't be the first time that we have several similar bug reports, > and it turns out that one is for a completely different issue... > > That's why I asked for testing with 2.6.20-rc2-git1 that includes the > two ieee80211softmac patches. I have been chasing a sound-card issue today and missed that -git1 was out. That version fixes the two outstanding 2.6.20 softmac issues. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
On Sat, Dec 30, 2006 at 03:23:42PM -0600, Larry Finger wrote: > Adrian Bunk wrote: > > On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: > >> Just was loading the bcm43xx module and got the following oops. Note that > >> this card is one of the newer PCI-E cards. If any other info is needed > >> let me know. > > > > Is this issue still present in 2.6.10-rc2-git1? > > > > If yes, was 2.6.19 working fine? >... > > Any oops involving wireless extensions is due to 2.6.20-rc1 and -rc2 not > having the fix for softmac > that is necessitated by the 2.6.20 changes in the work structure. "Any oops" are very strong words. It wouldn't be the first time that we have several similar bug reports, and it turns out that one is for a completely different issue... > The needed patch has now been > pushed by Jeff to Andrew and Linus, and should be in -rc3. In the meantime, > it is attached. That's why I asked for testing with 2.6.20-rc2-git1 that includes the two ieee80211softmac patches. > Larry cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
Adrian Bunk wrote:
> On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote:
>> Just was loading the bcm43xx module and got the following oops. Note that
>> this card is one of the newer PCI-E cards. If any other info is needed
>> let me know.
>
> Is this issue still present in 2.6.10-rc2-git1?
>
> If yes, was 2.6.19 working fine?
>
>> -Aaron
>>
>> ACPI: PCI Interrupt :0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
>> PCI: Setting latency timer of device :0c:00.0 to 64
>> bcm43xx: Chip ID 0x4311, rev 0x1
>> bcm43xx: Number of cores: 4
>> bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
>> bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
>> bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
>> bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
>> bcm43xx: PHY connected
>> bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8
>> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
>> bcm43xx: Radio turned off
>> bcm43xx: Radio turned off
>> Unable to handle kernel NULL pointer dereference at 0011 RIP:
>> [] :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7
>> PGD 33a22067 PUD 3469b067 PMD 0
>> Oops: [1] SMP
>> CPU 0
>> Modules linked in: bcm43xx rng_core ieee80211softmac ieee80211
>> ieee80211_crypt
>> Pid: 4088, comm: iwconfig Not tainted 2.6.20-rc1 #2
>> RIP: 0010:[] []
>> :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7
>> RSP: 0018:810032d3fc28 EFLAGS: 00010202
>> RAX: 0001 RBX: 81003332ebf8 RCX:
>> RDX: RSI: RDI: 810032d3fcd5
>> RBP: 81003332ebf8 R08: 0005 R09: 810032d3fc48
>> R10: R11: 0202 R12: 81003332e4c0
>> R13: R14: R15: 810032d3fe58
>> FS: 2b7863a2d6d0() GS:80697000()
>> knlGS:
>> CS: 0010 DS: ES: CR0: 8005003b
>> CR2: 0011 CR3: 3427 CR4: 26e0
>> Process iwconfig (pid: 4088, threadinfo 810032d3e000, task
>> 810037c4f690)
>> Stack: 81003d87ecc0 0001
>> 80290ede
>> 0404
>>
>> Call Trace:
>> [] touch_atime+0xde/0x130
>> [] ioctl_standard_call+0x26b/0x3b0
>> [] :bcm43xx:bcm43xx_wx_set_encoding+0x0/0x10
>> [] find_get_page+0x29/0x60
>> [] filemap_nopage+0x194/0x350
>> [] :bcm43xx:bcm43xx_wx_set_encoding+0x0/0x10
>> [] wireless_process_ioctl+0x105/0x3d0
>> [] __handle_mm_fault+0x465/0xad0
>> [] dev_ioctl+0x346/0x3c0
>> [] __up_read+0x21/0xb0
>> [] sock_ioctl+0x220/0x240
>> [] do_ioctl+0x2f/0xa0
>> [] vfs_ioctl+0x2a3/0x2e0
>> [] sys_ioctl+0x49/0x80
>> [] error_exit+0x0/0x84
>> [] system_call+0x7e/0x83
>>
>>
>> Code: 48 8b 40 10 48 85 c0 0f 84 01 01 00 00 48 8b 30 b9 04 00 00
>> RIP [] :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7
>> RSP
>> CR2: 0011
Any oops involving wireless extensions is due to 2.6.20-rc1 and -rc2 not having
the fix for softmac
that is necessitated by the 2.6.20 changes in the work structure. The needed
patch has now been
pushed by Jeff to Andrew and Linus, and should be in -rc3. In the meantime, it
is attached.
Larry
From: Ulrich Kunitz <[EMAIL PROTECTED]>
The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.
Larry
net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: > > Just was loading the bcm43xx module and got the following oops. Note that > this card is one of the newer PCI-E cards. If any other info is needed > let me know. Is this issue still present in 2.6.10-rc2-git1? If yes, was 2.6.19 working fine? > -Aaron > > ACPI: PCI Interrupt :0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17 > PCI: Setting latency timer of device :0c:00.0 to 64 > bcm43xx: Chip ID 0x4311, rev 0x1 > bcm43xx: Number of cores: 4 > bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 > bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 > bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 > bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 > bcm43xx: PHY connected > bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 > bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) > bcm43xx: Radio turned off > bcm43xx: Radio turned off > Unable to handle kernel NULL pointer dereference at 0011 RIP: > [] :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7 > PGD 33a22067 PUD 3469b067 PMD 0 > Oops: [1] SMP > CPU 0 > Modules linked in: bcm43xx rng_core ieee80211softmac ieee80211 > ieee80211_crypt > Pid: 4088, comm: iwconfig Not tainted 2.6.20-rc1 #2 > RIP: 0010:[] [] > :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7 > RSP: 0018:810032d3fc28 EFLAGS: 00010202 > RAX: 0001 RBX: 81003332ebf8 RCX: > RDX: RSI: RDI: 810032d3fcd5 > RBP: 81003332ebf8 R08: 0005 R09: 810032d3fc48 > R10: R11: 0202 R12: 81003332e4c0 > R13: R14: R15: 810032d3fe58 > FS: 2b7863a2d6d0() GS:80697000() > knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 0011 CR3: 3427 CR4: 26e0 > Process iwconfig (pid: 4088, threadinfo 810032d3e000, task > 810037c4f690) > Stack: 81003d87ecc0 0001 > 80290ede > 0404 > > Call Trace: > [] touch_atime+0xde/0x130 > [] ioctl_standard_call+0x26b/0x3b0 > [] :bcm43xx:bcm43xx_wx_set_encoding+0x0/0x10 > [] find_get_page+0x29/0x60 > [] filemap_nopage+0x194/0x350 > [] :bcm43xx:bcm43xx_wx_set_encoding+0x0/0x10 > [] wireless_process_ioctl+0x105/0x3d0 > [] __handle_mm_fault+0x465/0xad0 > [] dev_ioctl+0x346/0x3c0 > [] __up_read+0x21/0xb0 > [] sock_ioctl+0x220/0x240 > [] do_ioctl+0x2f/0xa0 > [] vfs_ioctl+0x2a3/0x2e0 > [] sys_ioctl+0x49/0x80 > [] error_exit+0x0/0x84 > [] system_call+0x7e/0x83 > > > Code: 48 8b 40 10 48 85 c0 0f 84 01 01 00 00 48 8b 30 b9 04 00 00 > RIP [] :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7 > RSP > CR2: 0011 > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][ETHTOOL] Add register dump support for SMSC LAN911x/LAN921x
This patch adds support for SMSC's LAN911x and LAN921x families of
embedded ethernet controllers to ethtool's dump registers (-d) command.
This patch is for use with the smsc911x driver.
Signed-off-by: Steve Glendinning <[EMAIL PROTECTED]>
---
Makefile.am|3 +-
ethtool-util.h |4 ++
ethtool.c |2 +
smsc911x.c | 90
4 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 240979e..9f4bbd3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,7 +7,8 @@ sbin_PROGRAMS = ethtool
ethtool_SOURCES = ethtool.c ethtool-copy.h ethtool-util.h \
amd8111e.c de2104x.c e100.c e1000.c \
fec_8xx.c ibm_emac.c ixgb.c natsemi.c \
- pcnet32.c realtek.c tg3.c marvell.c vioc.c
+ pcnet32.c realtek.c tg3.c marvell.c vioc.c\
+ smsc911x.c
dist-hook:
cp $(top_srcdir)/ethtool.spec $(distdir)
diff --git a/ethtool-util.h b/ethtool-util.h
index dcb0c1c..c8f98f4 100644
--- a/ethtool-util.h
+++ b/ethtool-util.h
@@ -56,4 +56,8 @@ int sky2_dump_regs(struct ethtool_drvinfo *info, struct
ethtool_regs *regs);
/* Fabric7 VIOC */
int vioc_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
+/* SMSC LAN911x/LAN921x embedded ethernet controller */
+int smsc911x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs
*regs);
+
#endif
diff --git a/ethtool.c b/ethtool.c
index 6e68009..7e9bf2a 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -13,6 +13,7 @@
* ixgb support by Nicholas Nunley <[EMAIL PROTECTED]>
* amd8111e support by Reeja John <[EMAIL PROTECTED]>
* long arguments by Andi Kleen.
+ * SMSC LAN911x support by Steve Glendinning <[EMAIL PROTECTED]>
*
* TODO:
* * no-args => summary of each device (mii-tool style)
@@ -959,6 +960,7 @@ static struct {
{ "skge", skge_dump_regs },
{ "sky2", sky2_dump_regs },
{ "vioc", vioc_dump_regs },
+{ "smsc911x", smsc911x_dump_regs },
};
static int dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
diff --git a/smsc911x.c b/smsc911x.c
new file mode 100644
index 000..07bf6a8
--- /dev/null
+++ b/smsc911x.c
@@ -0,0 +1,90 @@
+#include
+#include
+#include "ethtool-util.h"
+
+int smsc911x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ unsigned int *smsc_reg = (unsigned int *)regs->data;
+
+ fprintf(stdout, "LAN911x Registers\n");
+ fprintf(stdout, "offset 0x50, ID_REV = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x54, INT_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x58, INT_STS = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x5C, INT_EN = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x60, RESERVED = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x64, BYTE_TEST= 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x68, FIFO_INT = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x6C, RX_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x70, TX_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x74, HW_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x78, RX_DP_CTRL = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x7C, RX_FIFO_INF = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x80, TX_FIFO_INF = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x84, PMT_CTRL = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x88, GPIO_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x8C, GPT_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x90, GPT_CNT = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x94, FPGA_REV = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x98, ENDIAN = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0x9C, FREE_RUN = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0xA0, RX_DROP = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0xA4, MAC_CSR_CMD = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0xA8, MAC_CSR_DATA = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0xAC, AFC_CFG = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0xB0, E2P_CMD = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "offset 0xB4, E2P_DATA = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "MAC Registers\n");
+ fprintf(stdout, "index 1, MAC_CR = 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "index 2, ADDRH= 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "index 3, ADDRL= 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "index 4, HASHH= 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "index 5, HASHL= 0x%08X\n",*smsc_reg++);
+ fprintf(stdout, "index 6, MII_ACC =
Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
In article <[EMAIL PROTECTED]> (at Sat, 30 Dec 2006 20:59:31 +0900), Komuro <[EMAIL PROTECTED]> says: > > Do you see similar issue with other simple application? > > sorry, I don't reproduce this problem on other application. Can you reproduce it with other ftp client and/or server? Anyway... Please provide the output of "netstat -na" command during the transfer, and the output of "lsmod | grep conntrack" (just for sure). More questions: What kind of mode do you use? e.g. PORT/EPRT/LPRT/PASV/EPSV/LPSV When the transfer get stuck, are other communication still working? Are there any workaround? e.g. stop-start vsftpd cycle, ifdown-ifup cycle, rmmod/insmod cycle etc. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Interrogate hardware-enable switch and update LEDs
On Friday 29 December 2006 21:00, Larry Finger wrote:
> The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
> and mini-PCI-E cards. This patch implements a new routine to interrogate the
> radio hardware enabled bit in the interface, logs the initial state and any
> changes in the switch (if debugging enabled), activates the LED to show the
> state, and changes the periodic work handler to provide 1 second response
> to switch changes and to account for changes in the periodic work specs.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John,
>
> This should be applied to wireless-2.6. It is a new feature and is
> not appropriate for 2.6.20-rcX. These changes have been tested on
> a PCMCIA card with no wireless switch, A BCM4306 mini-PCI card, and
> a BCM4311 mini-PCIE card.
>
> Larry
>
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
> if (err)
> goto err_gpio_cleanup;
> bcm43xx_radio_turn_on(bcm);
> + bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> + dprintk(KERN_INFO PFX "Radio %s by hardware\n",
> + (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
>
> bcm43xx_write16(bcm, 0x03E6, 0x);
> err = bcm43xx_phy_init(bcm);
> @@ -3174,9 +3177,24 @@ static void bcm43xx_periodic_every30sec(
>
> static void bcm43xx_periodic_every15sec(struct bcm43xx_private *bcm)
> {
> + bcm43xx_phy_xmitpower(bcm); //FIXME: unless scanning?
> + //TODO for APHY (temperature?)
> +}
> +
> +static void bcm43xx_periodic_every1sec(struct bcm43xx_private *bcm)
> +{
> struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
> struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
> + int radio_hw_enable;
>
> + /* check if radio hardware enabled status changed */
> + radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> + if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) {
> + bcm->radio_hw_enable = radio_hw_enable;
> + dprintk(KERN_INFO PFX "Radio hardware status changed to %s\n",
> +(radio_hw_enable == 0) ? "disabled" : "enabled");
> + bcm43xx_leds_update(bcm, 0);
> + }
> if (phy->type == BCM43xx_PHYTYPE_G) {
> //TODO: update_aci_moving_average
> if (radio->aci_enable && radio->aci_wlan_automatic) {
> @@ -3200,21 +3218,21 @@ static void bcm43xx_periodic_every15sec(
> //TODO: implement rev1 workaround
> }
> }
> - bcm43xx_phy_xmitpower(bcm); //FIXME: unless scanning?
> - //TODO for APHY (temperature?)
> }
>
> static void do_periodic_work(struct bcm43xx_private *bcm)
> {
> - if (bcm->periodic_state % 8 == 0)
> + if (bcm->periodic_state % 120 == 0)
> bcm43xx_periodic_every120sec(bcm);
> - if (bcm->periodic_state % 4 == 0)
> + if (bcm->periodic_state % 60 == 0)
> bcm43xx_periodic_every60sec(bcm);
> - if (bcm->periodic_state % 2 == 0)
> + if (bcm->periodic_state % 30 == 0)
> bcm43xx_periodic_every30sec(bcm);
> - bcm43xx_periodic_every15sec(bcm);
> + if (bcm->periodic_state % 15 == 0)
> + bcm43xx_periodic_every15sec(bcm);
> + bcm43xx_periodic_every1sec(bcm);
>
> - schedule_delayed_work(&bcm->periodic_work, HZ * 15);
> + schedule_delayed_work(&bcm->periodic_work, HZ);
> }
>
> static void bcm43xx_periodic_work_handler(struct work_struct *work)
> @@ -3227,7 +3245,7 @@ static void bcm43xx_periodic_work_handle
> unsigned long orig_trans_start = 0;
>
> mutex_lock(&bcm->mutex);
> - if (unlikely(bcm->periodic_state % 4 == 0)) {
> + if (unlikely(bcm->periodic_state % 60 == 0)) {
> /* Periodic work will take a long time, so we want it to
>* be preemtible.
>*/
> @@ -3259,7 +3277,7 @@ static void bcm43xx_periodic_work_handle
>
> do_periodic_work(bcm);
>
> - if (unlikely(bcm->periodic_state % 4 == 0)) {
> + if (unlikely(bcm->periodic_state % 60 == 0)) {
> spin_lock_irqsave(&bcm->irq_lock, flags);
> tasklet_enable(&bcm->isr_tasklet);
> bcm43xx_interrupt_enable(bcm, savedirqs);
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> @@ -65,6 +65,22 @@ void bcm43xx_radio_init2060(struct bcm43
> void bcm43xx_radio_turn_on(struct bcm43xx_private *bcm);
> void bcm43xx_radio_turn_off(struct bcm43xx_private *bcm);
>
> +static
