[PATCH] bcm43xx: suspend MAC while executing long pwork

2006-06-12 Thread Michael Buesch
Hi John,
Please queue this for 2.6.18.

--

Suspend MAC (and make MAC-suspend refcounting) when doing
long periodic work.
On long periodic work, we disable IRQs on the device, so
we don't want the MAC to stay operating and probably miss
packets due do non-delivery of interrupts.

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx.h2006-06-05 
18:19:59.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-06-12 
16:20:28.0 +0200
@@ -723,6 +723,8 @@
u32 irq_savedstate;
/* Link Quality calculation context. */
struct bcm43xx_noise_calculation noisecalc;
+   /* if  0 MAC is suspended. if == 0 MAC is enabled. */
+   int mac_suspended;
 
/* Threshold values. */
//TODO: The RTS thr has to be _used_. Currently, it is only set via WX.
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c   
2006-06-05 20:17:36.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c2006-06-12 
16:41:41.0 +0200
@@ -2284,13 +2284,17 @@
 /* http://bcm-specs.sipsolutions.net/EnableMac */
 void bcm43xx_mac_enable(struct bcm43xx_private *bcm)
 {
-   bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
-   bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
-   | BCM43xx_SBF_MAC_ENABLED);
-   bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON, BCM43xx_IRQ_READY);
-   bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* dummy read */
-   bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
-   bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
+   bcm-mac_suspended--;
+   assert(bcm-mac_suspended = 0);
+   if (bcm-mac_suspended == 0) {
+   bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
+   bcm43xx_read32(bcm, 
BCM43xx_MMIO_STATUS_BITFIELD)
+   | BCM43xx_SBF_MAC_ENABLED);
+   bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON, 
BCM43xx_IRQ_READY);
+   bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* dummy 
read */
+   bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read 
*/
+   bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
+   }
 }
 
 /* http://bcm-specs.sipsolutions.net/SuspendMAC */
@@ -2299,18 +2303,23 @@
int i;
u32 tmp;
 
-   bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
-   bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
-   bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
-~BCM43xx_SBF_MAC_ENABLED);
-   bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
-   for (i = 10; i; i--) {
-   tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
-   if (tmp  BCM43xx_IRQ_READY)
-   return;
-   udelay(10);
+   assert(bcm-mac_suspended = 0);
+   if (bcm-mac_suspended == 0) {
+   bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
+   bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
+   bcm43xx_read32(bcm, 
BCM43xx_MMIO_STATUS_BITFIELD)
+~BCM43xx_SBF_MAC_ENABLED);
+   bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read 
*/
+   for (i = 10; i; i--) {
+   tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
+   if (tmp  BCM43xx_IRQ_READY)
+   goto out;
+   udelay(10);
+   }
+   printkl(KERN_ERR PFX MAC suspend failed\n);
}
-   printkl(KERN_ERR PFX MAC suspend failed\n);
+out:
+   bcm-mac_suspended++;
 }
 
 void bcm43xx_set_iwmode(struct bcm43xx_private *bcm,
@@ -3168,8 +3177,10 @@
/* Periodic work will take a long time, so we want it to
 * be preemtible.
 */
-   bcm43xx_lock_irqonly(bcm, flags);
netif_stop_queue(bcm-net_dev);
+   synchronize_net();
+   bcm43xx_lock_irqonly(bcm, flags);
+   bcm43xx_mac_suspend(bcm);
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_freeze_txqueues(bcm);
savedirqs = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
@@ -3192,6 +3203,7 @@
bcm43xx_interrupt_enable(bcm, savedirqs);
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_thaw_txqueues(bcm);
+   bcm43xx_mac_enable(bcm);
}

Re: Anyone got a 4306 working properly?

2006-06-12 Thread Larry Finger

Michael Buesch wrote:

On Sunday 04 June 2006 21:49, Mattias Nissler wrote:

On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote:

On Sunday 04 June 2006 21:30, Mattias Nissler wrote:

Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and
donate the old one if somebody can tell me where to buy a new mini-PCI
card for my laptop.

