[PATCH] bcm43xx:Eliminate some 'G Mode Enable' magic numbers
In code manipulating the TM State Low register of 802.11 cores, two
different magic numbers are used to reference the 'G Mode Enable' bit.
One of these, 0x2000, is clear, but the other, (0x800 << 18), is not.
This patch replaces both types with a defined constant. In addition, two
bits in the TM State High registers are given definitions to help in
following the code.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -277,11 +277,14 @@
#define BCM43xx_SBTMSTATELOW_REJECT0x02
#define BCM43xx_SBTMSTATELOW_CLOCK 0x1
#define BCM43xx_SBTMSTATELOW_FORCE_GATE_CLOCK 0x2
+#define BCM43xx_SBTMSTATELOW_G_MODE_ENABLE 0x2000
/* sbtmstatehigh state flags */
#define BCM43xx_SBTMSTATEHIGH_SERROR 0x0001
#define BCM43xx_SBTMSTATEHIGH_BUSY 0x0004
#define BCM43xx_SBTMSTATEHIGH_TIMEOUT 0x0020
+#define BCM43xx_SBTMSTATEHIGH_G_PHY_AVAIL 0x0001
+#define BCM43xx_SBTMSTATEHIGH_A_PHY_AVAIL 0x0002
#define BCM43xx_SBTMSTATEHIGH_COREFLAGS0x1FFF
#define BCM43xx_SBTMSTATEHIGH_DMA64BIT 0x1000
#define BCM43xx_SBTMSTATEHIGH_GATEDCLK 0x2000
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -168,16 +168,16 @@ int bcm43xx_phy_connect(struct bcm43xx_p
flags = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATEHIGH);
if (connect) {
- if (!(flags & 0x0001))
+ if (!(flags & BCM43xx_SBTMSTATEHIGH_G_PHY_AVAIL))
return -ENODEV;
flags = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATELOW);
- flags |= (0x800 << 18);
+ flags |= BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_write32(bcm, BCM43xx_CIR_SBTMSTATELOW, flags);
} else {
- if (!(flags & 0x0002))
+ if (!(flags & BCM43xx_SBTMSTATEHIGH_A_PHY_AVAIL))
return -ENODEV;
flags = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATELOW);
- flags &= ~(0x800 << 18);
+ flags &= ~BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_write32(bcm, BCM43xx_CIR_SBTMSTATELOW, flags);
}
out:
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
@@ -1389,7 +1389,7 @@ void bcm43xx_wireless_core_reset(struct
& ~(BCM43xx_SBF_MAC_ENABLED | 0x0002));
} else {
if (connect_phy)
- flags |= 0x2000;
+ flags |= BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_phy_connect(bcm, connect_phy);
bcm43xx_core_enable(bcm, flags);
bcm43xx_write16(bcm, 0x03E6, 0x);
@@ -3662,7 +3662,7 @@ int bcm43xx_select_wireless_core(struct
u32 sbtmstatelow;
sbtmstatelow = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATELOW);
- sbtmstatelow |= 0x2000;
+ sbtmstatelow |= BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_write32(bcm, BCM43xx_CIR_SBTMSTATELOW, sbtmstatelow);
}
err = wireless_core_up(bcm, 1);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] Eliminate some 'G Mode Enable' magic numbers
John W. Linville wrote: > On Wed, Mar 14, 2007 at 11:18:28AM -0500, Larry Finger wrote: >> In code manipulating the TM State Low register of 802.11 cores, two >> different magic numbers are used to reference the 'G Mode Enable' bit. >> One of these, 0x2000, is clear, but the other, (0x800 << 18), is not. >> This patch replaces both types with a defined constant. In addition, two >> bits in the TM State High registers are given definitions to help in >> following the code. > > Looks reasonable to me -- not sure why this is an RFC? Does anyone > object? Not so far. I'll make it a proper patch. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] Eliminate some 'G Mode Enable' magic numbers
On Wed, Mar 14, 2007 at 11:18:28AM -0500, Larry Finger wrote: > In code manipulating the TM State Low register of 802.11 cores, two > different magic numbers are used to reference the 'G Mode Enable' bit. > One of these, 0x2000, is clear, but the other, (0x800 << 18), is not. > This patch replaces both types with a defined constant. In addition, two > bits in the TM State High registers are given definitions to help in > following the code. Looks reasonable to me -- not sure why this is an RFC? Does anyone object? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
EAP-FAST or LEAP?
Can anyone get LEAP or EAP-FAST to work with these drivers? Especially the bcm4311? My campus currently uses LEAP, and I have not been able to get my card to work using wpa_supplicant in Linux. The reason I am asking about EAP-FAST is that the network administrators are considering on switching over to EAP-FAST or run both. I noticed a small issue where I can't set the ssid using iwconfig. It only takes the first letter of the ssid. Although NetworkManager has no problem setting the ssid. I did not do that under ndiswrapper. I'll look more into it after class. Again thanks for the hard work developers. :) --Dustin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC] Eliminate some 'G Mode Enable' magic numbers
In code manipulating the TM State Low register of 802.11 cores, two
different magic numbers are used to reference the 'G Mode Enable' bit.
One of these, 0x2000, is clear, but the other, (0x800 << 18), is not.
This patch replaces both types with a defined constant. In addition, two
bits in the TM State High registers are given definitions to help in
following the code.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -277,11 +277,14 @@
#define BCM43xx_SBTMSTATELOW_REJECT0x02
#define BCM43xx_SBTMSTATELOW_CLOCK 0x1
#define BCM43xx_SBTMSTATELOW_FORCE_GATE_CLOCK 0x2
+#define BCM43xx_SBTMSTATELOW_G_MODE_ENABLE 0x2000
/* sbtmstatehigh state flags */
#define BCM43xx_SBTMSTATEHIGH_SERROR 0x0001
#define BCM43xx_SBTMSTATEHIGH_BUSY 0x0004
#define BCM43xx_SBTMSTATEHIGH_TIMEOUT 0x0020
+#define BCM43xx_SBTMSTATEHIGH_G_PHY_AVAIL 0x0001
+#define BCM43xx_SBTMSTATEHIGH_A_PHY_AVAIL 0x0002
#define BCM43xx_SBTMSTATEHIGH_COREFLAGS0x1FFF
#define BCM43xx_SBTMSTATEHIGH_DMA64BIT 0x1000
#define BCM43xx_SBTMSTATEHIGH_GATEDCLK 0x2000
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -168,16 +168,16 @@ int bcm43xx_phy_connect(struct bcm43xx_p
flags = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATEHIGH);
if (connect) {
- if (!(flags & 0x0001))
+ if (!(flags & BCM43xx_SBTMSTATEHIGH_G_PHY_AVAIL))
return -ENODEV;
flags = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATELOW);
- flags |= (0x800 << 18);
+ flags |= BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_write32(bcm, BCM43xx_CIR_SBTMSTATELOW, flags);
} else {
- if (!(flags & 0x0002))
+ if (!(flags & BCM43xx_SBTMSTATEHIGH_A_PHY_AVAIL))
return -ENODEV;
flags = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATELOW);
- flags &= ~(0x800 << 18);
+ flags &= ~BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_write32(bcm, BCM43xx_CIR_SBTMSTATELOW, flags);
}
out:
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
@@ -1389,7 +1389,7 @@ void bcm43xx_wireless_core_reset(struct
& ~(BCM43xx_SBF_MAC_ENABLED | 0x0002));
} else {
if (connect_phy)
- flags |= 0x2000;
+ flags |= BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_phy_connect(bcm, connect_phy);
bcm43xx_core_enable(bcm, flags);
bcm43xx_write16(bcm, 0x03E6, 0x);
@@ -3662,7 +3662,7 @@ int bcm43xx_select_wireless_core(struct
u32 sbtmstatelow;
sbtmstatelow = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATELOW);
- sbtmstatelow |= 0x2000;
+ sbtmstatelow |= BCM43xx_SBTMSTATELOW_G_MODE_ENABLE;
bcm43xx_write32(bcm, BCM43xx_CIR_SBTMSTATELOW, sbtmstatelow);
}
err = wireless_core_up(bcm, 1);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re:
On Wednesday 14 March 2007 16:32, Larry Finger wrote: > During testing of bcm43xx interference mitigation, two problems were > discovered: > > (1) When the MANUALWLAN mode was set, routines _stack_save and _stack_restore > generated assertions that were traced to saving ILT registers with > addresses > > 0xFFF. This problem was fixed by adding one bit to the field used for > the offset, and subtracting one bit from the space used for the id. > (2) In MANUALWLAN mode, the IRQ XMIT errors are generated. The cause of these > errors has not yet been located. Any suggestions on debugging this problem > would be greatly appreciated. Interference mitigation code is broken and has always been. It never worked. So no wonder it doesn't work now. ;) I'd suggest to first fix that (by a rewrite) before you do any code that's based on it (like this ACI stuff). I won't do it. interf mitigation is an uninterresting feature to me. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[no subject]
During testing of bcm43xx interference mitigation, two problems were
discovered:
(1) When the MANUALWLAN mode was set, routines _stack_save and _stack_restore
generated assertions that were traced to saving ILT registers with addresses
> 0xFFF. This problem was fixed by adding one bit to the field used for
the offset, and subtracting one bit from the space used for the id.
(2) In MANUALWLAN mode, the IRQ XMIT errors are generated. The cause of these
errors has not yet been located. Any suggestions on debugging this problem
would be greatly appreciated.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -882,10 +882,10 @@ static void _stack_save(u32 *_stackptr,
{
u32 *stackptr = &(_stackptr[*stackidx]);
- assert((offset & 0xF000) == 0x);
- assert((id & 0xF0) == 0x00);
+ assert((offset & 0xE000) == 0x);
+ assert((id & 0xF8) == 0x00);
*stackptr = offset;
- *stackptr |= ((u32)id) << 12;
+ *stackptr |= ((u32)id) << 13;
*stackptr |= ((u32)value) << 16;
(*stackidx)++;
assert(*stackidx < BCM43xx_INTERFSTACK_SIZE);
@@ -896,12 +896,12 @@ static u16 _stack_restore(u32 *stackptr,
{
size_t i;
- assert((offset & 0xF000) == 0x);
- assert((id & 0xF0) == 0x00);
+ assert((offset & 0xE000) == 0x);
+ assert((id & 0xF8) == 0x00);
for (i = 0; i < BCM43xx_INTERFSTACK_SIZE; i++, stackptr++) {
- if ((*stackptr & 0x0FFF) != offset)
+ if ((*stackptr & 0x1FFF) != offset)
continue;
- if (((*stackptr & 0xF000) >> 12) != id)
+ if (((*stackptr & 0x7000) >> 13) != id)
continue;
return ((*stackptr & 0x) >> 16);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Belkin F5D7001PCI ( also BCM4318 ) not works using bcm43xx softmac driver.
On Wednesday 14 March 2007 15:46, Pavel Roskin wrote: > On Wed, 2007-03-14 at 16:40 +0200, Tomas Martišius wrote: > > > One more question. How about such projects as openwrt or dd-wrt? > > As I know - on these at least Linksys devices broadcom wireless chipset > > is also used. > > I don't know exact version of it, but if linux kernel works on this > > device - which driver is used? Your's or some other? > > If your's - they somehow forced it to work in "Master" mode? > > No, it's a closed source driver that was on the original Linksys router. > > But I think they could try bcm43xx_mac80211. There was a recent report > that it's working in master mode. bcm43xx-mac80211 and ssb is in openwrt trunk, if you enable the "broken" config option. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Belkin F5D7001PCI ( also BCM4318 ) not works using bcm43xx softmac driver.
Tomas Martišius wrote: > Larry Finger wrote: >> The firmware only does a small part of the operation - the driver does >> the rest. > I think'ed firmware does a lot of more >> The writers of the >> Windows driver had the cooperation of the hardware designers and knew >> exactly how the chip would >> respond to a given set of operations. We have had to reverse-engineer >> the code and try to emulate >> their stuff. Obviously, we don't have it right yet. Considering that >> 4318's couldn't go above 11M >> until a few weeks ago, we are making progress. >> > Yes, I know all this story. Your question didn't make it seem that you really understood. > > One more question. How about such projects as openwrt or dd-wrt? > As I know - on these at least Linksys devices broadcom wireless chipset > is also used. > I don't know exact version of it, but if linux kernel works on this > device - which driver is used? Your's or some other? > If your's - they somehow forced it to work in "Master" mode? AFAIK, the openWRT project uses pre-compiled binary drivers for the bcm43xx device from the Linksys GPL'd source distribution, which is also the piece of code that was decompiled in our reverse-engineering step. We could use it as well, but we would be limited to 2.4 kernels, have to run MIPS hardware, and would have tainted kernels. From what I read, the openWRT project is very interested in the mac80211 driver and hopes to use it to replace their current version. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Belkin F5D7001PCI ( also BCM4318 ) not works using bcm43xx softmac driver.
On Wed, 2007-03-14 at 16:40 +0200, Tomas Martišius wrote: > One more question. How about such projects as openwrt or dd-wrt? > As I know - on these at least Linksys devices broadcom wireless chipset > is also used. > I don't know exact version of it, but if linux kernel works on this > device - which driver is used? Your's or some other? > If your's - they somehow forced it to work in "Master" mode? No, it's a closed source driver that was on the original Linksys router. But I think they could try bcm43xx_mac80211. There was a recent report that it's working in master mode. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Belkin F5D7001PCI ( also BCM4318 ) not works using bcm43xx softmac driver.
Larry Finger wrote: > The firmware only does a small part of the operation - the driver does the > rest. I think'ed firmware does a lot of more > The writers of the > Windows driver had the cooperation of the hardware designers and knew exactly > how the chip would > respond to a given set of operations. We have had to reverse-engineer the > code and try to emulate > their stuff. Obviously, we don't have it right yet. Considering that 4318's > couldn't go above 11M > until a few weeks ago, we are making progress. > Yes, I know all this story. One more question. How about such projects as openwrt or dd-wrt? As I know - on these at least Linksys devices broadcom wireless chipset is also used. I don't know exact version of it, but if linux kernel works on this device - which driver is used? Your's or some other? If your's - they somehow forced it to work in "Master" mode? Sory for my english. Best regards, Tomas ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFT] [PATCH] bcm43xx: ACI fixes
On Wednesday 14 March 2007 07:41, Stefano Brivio wrote:
> > > -aci_hw_rssi:1;
> > > +aci_hw_rssi:1,
> > > +aci_delay:5;
> > Should this be a bit field? Why not just make it a u8?
>
> We only need 5 bits, as aci_delay will never be > 20.
I actually try to move away from the foo:x notation, as it generates bad code.
There's no benefit in saving 3 bits here and adding 100byte of additional
code, which is generated by gcc to mask and shift the bits. :)
> > > + u8 aci_start;
> > > };
> > >
> > > /* Data structures for DMA transmission, per 80211 core. */
> > > @@ -699,6 +708,18 @@ struct bcm43xx_noise_calculation {
> > > s8 samples[8][4];
> > > };
> > >
> > > +/* Statscounter data (currently ACI only). */
> > > +struct bcm43xx_statscounter_saved {
> > > + u16 aci;
> > > +};
> > > +
> > > +/* Values for ACI moving average calculation. */
> > > +struct bcm43xx_aci_saved {
> > > + u16 value[8];
> > > + u8 next:3,
> > > +set:3;
> > As I will explain later, I don't think 'set' is needed. I also recommend
> > having 'next' be a plain u8.
>
> Both values will never be > 7.
Please do u8 nevertheless to get better code.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
