Re: quetion on beacon irq and multibss
On Apr 10, 2009, at 12:44 AM, Michael Buesch wrote: > On Friday 10 April 2009 00:34:32 Francesco Gringoli wrote: >> I was wondering about the beacon IRQ and those functions inside b43 >> that handle such interrupt. In which situations apart the first >> installation of the beacon in template ram, is handle_irq_beacon >> called inside the b43 driver? E.g., openfirmware does not raise the >> beacon irq but beaconing is correct and it has no problem in AP mode. >> Is this function useful for multibss? e.g., after we send a beacon >> the kernel can upload the next one and so on... > > It's raised when the beacon needs to be updated. Think about TIM, > for example. > This is not used for MBSS. I thought this was handled inside the firmware so we put the same refreshing code back and forth from template to shm for the tim part. Ok but what`about MBSS? Is it already implemented in b43? I found some old patches from Johannes but they required fw hacking, I can't find traces of them inside the current kernel. So I would assume MBSS is not yet implemented. > If openfw does not raise the interrupt, PS most likely is broken and > the > firmware cannot work on AP with PS stations associated. Uh, interesting. I completely missed this. I must say I'm not familiar with PS. Many thanks, -FG > > > -- > Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Apr 10, 2009, at 12:42 AM, Michael Buesch wrote: > On Friday 10 April 2009 00:28:48 Francesco Gringoli wrote: >> You mean that it misses to transmit some frames? Do you have >> hypotheses on why AP mode should complete change the behavior of the >> board from "good enough" to "not working correctly"? > > Practice shows this. It's as simple as that. > Try it, if you don't trust me. No no, I didn't want to say that I don't trust what you say, I too experienced problems with 4318 on linksys. I'm wondering what could be the problem, I was asking if you have any conjecture about. >>> Of course, there always are exceptions to these rules, because there >>> are about >>> a million completely different 4318 and and 4306 cards out there. >>> So you might be lucky to pick one of the few 4318 that works well in >>> AP mode, or >>> you might pick one of the few 4306 that don't work too well. >> Ok, that could be. I have only 4318 branded as Asus, they are all >> equal. Probably the fact the linksys does not work in AP mode confirm >> what you say. > > I mostly use linksys products for testing. > But I think I could give the asus card a try, if you say it works > better in AP mode. Ok that could be nice. Mine is a mini-pci card, it was a very common board included in WL500G Premium AP. >> I have noticed, however a strange fact with these 4318 based linksys: >> when I set one of them in AP mode, beaconing is perfect and I can >> join >> it from other stations. When I ping the AP from stations I get echo >> reply. If, instead, I ping stations from the AP, no packet is sent! >> at >> all; if I telnet from stations to the AP, e.g., to port 22, 3whs ends >> but then the TCP session dies. The strange fact is that it seems that >> there are problems for all the frames whose generation involves a >> contest switching from userspace to kernel, in other words a complete >> cross of the mac80211+b43 layers. If instead, on the AP, I completely >> bypass the network stack and directly ask b43 to transmit a frame >> (with a modified b43) the frame is transmitted, at every rate I >> choose >> (I choose the rate inside the kernel code, I'm not referring to the >> rate set by iwconfig). >> >> Do you have some of these flawed 4318? > > I don't think the type of device influences whether packets are > dropped > inside of some random kernel subsystem. > > -- > Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: quetion on beacon irq and multibss
On Friday 10 April 2009 00:34:32 Francesco Gringoli wrote: > I was wondering about the beacon IRQ and those functions inside b43 > that handle such interrupt. In which situations apart the first > installation of the beacon in template ram, is handle_irq_beacon > called inside the b43 driver? E.g., openfirmware does not raise the > beacon irq but beaconing is correct and it has no problem in AP mode. > Is this function useful for multibss? e.g., after we send a beacon > the kernel can upload the next one and so on... It's raised when the beacon needs to be updated. Think about TIM, for example. This is not used for MBSS. If openfw does not raise the interrupt, PS most likely is broken and the firmware cannot work on AP with PS stations associated. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Friday 10 April 2009 00:28:48 Francesco Gringoli wrote: > You mean that it misses to transmit some frames? Do you have > hypotheses on why AP mode should complete change the behavior of the > board from "good enough" to "not working correctly"? Practice shows this. It's as simple as that. Try it, if you don't trust me. > > > > Of course, there always are exceptions to these rules, because there > > are about > > a million completely different 4318 and and 4306 cards out there. > > So you might be lucky to pick one of the few 4318 that works well in > > AP mode, or > > you might pick one of the few 4306 that don't work too well. > Ok, that could be. I have only 4318 branded as Asus, they are all > equal. Probably the fact the linksys does not work in AP mode confirm > what you say. I mostly use linksys products for testing. But I think I could give the asus card a try, if you say it works better in AP mode. > I have noticed, however a strange fact with these 4318 based linksys: > when I set one of them in AP mode, beaconing is perfect and I can join > it from other stations. When I ping the AP from stations I get echo > reply. If, instead, I ping stations from the AP, no packet is sent! at > all; if I telnet from stations to the AP, e.g., to port 22, 3whs ends > but then the TCP session dies. The strange fact is that it seems that > there are problems for all the frames whose generation involves a > contest switching from userspace to kernel, in other words a complete > cross of the mac80211+b43 layers. If instead, on the AP, I completely > bypass the network stack and directly ask b43 to transmit a frame > (with a modified b43) the frame is transmitted, at every rate I choose > (I choose the rate inside the kernel code, I'm not referring to the > rate set by iwconfig). > > Do you have some of these flawed 4318? I don't think the type of device influences whether packets are dropped inside of some random kernel subsystem. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
quetion on beacon irq and multibss
Michael, I was wondering about the beacon IRQ and those functions inside b43 that handle such interrupt. In which situations apart the first installation of the beacon in template ram, is handle_irq_beacon called inside the b43 driver? E.g., openfirmware does not raise the beacon irq but beaconing is correct and it has no problem in AP mode. Is this function useful for multibss? e.g., after we send a beacon the kernel can upload the next one and so on... Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Apr 9, 2009, at 11:56 PM, Michael Buesch wrote: > On Thursday 09 April 2009 23:47:25 Francesco Gringoli wrote: >> >> On Apr 6, 2009, at 5:04 PM, Michael Buesch wrote: >> > > Well, you know that lots of cards don't work correctly with b43. > I bet you're using a BCM4318 flavor. > Sadly, yes, it is a BCM4318. I've tried moving further away from the AP, as well as decreasing the txpower output.. neither seemed to help any. I suspect something else may be the cause of the poor performance that I'm seeing. I'll try to rule out the card as a problem tonight by setting up an Ad-Hoc network under Windows XP. If I observe good performance then maybe b43 is the issue... In which case.. I'll start the painful process of comparing the Windows driver to b43. If I find any discrepancies, I'll send them to the reverse engineers to be posted with the rest of the specs. Then maybe you or someone else can make the appropriate changes to b43. >>> >>> 4318 currently is not usable in AP mode due to low but (for AP mode) >>> significant >>> packet loss in high transmission rates. >>> I doubt this will change unless Broadcom releases some code. >> Michael, >> >> is this for all 4318? I'm doing extensive testing these days with >> both >> 4318 and 4306 on x86. I always get very good performance with latest >> hostapd on 2.6.29-rc2-wl. I can also reach maximum theoretical >> throughput if I choose channel 14 to limit interferences. I get max >> throughput independently of the board running hostapd and traffic >> direction. >> >> All this applies to both AP and stations being x86 linux based, e.g., >> if I try to join an x86 AP running b43 from my macbook I can get good >> performance only occasionally. >> >> Good performance also if the station is a linksys wrt54gl (it uses a >> 4318). I can't instead run hostapd successfully on these linksys. > > 4318 is good enough for STA mode, but in AP mode it doesn't work > correctly, because > it simply loses too many packets. So it loses important management > frames, etc... . > If you limit the TX rate to 24M it becomes usable, however. > 4306 is _much_ better in AP mode. You mean that it misses to transmit some frames? Do you have hypotheses on why AP mode should complete change the behavior of the board from "good enough" to "not working correctly"? The only difference between station and AP mode AFAIK is that AP mode honors the TBTT condition and transmit the beacon when a beacon is needed. I say honor since that condition and the other about beacon needed are raised also in station mode but they are not handled. I'm confused. > > > Of course, there always are exceptions to these rules, because there > are about > a million completely different 4318 and and 4306 cards out there. > So you might be lucky to pick one of the few 4318 that works well in > AP mode, or > you might pick one of the few 4306 that don't work too well. Ok, that could be. I have only 4318 branded as Asus, they are all equal. Probably the fact the linksys does not work in AP mode confirm what you say. I have noticed, however a strange fact with these 4318 based linksys: when I set one of them in AP mode, beaconing is perfect and I can join it from other stations. When I ping the AP from stations I get echo reply. If, instead, I ping stations from the AP, no packet is sent! at all; if I telnet from stations to the AP, e.g., to port 22, 3whs ends but then the TCP session dies. The strange fact is that it seems that there are problems for all the frames whose generation involves a contest switching from userspace to kernel, in other words a complete cross of the mac80211+b43 layers. If instead, on the AP, I completely bypass the network stack and directly ask b43 to transmit a frame (with a modified b43) the frame is transmitted, at every rate I choose (I choose the rate inside the kernel code, I'm not referring to the rate set by iwconfig). Do you have some of these flawed 4318? -Francesco > > > -- > Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Thursday 09 April 2009 23:47:25 Francesco Gringoli wrote: > > On Apr 6, 2009, at 5:04 PM, Michael Buesch wrote: > > >>> > >>> Well, you know that lots of cards don't work correctly with b43. > >>> I bet you're using a BCM4318 flavor. > >>> > >> > >> Sadly, yes, it is a BCM4318. I've tried moving further away from the > >> AP, as well as decreasing the txpower output.. neither seemed to help > >> any. I suspect something else may be the cause of the poor > >> performance > >> that I'm seeing. I'll try to rule out the card as a problem tonight > >> by > >> setting up an Ad-Hoc network under Windows XP. If I observe good > >> performance then maybe b43 is the issue... In which case.. I'll start > >> the painful process of comparing the Windows driver to b43. If I find > >> any discrepancies, I'll send them to the reverse engineers to be > >> posted with the rest of the specs. Then maybe you or someone else can > >> make the appropriate changes to b43. > > > > 4318 currently is not usable in AP mode due to low but (for AP mode) > > significant > > packet loss in high transmission rates. > > I doubt this will change unless Broadcom releases some code. > Michael, > > is this for all 4318? I'm doing extensive testing these days with both > 4318 and 4306 on x86. I always get very good performance with latest > hostapd on 2.6.29-rc2-wl. I can also reach maximum theoretical > throughput if I choose channel 14 to limit interferences. I get max > throughput independently of the board running hostapd and traffic > direction. > > All this applies to both AP and stations being x86 linux based, e.g., > if I try to join an x86 AP running b43 from my macbook I can get good > performance only occasionally. > > Good performance also if the station is a linksys wrt54gl (it uses a > 4318). I can't instead run hostapd successfully on these linksys. 4318 is good enough for STA mode, but in AP mode it doesn't work correctly, because it simply loses too many packets. So it loses important management frames, etc... . If you limit the TX rate to 24M it becomes usable, however. 4306 is _much_ better in AP mode. Of course, there always are exceptions to these rules, because there are about a million completely different 4318 and and 4306 cards out there. So you might be lucky to pick one of the few 4318 that works well in AP mode, or you might pick one of the few 4306 that don't work too well. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Apr 6, 2009, at 5:04 PM, Michael Buesch wrote: >>> >>> Well, you know that lots of cards don't work correctly with b43. >>> I bet you're using a BCM4318 flavor. >>> >> >> Sadly, yes, it is a BCM4318. I've tried moving further away from the >> AP, as well as decreasing the txpower output.. neither seemed to help >> any. I suspect something else may be the cause of the poor >> performance >> that I'm seeing. I'll try to rule out the card as a problem tonight >> by >> setting up an Ad-Hoc network under Windows XP. If I observe good >> performance then maybe b43 is the issue... In which case.. I'll start >> the painful process of comparing the Windows driver to b43. If I find >> any discrepancies, I'll send them to the reverse engineers to be >> posted with the rest of the specs. Then maybe you or someone else can >> make the appropriate changes to b43. > > 4318 currently is not usable in AP mode due to low but (for AP mode) > significant > packet loss in high transmission rates. > I doubt this will change unless Broadcom releases some code. Michael, is this for all 4318? I'm doing extensive testing these days with both 4318 and 4306 on x86. I always get very good performance with latest hostapd on 2.6.29-rc2-wl. I can also reach maximum theoretical throughput if I choose channel 14 to limit interferences. I get max throughput independently of the board running hostapd and traffic direction. All this applies to both AP and stations being x86 linux based, e.g., if I try to join an x86 AP running b43 from my macbook I can get good performance only occasionally. Good performance also if the station is a linksys wrt54gl (it uses a 4318). I can't instead run hostapd successfully on these linksys. Cheers, -FG > > > I suggest you just buy another card instead of wasting months of > time on trying > to get this to work. > > -- > Greetings, Michael. > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with 2.6.30-rc1
* Larry Finger [090408 16:18 -0500] > > If you are having problems with wireless networking using 2.6.30-rc1 from > Linus's Linux-2.6 git tree, the fix is the following (Note: This is _NOT_ > needed > for wireless-testing!!!): > > --- > Fix try_then_request_module to use waiting __request_module again. Tried that patch. B43 is loaded but there are probs with alsa and hald left, though. I wait for rc2, Maybe test git? . Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RFC] b44: Add fw capabilities
On Apr 9, 2009, at 11:05 PM, Lorenzo Nava wrote: > Hi, > > I think that Francesco agrees with me, so 0x42 is ok for firmware > capabilities. It's ok for me. -FG > > > Cheers, > > Lorenzo > > On Apr 9, 2009, at 1:26 PM, Michael Buesch wrote: > >> On Thursday 09 April 2009 12:36:42 Francesco Gringoli wrote: >>> On Apr 9, 2009, at 12:18 PM, Michael Buesch wrote: >>> On Wednesday 08 April 2009 02:11:16 Michael Buesch wrote: > Completely untested patch to implement firmware capabilities > and automagic QoS-disabling. > So could somebody who uses opensource fw test this? Module parameter qos=0 should not be needed anymore. So please test opensource fw with qos=1. >>> Hi Michael, >>> >>> cool! These are excerpts from dmesg. All the times connectivity >>> was ok. >> >> Ok nice. >> If you guys think 0x42 still is a good SHM offset, I'll submit it >> upstream. >> >> -- >> Greetings, Michael. >> ___ >> Bcm43xx-dev mailing list >> Bcm43xx-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RFC] b44: Add fw capabilities
Hi, I think that Francesco agrees with me, so 0x42 is ok for firmware capabilities. Cheers, Lorenzo On Apr 9, 2009, at 1:26 PM, Michael Buesch wrote: > On Thursday 09 April 2009 12:36:42 Francesco Gringoli wrote: >> On Apr 9, 2009, at 12:18 PM, Michael Buesch wrote: >> >>> On Wednesday 08 April 2009 02:11:16 Michael Buesch wrote: Completely untested patch to implement firmware capabilities and automagic QoS-disabling. >>> >>> So could somebody who uses opensource fw test this? >>> >>> Module parameter qos=0 should not be needed anymore. So please test >>> opensource fw >>> with qos=1. >> Hi Michael, >> >> cool! These are excerpts from dmesg. All the times connectivity was >> ok. > > Ok nice. > If you guys think 0x42 still is a good SHM offset, I'll submit it > upstream. > > -- > Greetings, Michael. > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RFC] b44: Add fw capabilities
On Thursday 09 April 2009 12:36:42 Francesco Gringoli wrote: > On Apr 9, 2009, at 12:18 PM, Michael Buesch wrote: > > > On Wednesday 08 April 2009 02:11:16 Michael Buesch wrote: > >> Completely untested patch to implement firmware capabilities > >> and automagic QoS-disabling. > >> > > > > So could somebody who uses opensource fw test this? > > > > Module parameter qos=0 should not be needed anymore. So please test > > opensource fw > > with qos=1. > Hi Michael, > > cool! These are excerpts from dmesg. All the times connectivity was ok. Ok nice. If you guys think 0x42 still is a good SHM offset, I'll submit it upstream. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RFC] b44: Add fw capabilities
On Apr 9, 2009, at 12:18 PM, Michael Buesch wrote:
> On Wednesday 08 April 2009 02:11:16 Michael Buesch wrote:
>> Completely untested patch to implement firmware capabilities
>> and automagic QoS-disabling.
>>
>
> So could somebody who uses opensource fw test this?
>
> Module parameter qos=0 should not be needed anymore. So please test
> opensource fw
> with qos=1.
Hi Michael,
cool! These are excerpts from dmesg. All the times connectivity was ok.
Cheers,
-FG
modprobe b43 qos=0
[ 194.368042] b43-phy1: Loading OpenSource firmware version 410.31754
[ 194.368054] b43-phy1: Hardware crypto acceleration not supported by
firmware
[ 194.368060] b43-phy1: QoS not supported by firmware
modprobe b43
[ 264.328047] b43-phy3: Loading OpenSource firmware version 410.31754
[ 264.328058] b43-phy3: Hardware crypto acceleration not supported by
firmware
[ 264.328064] b43-phy3: QoS not supported by firmware
modprobe b43 qos=1
[ 309.224044] b43-phy5: Loading OpenSource firmware version 410.31754
[ 309.224056] b43-phy5: Hardware crypto acceleration not supported by
firmware
[ 309.224062] b43-phy5: QoS not supported by firmware
>
>
>
>> Index: wireless-testing/drivers/net/wireless/b43/b43.h
>> ===
>> --- wireless-testing.orig/drivers/net/wireless/b43/b43.h 2009-04-07
>> 19:52:34.0 +0200
>> +++ wireless-testing/drivers/net/wireless/b43/b43.h 2009-04-08
>> 01:57:58.0 +0200
>> @@ -163,6 +163,7 @@ enum {
>> #define B43_SHM_SH_WLCOREREV 0x0016 /* 802.11 core revision */
>> #define B43_SHM_SH_PCTLWDPOS 0x0008
>> #define B43_SHM_SH_RXPADOFF 0x0034 /* RX Padding data offset (PIO
>> only) */
>> +#define B43_SHM_SH_FWCAPA 0x0042 /* Firmware capabilities
>> (Opensource firmware only) */
>> #define B43_SHM_SH_PHYVER0x0050 /* PHY version */
>> #define B43_SHM_SH_PHYTYPE 0x0052 /* PHY type */
>> #define B43_SHM_SH_ANTSWAP 0x005C /* Antenna swap threshold */
>> @@ -297,6 +298,10 @@ enum {
>> #define B43_HF_MLADVW0x0010ULL /* N PHY ML ADV
>> workaround
>> (rev >= 13 only) */
>> #define B43_HF_PR45960W 0x0800ULL /* PR 45960
>> workaround
>> (rev >= 13 only) */
>>
>> +/* Firmware capabilities field in SHM (Opensource firmware only) */
>> +#define B43_FWCAPA_HWCRYPTO 0x0001
>> +#define B43_FWCAPA_QOS 0x0002
>> +
>> /* MacFilter offsets. */
>> #define B43_MACFILTER_SELF 0x
>> #define B43_MACFILTER_BSSID 0x0003
>> @@ -596,6 +601,13 @@ struct b43_wl {
>> /* Pointer to the ieee80211 hardware data structure */
>> struct ieee80211_hw *hw;
>>
>> +/* The number of queues that were registered with the mac80211
>> subsystem
>> + * initially. This is a backup copy of hw->queues in case hw-
>> >queues has
>> + * to be dynamically lowered at runtime (Firmware does not
>> support QoS).
>> + * hw->queues has to be restored to the original value before
>> unregistering
>> + * from the mac80211 subsystem. */
>> +u16 mac80211_initially_registered_queues;
>> +
>> struct mutex mutex;
>> spinlock_t irq_lock;
>> /* R/W lock for data transmission.
>> @@ -752,6 +764,8 @@ struct b43_wldev {
>> bool dfq_valid; /* Directed frame queue valid (IBSS PS mode,
>> ATIM) */
>> bool radio_hw_enable; /* saved state of radio hardware enabled
>> state */
>> bool suspend_in_progress; /* TRUE, if we are in a suspend/resume
>> cycle */
>> +bool qos_enabled; /* TRUE, if QoS is used. */
>> +bool hwcrypto_enabled; /* TRUE, if HW crypto acceleration is
>> enabled. */
>>
>> /* PHY/Radio device. */
>> struct b43_phy phy;
>> Index: wireless-testing/drivers/net/wireless/b43/dma.c
>> ===
>> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c 2009-04-07
>> 19:58:22.0 +0200
>> +++ wireless-testing/drivers/net/wireless/b43/dma.c 2009-04-08
>> 01:53:56.0 +0200
>> @@ -1285,7 +1285,7 @@ static struct b43_dmaring *select_ring_b
>> {
>> struct b43_dmaring *ring;
>>
>> -if (b43_modparam_qos) {
>> +if (dev->qos_enabled) {
>> /* 0 = highest priority */
>> switch (queue_prio) {
>> default:
>> Index: wireless-testing/drivers/net/wireless/b43/main.c
>> ===
>> --- wireless-testing.orig/drivers/net/wireless/b43/main.c
>> 2009-04-07 19:55:03.0 +0200
>> +++ wireless-testing/drivers/net/wireless/b43/main.c 2009-04-08
>> 02:02:19.0 +0200
>> @@ -80,8 +80,8 @@ static int modparam_nohwcrypt;
>> module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
>> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
>>
>> -int b43_modparam_qos = 1;
>> -module_param_named(qos, b43_mo
Re: [PATCH, RFC] b44: Add fw capabilities
On Wednesday 08 April 2009 02:11:16 Michael Buesch wrote:
> Completely untested patch to implement firmware capabilities
> and automagic QoS-disabling.
>
So could somebody who uses opensource fw test this?
Module parameter qos=0 should not be needed anymore. So please test opensource
fw
with qos=1.
> Index: wireless-testing/drivers/net/wireless/b43/b43.h
> ===
> --- wireless-testing.orig/drivers/net/wireless/b43/b43.h 2009-04-07
> 19:52:34.0 +0200
> +++ wireless-testing/drivers/net/wireless/b43/b43.h 2009-04-08
> 01:57:58.0 +0200
> @@ -163,6 +163,7 @@ enum {
> #define B43_SHM_SH_WLCOREREV 0x0016 /* 802.11 core revision */
> #define B43_SHM_SH_PCTLWDPOS 0x0008
> #define B43_SHM_SH_RXPADOFF 0x0034 /* RX Padding data offset (PIO
> only) */
> +#define B43_SHM_SH_FWCAPA0x0042 /* Firmware capabilities
> (Opensource firmware only) */
> #define B43_SHM_SH_PHYVER0x0050 /* PHY version */
> #define B43_SHM_SH_PHYTYPE 0x0052 /* PHY type */
> #define B43_SHM_SH_ANTSWAP 0x005C /* Antenna swap threshold */
> @@ -297,6 +298,10 @@ enum {
> #define B43_HF_MLADVW0x0010ULL /* N PHY ML ADV
> workaround (rev >= 13 only) */
> #define B43_HF_PR45960W 0x0800ULL /* PR 45960
> workaround (rev >= 13 only) */
>
> +/* Firmware capabilities field in SHM (Opensource firmware only) */
> +#define B43_FWCAPA_HWCRYPTO 0x0001
> +#define B43_FWCAPA_QOS 0x0002
> +
> /* MacFilter offsets. */
> #define B43_MACFILTER_SELF 0x
> #define B43_MACFILTER_BSSID 0x0003
> @@ -596,6 +601,13 @@ struct b43_wl {
> /* Pointer to the ieee80211 hardware data structure */
> struct ieee80211_hw *hw;
>
> + /* The number of queues that were registered with the mac80211 subsystem
> + * initially. This is a backup copy of hw->queues in case hw->queues has
> + * to be dynamically lowered at runtime (Firmware does not support QoS).
> + * hw->queues has to be restored to the original value before
> unregistering
> + * from the mac80211 subsystem. */
> + u16 mac80211_initially_registered_queues;
> +
> struct mutex mutex;
> spinlock_t irq_lock;
> /* R/W lock for data transmission.
> @@ -752,6 +764,8 @@ struct b43_wldev {
> bool dfq_valid; /* Directed frame queue valid (IBSS PS mode,
> ATIM) */
> bool radio_hw_enable; /* saved state of radio hardware enabled state
> */
> bool suspend_in_progress; /* TRUE, if we are in a suspend/resume
> cycle */
> + bool qos_enabled; /* TRUE, if QoS is used. */
> + bool hwcrypto_enabled; /* TRUE, if HW crypto acceleration is
> enabled. */
>
> /* PHY/Radio device. */
> struct b43_phy phy;
> Index: wireless-testing/drivers/net/wireless/b43/dma.c
> ===
> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c 2009-04-07
> 19:58:22.0 +0200
> +++ wireless-testing/drivers/net/wireless/b43/dma.c 2009-04-08
> 01:53:56.0 +0200
> @@ -1285,7 +1285,7 @@ static struct b43_dmaring *select_ring_b
> {
> struct b43_dmaring *ring;
>
> - if (b43_modparam_qos) {
> + if (dev->qos_enabled) {
> /* 0 = highest priority */
> switch (queue_prio) {
> default:
> Index: wireless-testing/drivers/net/wireless/b43/main.c
> ===
> --- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-04-07
> 19:55:03.0 +0200
> +++ wireless-testing/drivers/net/wireless/b43/main.c 2009-04-08
> 02:02:19.0 +0200
> @@ -80,8 +80,8 @@ static int modparam_nohwcrypt;
> module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
>
> -int b43_modparam_qos = 1;
> -module_param_named(qos, b43_modparam_qos, int, 0444);
> +static int modparam_qos = 1;
> +module_param_named(qos, modparam_qos, int, 0444);
> MODULE_PARM_DESC(qos, "Enable QOS support (default on)");
>
> static int modparam_btcoex = 1;
> @@ -538,6 +538,13 @@ void b43_hf_write(struct b43_wldev *dev,
> b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_HOSTFHI, hi);
> }
>
> +/* Read the firmware capabilities bitmask (Opensource firmware only) */
> +static u16 b43_fwcapa_read(struct b43_wldev *dev)
> +{
> + B43_WARN_ON(!dev->fw.opensource);
> + return b43_shm_read16(dev, B43_SHM_SHARED, B43_SHM_SH_FWCAPA);
> +}
> +
> void b43_tsf_read(struct b43_wldev *dev, u64 *tsf)
> {
> u32 low, high;
> @@ -2330,12 +2337,34 @@ static int b43_upload_microcode(struct b
> dev->fw.patch = fwpatch;
> dev->fw.opensource = (fwdate == 0x);
>
> + /* Default to use-all-queues. */
> + dev->wl->hw->queues =