http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem
Seems to be a 4318. Keep in mind that this is not 100% supported, too.

What about a new airport extreme card from apple? I'll check whether it
fits and go for that if it does.


The airport has a special connector that only fits into apple hardware.
You could also buy an ipw2200. That works good, too.



FWIW, now that I found the problem associating with a Linksys WRT54G V5, I have been able to run my 
Linksys WPC54G again using WPA-PSK. At startup, the following details are reported:


bcm43xx: Chip ID 0x4306, rev 0x2
bcm43xx: Number of cores: 6
bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled
bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
bcm43xx: Ignoring additional 802.11 core.
bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)

With the June 5 versions of the bcm43xx: redesign locking and bcm43xx: preemptible periodic work 
patches applied to the 2.6.17-rc6 kernel, I am running with no problems. I ran 50,000 pings to my AP 
with no losses and no duplicates. The only thing being logged is an occasional TKIP: replay 
detected message, but they don't seem to do any harm.


Thanks for your efforts.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[PATCH] AP (master) mode fixed (resubmit)

2006-06-12 Thread Alexander Tsvyashchenko
Hello All,

Here is AP mode patch that is adapted to the current wireless-dev version
of bcm43xx.

Signed-off-by: Alexander Tsvyashchenko [EMAIL PROTECTED]

Differencies to the previous version:

1) This version deals with TIM in cleaner way (though, PS mode is still
not supported) - instead of patching dscape stack to skip TIM
generation, it strips TIM when writing probe response template and
leaves it when writing beacon template.

2) As in current dscape stack management interface seems to be no longer
passed to the driver, all interface handling is left as it is, no
changes there should be made anymore.

3) cpu_to_be/le32 were added in the places that seem appropriate for that
(but I still not sure about that enough; my CPU is LE)

4) This version includes some fixes to CONFIG_BCM947XX SPROM code: for
each value to be read from nvram it checks whether it is present or not
and uses it only in the case it is present. This change is not strictly
related to AP mode, but just is added as it seems to be more correct,
and I had to do it for my hardware anyway.

5) To make debugging of LE/BE issues easier, I've left some debugging
output in templates generation, it can be stripped once all things are
verified  fixed.

Known limitations:

1) PS mode is not supported.

Testing instructions:

Although my previous patch to hostapd to make it interoperable with
bcm43xx  dscape has been merged already in their CVS version, due to
the subsequent changes in dscape stack current hostapd is again
incompartible :-( So, to test this patch, the patch to hostapd should be
applied.
I used hostapd snapshot 0.5-2006-06-10, patch for it is attached.
The patch is very hacky and requires tricky way to bring everything up,
but as dscape stack is changed quite constantly, I just do not want to
waste time fixing it in proper way only to find a week later that
dscape handling of master interface was changed completely once more and
everything is broken again ;-)

The patch for dscape stack that is attached is not 100% necessary, but it
seems to allow operating clients that request PS mode to be enabled at
AP (verified with PDA client), the only thing it contains is disabling
actual PS handling in dscape.

So, the following sequence should be used to test AP mode:

1) take hostapd snapshot 0.5-2006-06-10 (other recent versions should
work OK also, though), apply the hostapd patch attached.

2) Insert modules (80211, rate_control and bcm43xx-d80211)

3) iwconfig wlan0 mode master

4) ifconfig wlan0 up (this should be done by hostapd actually, but
its operation with current dscape stack seems to be broken)

5) Start hostapd (f.e. hostapd -B /etc/hostapd.conf), config file can
look like:
=
interface=wlan0
driver=devicescape
ssid=OpenWrt
channel=1
send_probe_response=0
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
debug=4
=

6) iwconfig wlan0 essid your-SSID-name (this also should not be
required, but current combination of hostapd + dscape doesn't seem to
generate config_interface callback when setting beacon, so this is
required just to force call of config_interface).

That's should be it.

Please comment!

Good luck!  Alexander


hostapd-dscape.patch
Description: Binary data


d80211-ap-mode.patch
Description: Binary data


bcm43xx-ap-mode.patch
Description: Binary data