Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
It's not perfectly stable yet, but scanning and associating to open network
works! It has to be tested, improved, there are some PHY errors from time to
time, but generally it works :)
Rafał Miłecki (4):
b43: N-PHY: silence warnings
b43: set TMS to work with current band width for N-PHY
b43: fix split of N-PHY devices into supported and not (based on PHY
rev)
b43: rename config option for N-PHY, drop BROKEN
drivers/net/wireless/b43/Kconfig | 13 +++++++------
drivers/net/wireless/b43/Makefile | 8 ++++----
drivers/net/wireless/b43/main.c | 12 +++++++++---
drivers/net/wireless/b43/phy_common.c | 9 ++++++++-
drivers/net/wireless/b43/phy_common.h | 2 ++
drivers/net/wireless/b43/phy_n.c | 16 ++++++----------
6 files changed, 36 insertions(+), 24 deletions(-)
2010/12/7 Rafał Miłecki <[email protected]>:
> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.
>
> It's not perfectly stable yet, but scanning and associating to open network
> works! It has to be tested, improved, there are some PHY errors from time to
> time, but generally it works :)
>
> Rafał Miłecki (4):
> b43: N-PHY: silence warnings
> b43: set TMS to work with current band width for N-PHY
> b43: fix split of N-PHY devices into supported and not (based on PHY
> rev)
> b43: rename config option for N-PHY, drop BROKEN
>
> drivers/net/wireless/b43/Kconfig | 13 +++++++------
> drivers/net/wireless/b43/Makefile | 8 ++++----
> drivers/net/wireless/b43/main.c | 12 +++++++++---
> drivers/net/wireless/b43/phy_common.c | 9 ++++++++-
> drivers/net/wireless/b43/phy_common.h | 2 ++
> drivers/net/wireless/b43/phy_n.c | 16 ++++++----------
> 6 files changed, 36 insertions(+), 24 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Thu, 2010-12-09 at 09:20 -0600, Larry Finger wrote:
> It has a rev 2 PHY, and a rev 4 0x2055 radio.
>
> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
> 4324A-BRCM1036?
It says BCM94322 on the image, and if that's any indication, I have a
4322 with pci ID 14e4:432b (but it's an Apple build):
b43-phy0: Broadcom 4322 WLAN found (core revision 16)
b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3
johannes
Rafał,
The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
hours under normal conditions - I have not yet tried any stress tests. Other
than the PHY errors that you noted, my link has only reported 2 other unusual
events. I have had 3 "Deauthentication for reason 3" from which it recovered in
one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
dropped" events. Again, these caused no problems.
Larry
On 12/10/2010 12:53 PM, Konstantinos Karantias wrote:
> It's not been so stable on my BCM4312, but it's still stable. It can
> keep the connection for ~3 hours here.
Your BCM4312 probably has an LP PHY. We were reporting on the N PHY devices.
I have 2 LP PHY units - both stay connected although one of them gets "cookie
out of order" errors on occasion. Please report the exact details for your device.
Larry
On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
> On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <[email protected]> wrote:
> > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> >>
> >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> >>>
> >>> and the device is never release (by who?). I have to reboot.
> >>
> >> That's a bug in the ipv6 code, upgrade your kernel :-)
> >
> > I would not have seen that as IPv6 is disabled in my kernels.
>
> Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
Can we stop this thread right here and go on-topic again please?
johannes
W dniu 9 grudnia 2010 15:19 użytkownik Michael Büsch <[email protected]> napisał:
> On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
>> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <[email protected]> napisał:
>> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <[email protected]> napisał:
>> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
>> >>> Signed-off-by: Rafał Miłecki <[email protected]>
>> >>> ---
>> >>> drivers/net/wireless/b43/main.c | 6 ++++++
>> >>> drivers/net/wireless/b43/phy_common.c | 7 +++++++
>> >>> drivers/net/wireless/b43/phy_common.h | 2 ++
>> >>> drivers/net/wireless/b43/phy_n.c | 7 -------
>> >>> 4 files changed, 15 insertions(+), 7 deletions(-)
>> >>>
>> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> >>> index fa48803..670fd7b 100644
>> >>> --- a/drivers/net/wireless/b43/main.c
>> >>> +++ b/drivers/net/wireless/b43/main.c
>> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>> >>>
>> >>> flags |= B43_TMSLOW_PHYCLKEN;
>> >>> flags |= B43_TMSLOW_PHYRESET;
>> >>> + if (dev->phy.type == B43_PHYTYPE_N) {
>> >>> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>> >>
>> >> Is channel_type already set at this time?
>> >
>> > Yeah, that core switching seems to be a little tricky. I didn't figure
>> > it out completely yet. We may need to fix that, or fix calls to this
>> > function.
>> >
>> > Thanks for reviewing!
>>
>> In other words: it will work for now, but we need to fix that in
>> future if we want to get 40 MHz channels working.
>
> That's exactly what I was saying. ;)
> To answer my original question: No, channel_type is not set, but the
> code will work for non-40mhz.
>
> This seems a bit tricky to fix, though. Maybe we should reset the
> wireless core twice. Once initially and once again after the
> configuration was set. The first reset would just be to be able
> to access the PHY and wireless core at all to probe it.
Even more tricky is that we already reset code twice... At least in
b43_wireless_core_attach. Will have to redesign that a little.
--
Rafał
On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <[email protected]> wrote:
> On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>>
>>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>>
>>> and the device is never release (by who?). I have to reboot.
>>
>> That's a bug in the ipv6 code, upgrade your kernel :-)
>
> I would not have seen that as IPv6 is disabled in my kernels.
Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <[email protected]> napisał:
> W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <[email protected]> napisał:
>> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
>>> Signed-off-by: Rafał Miłecki <[email protected]>
>>> ---
>>> drivers/net/wireless/b43/main.c | 6 ++++++
>>> drivers/net/wireless/b43/phy_common.c | 7 +++++++
>>> drivers/net/wireless/b43/phy_common.h | 2 ++
>>> drivers/net/wireless/b43/phy_n.c | 7 -------
>>> 4 files changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>>> index fa48803..670fd7b 100644
>>> --- a/drivers/net/wireless/b43/main.c
>>> +++ b/drivers/net/wireless/b43/main.c
>>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>>>
>>> flags |= B43_TMSLOW_PHYCLKEN;
>>> flags |= B43_TMSLOW_PHYRESET;
>>> + if (dev->phy.type == B43_PHYTYPE_N) {
>>> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>>
>> Is channel_type already set at this time?
>
> Yeah, that core switching seems to be a little tricky. I didn't figure
> it out completely yet. We may need to fix that, or fix calls to this
> function.
>
> Thanks for reviewing!
In other words: it will work for now, but we need to fix that in
future if we want to get 40 MHz channels working.
--
Rafał
On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> Signed-off-by: Rafał Miłecki <[email protected]>
> ---
> drivers/net/wireless/b43/main.c | 6 ++++++
> drivers/net/wireless/b43/phy_common.c | 7 +++++++
> drivers/net/wireless/b43/phy_common.h | 2 ++
> drivers/net/wireless/b43/phy_n.c | 7 -------
> 4 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index fa48803..670fd7b 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>
> flags |= B43_TMSLOW_PHYCLKEN;
> flags |= B43_TMSLOW_PHYRESET;
> + if (dev->phy.type == B43_PHYTYPE_N) {
> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
Is channel_type already set at this time?
> + flags |= B43_TMSLOW_PHYCLKSPEED_160MHZ;
> + else
> + flags |= B43_TMSLOW_PHYCLKSPEED_80MHZ;
> + }
--
Greetings Michael.
I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
As shown in the NetworkManager log attached, Authentication is successful, but
DHCP fails. Either the transmit data is improperly encrypted, or the decryption
fails. I will use wireshark to sort that out. Note: Using software encryption
makes no difference.
Larry
Signed-off-by: Rafał Miłecki <[email protected]>
---
drivers/net/wireless/b43/Kconfig | 13 +++++++------
drivers/net/wireless/b43/Makefile | 8 ++++----
drivers/net/wireless/b43/main.c | 4 ++--
drivers/net/wireless/b43/phy_common.c | 2 +-
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index 0a00d42..47033f6 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -86,15 +86,16 @@ config B43_PIO
select SSB_BLOCKIO
default y
-config B43_NPHY
- bool "Pre IEEE 802.11n support (BROKEN)"
- depends on B43 && EXPERIMENTAL && BROKEN
+config B43_PHY_N
+ bool "Support for 802.11n (N-PHY) devices (EXPERIMENTAL)"
+ depends on B43 && EXPERIMENTAL
---help---
- Support for the IEEE 802.11n draft.
+ Support for the N-PHY.
- THIS IS BROKEN AND DOES NOT WORK YET.
+ This enables support for devices with N-PHY revision up to 2.
- SAY N.
+ Say N if you expect high stability and performance. Saying Y will not
+ affect other devices support and may provide support for basic needs.
config B43_PHY_LP
bool "Support for low-power (LP-PHY) devices (EXPERIMENTAL)"
diff --git a/drivers/net/wireless/b43/Makefile b/drivers/net/wireless/b43/Makefile
index 69d4af0..cef334a 100644
--- a/drivers/net/wireless/b43/Makefile
+++ b/drivers/net/wireless/b43/Makefile
@@ -1,12 +1,12 @@
b43-y += main.o
b43-y += tables.o
-b43-$(CONFIG_B43_NPHY) += tables_nphy.o
-b43-$(CONFIG_B43_NPHY) += radio_2055.o
-b43-$(CONFIG_B43_NPHY) += radio_2056.o
+b43-$(CONFIG_B43_PHY_N) += tables_nphy.o
+b43-$(CONFIG_B43_PHY_N) += radio_2055.o
+b43-$(CONFIG_B43_PHY_N) += radio_2056.o
b43-y += phy_common.o
b43-y += phy_g.o
b43-y += phy_a.o
-b43-$(CONFIG_B43_NPHY) += phy_n.o
+b43-$(CONFIG_B43_PHY_N) += phy_n.o
b43-$(CONFIG_B43_PHY_LP) += phy_lp.o
b43-$(CONFIG_B43_PHY_LP) += tables_lpphy.o
b43-y += sysfs.o
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 4d97aac..9ae3f61 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4052,7 +4052,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
if (phy_rev > 9)
unsupported = 1;
break;
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
case B43_PHYTYPE_N:
if (phy_rev > 2)
unsupported = 1;
@@ -5097,7 +5097,7 @@ static void b43_print_driverinfo(void)
#ifdef CONFIG_B43_PCMCIA
feat_pcmcia = "M";
#endif
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
feat_nphy = "N";
#endif
#ifdef CONFIG_B43_LEDS
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index 412f1b6..b5c5ce9 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -50,7 +50,7 @@ int b43_phy_allocate(struct b43_wldev *dev)
phy->ops = &b43_phyops_g;
break;
case B43_PHYTYPE_N:
-#ifdef CONFIG_B43_NPHY
+#ifdef CONFIG_B43_PHY_N
phy->ops = &b43_phyops_n;
#endif
break;
--
1.6.3.3
On 12/10/2010 12:47 PM, Johannes Berg wrote:
> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>
>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>
>> and the device is never release (by who?). I have to reboot.
>
> That's a bug in the ipv6 code, upgrade your kernel :-)
I would not have seen that as IPv6 is disabled in my kernels.
Larry
On 12/09/2010 09:52 PM, Jon Saul wrote:
> On 12/09/2010 10:03 AM, Larry Finger wrote:
>> I sent a question to the seller of the card I mentioned earlier asking them to
>> tell me the PCI IDs and explaining why I needed to know. If they answer, we will
>> at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
>>> 2. At that price, I'm willing to buy it myself, but there should be money
>> available to get things for Rafał. Who has those funds? I think the last time I
>> got something though the donations, it was Stefano, but that was a long time ago.
>>
>> Rafał: If I get a rev > 2 card, you can certainly ssh into my computer for
>> testing, or I can do the runs here and send you the dumps.
>>
>> Larry
> I have a 14e4:432b card and am willing to help any way I can.
Thanks for the offer. I bought one that should have those ID values on Ebay
today. If it is not a 432b, or some other N PHY with rev > 2, I have the right
to return it. The seller did not know the IDs. In that case, I will contact you
to see what we can arrange.
Larry
On 12/21/2010 03:25 AM, David Woodhouse wrote:
>
> On-topic:
>
> Anyone working on or testing network device drivers should be using
> IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
> rarely does, in particular using multicast to do neighbour discovery.
> And on wireless networks when multicast will be handled differently by
> the AP, that makes more difference than on wired where it's mostly the
> MAC filters that get neglected.
>
> I've seen a number of broken drivers because their authors were only
> testing with Legacy IP and not IPv6.
>
> It's not hard to set up IPv6. Larry, if you need any pointers I'd be
> more than happy to help.
I have no problem setting it up. I disabled it mostly to reduce the number of
modules in a kernel recompile. It doesn't make much difference on either of my
multi-core boxes, but some of the lower-powered units already take hours to build.
I take your point, and will be reenabling IPv6.
Larry
On Fri, 2010-12-10 at 20:08 +0100, Johannes Berg wrote:
> On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
> > On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <[email protected]> wrote:
> > > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> > >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> > >>
> > >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> > >>>
> > >>> and the device is never release (by who?). I have to reboot.
> > >>
> > >> That's a bug in the ipv6 code, upgrade your kernel :-)
> > >
> > > I would not have seen that as IPv6 is disabled in my kernels.
> >
> > Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
>
> Can we stop this thread right here and go on-topic again please?
On-topic:
Anyone working on or testing network device drivers should be using
IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
rarely does, in particular using multicast to do neighbour discovery.
And on wireless networks when multicast will be handled differently by
the AP, that makes more difference than on wired where it's mostly the
MAC filters that get neglected.
I've seen a number of broken drivers because their authors were only
testing with Legacy IP and not IPv6.
It's not hard to set up IPv6. Larry, if you need any pointers I'd be
more than happy to help.
--
dwmw2
On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
>
> It's not perfectly stable yet, but scanning and associating to open network
> works! It has to be tested, improved, there are some PHY errors from time to
> time, but generally it works :)
Wow! Congrats to all involved!!
johannes
On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <[email protected]> napisał:
> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <[email protected]> napisał:
> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> >>> Signed-off-by: Rafał Miłecki <[email protected]>
> >>> ---
> >>> drivers/net/wireless/b43/main.c | 6 ++++++
> >>> drivers/net/wireless/b43/phy_common.c | 7 +++++++
> >>> drivers/net/wireless/b43/phy_common.h | 2 ++
> >>> drivers/net/wireless/b43/phy_n.c | 7 -------
> >>> 4 files changed, 15 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >>> index fa48803..670fd7b 100644
> >>> --- a/drivers/net/wireless/b43/main.c
> >>> +++ b/drivers/net/wireless/b43/main.c
> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >>>
> >>> flags |= B43_TMSLOW_PHYCLKEN;
> >>> flags |= B43_TMSLOW_PHYRESET;
> >>> + if (dev->phy.type == B43_PHYTYPE_N) {
> >>> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >>
> >> Is channel_type already set at this time?
> >
> > Yeah, that core switching seems to be a little tricky. I didn't figure
> > it out completely yet. We may need to fix that, or fix calls to this
> > function.
> >
> > Thanks for reviewing!
>
> In other words: it will work for now, but we need to fix that in
> future if we want to get 40 MHz channels working.
That's exactly what I was saying. ;)
To answer my original question: No, channel_type is not set, but the
code will work for non-40mhz.
This seems a bit tricky to fix, though. Maybe we should reset the
wireless core twice. Once initially and once again after the
configuration was set. The first reset would just be to be able
to access the PHY and wireless core at all to probe it.
--
Greetings Michael.
On 12/07/2010 04:57 PM, Gábor Stefanik wrote:
> 2010/12/7 Rafał Miłecki <[email protected]>:
>> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
>
> Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.
>
>>
>> It's not perfectly stable yet, but scanning and associating to open network
>> works! It has to be tested, improved, there are some PHY errors from time to
>> time, but generally it works :)
With my device:
04:00.0 Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n
[14e4:4328] (rev 03)
Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n Wireless LAN
Controller [103c:1366]
Kernel driver in use: b43-pci-bridge
Excerpt of log:
[ 1184.780924] b43-pci-bridge 0000:04:00.0: PCI INT A -> Link[LK4E] -> GSI 20
(level, low) -> IRQ 20
[ 1184.780945] b43-pci-bridge 0000:04:00.0: setting latency timer to 64
[ 1184.800166] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
[ 1184.800176] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
[ 1184.800184] ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
[ 1184.800192] ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
[ 1184.800200] ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
[ 1184.820062] ssb: Switching to ChipCommon core, index 0
[ 1184.820202] ssb: chipcommon status is 0x0
[ 1184.820211] ssb: SPROM offset is 0x1000
[ 1184.828653] ssb: SPROM revision 5 detected.
[ 1184.848037] ssb: Switching to PCI-E core, index 2
[ 1184.848659] ssb: Sonics Silicon Backplane found on PCI device 0000:04:00.0
[ 1184.897825] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[ 1184.916062] ssb: Switching to IEEE 802.11 core, index 1
[ 1184.940038] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[ 1184.940064] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
[ 1184.975224] Registered led device: b43-phy0::tx
[ 1184.978455] Registered led device: b43-phy0::rx
[ 1184.980387] Registered led device: b43-phy0::radio
[ 1185.256050] b43-phy0: Loading firmware version 508.1107 (2009-06-26 19:16:02)
[ 1185.256059] ssb: Switching to ChipCommon core, index 0
[ 1185.256123] ssb: Switching to IEEE 802.11 core, index 1
[ 1185.332045] b43-phy0 debug: Chip initialized
[ 1185.333522] b43-phy0 debug: 64-bit DMA initialized
[ 1185.333570] b43-phy0 debug: QoS enabled
[ 1185.353497] b43-phy0 debug: Wireless interface started
[ 1185.353512] b43-phy0 debug: Adding Interface type 2
[ 1188.041790] b43-phy0 debug: Using hardware based encryption for keyidx: 0,
mac: c0:3f:0e:be:2b:45
[ 1191.134922] b43-phy0 debug: Disabling hardware based encryption for keyidx:
0, mac: c0:3f:0e:be:2b:45
[ 1192.823490] b43-phy0 debug: Using hardware based encryption for keyidx: 0,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824306] b43-phy0 debug: Using hardware based encryption for keyidx: 1,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824630] b43-phy0 debug: Using hardware based encryption for keyidx: 2,
mac: ff:ff:ff:ff:ff:ff
[ 1192.824989] b43-phy0 debug: Using hardware based encryption for keyidx: 3,
mac: ff:ff:ff:ff:ff:ff
[ 1194.896063] b43-phy0 ERROR: PHY transmission error
It connects and authenticates with WEP, but not with WPA2. It appears to be
limited to CCK rates. Setting a rate above 11Mb/s results in complete failure.
Transmit rate is 4.6 Mb/s at 11M. All in all, not bad for first life.
Larry
W dniu 7 grudnia 2010 23:57 użytkownik Gábor Stefanik
<[email protected]> napisał:
> 2010/12/7 Rafał Miłecki <[email protected]>:
>> Finally, thanks for Larry and Francesco I got b43 working with BCM4328 chipset!
>
> Do you mean BCM4321 (14e4:4328)? BCM4328 is AFAIK handled by brcmfmac.
Yeah, I removed following hack some time ago:
- } else if (bus->chip_id == 0x4321) {
- /* the BCM4328 has a chipid == 0x4321 and a rev 4 SPROM */
and got lost what is my chipset. You're right.
--
Rafał
Signed-off-by: Rafał Miłecki <[email protected]>
---
drivers/net/wireless/b43/main.c | 2 +-
drivers/net/wireless/b43/phy_n.c | 1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 670fd7b..4d97aac 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4054,7 +4054,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
break;
#ifdef CONFIG_B43_NPHY
case B43_PHYTYPE_N:
- if (phy_rev > 4)
+ if (phy_rev > 2)
unsupported = 1;
break;
#endif
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 3517341..61875c8 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -3515,7 +3515,6 @@ int b43_phy_initn(struct b43_wldev *dev)
if (phy->rev >= 3)
b43_nphy_spur_workaround(dev);
- b43err(dev->wl, "IEEE 802.11n devices are not supported, yet.\n");
return 0;
}
--
1.6.3.3
On 12/09/2010 10:03 AM, Larry Finger wrote:
> I sent a question to the seller of the card I mentioned earlier asking them to
> tell me the PCI IDs and explaining why I needed to know. If they answer, we will
> at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
>> 2. At that price, I'm willing to buy it myself, but there should be money
> available to get things for Rafał. Who has those funds? I think the last time I
> got something though the donations, it was Stefano, but that was a long time ago.
>
> Rafał: If I get a rev > 2 card, you can certainly ssh into my computer for
> testing, or I can do the runs here and send you the dumps.
>
> Larry
I have a 14e4:432b card and am willing to help any way I can.
--
0x00
2010/12/21 David Woodhouse <[email protected]>:
> On Fri, 2010-12-10 at 20:08 +0100, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
>> > On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <[email protected]> wrote:
>> > > On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> > >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>> > >>
>> > >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>> > >>>
>> > >>> and the device is never release (by who?). I have to reboot.
>> > >>
>> > >> That's a bug in the ipv6 code, upgrade your kernel :-)
>> > >
>> > > I would not have seen that as IPv6 is disabled in my kernels.
>> >
>> > Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
>>
>> Can we stop this thread right here and go on-topic again please?
>
> On-topic:
>
> Anyone working on or testing network device drivers should be using
> IPv6. IPv6 will exercise code paths and network behaviour that Legacy IP
> rarely does, in particular using multicast to do neighbour discovery.
> And on wireless networks when multicast will be handled differently by
> the AP, that makes more difference than on wired where it's mostly the
> MAC filters that get neglected.
>
> I've seen a number of broken drivers because their authors were only
> testing with Legacy IP and not IPv6.
>
> It's not hard to set up IPv6. Larry, if you need any pointers I'd be
> more than happy to help.
I've router with OpenWRT, so that probably should be possible for me
to setup IPv6. However first I want to have working basic PHY and
radio configuration.
--
Rafał
Signed-off-by: Rafał Miłecki <[email protected]>
---
drivers/net/wireless/b43/phy_n.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index f78f4e9..d41da7f 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -258,7 +258,8 @@ static void b43_nphy_tx_power_fix(struct b43_wldev *dev)
for (i = 0; i < 2; i++) {
if (dev->phy.rev >= 3) {
- /* TODO */
+ /* FIXME: support 5GHz */
+ txgain = b43_ntab_tx_gain_rev3plus_2ghz[txpi[i]];
radio_gain = (txgain >> 16) & 0x1FFFF;
} else {
txgain = b43_ntab_tx_gain_rev0_1_2[txpi[i]];
@@ -613,6 +614,8 @@ static void b43_nphy_rx_iq_coeffs(struct b43_wldev *dev, bool write,
}
}
+#if 0
+/* Ready but not used anywhere */
/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/RxCalPhyCleanup */
static void b43_nphy_rx_cal_phy_cleanup(struct b43_wldev *dev, u8 core)
{
@@ -694,6 +697,7 @@ static void b43_nphy_rx_cal_phy_setup(struct b43_wldev *dev, u8 core)
b43_nphy_rf_control_intc_override(dev, 1, rxval, (core + 1));
b43_nphy_rf_control_intc_override(dev, 1, txval, (2 - core));
}
+#endif
/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/CalcRxIqComp */
static void b43_nphy_calc_rx_iq_comp(struct b43_wldev *dev, u8 mask)
@@ -3088,7 +3092,7 @@ static int b43_nphy_rev2_cal_rx_iq(struct b43_wldev *dev,
u8 rfctl[2];
u8 afectl_core;
u16 tmp[6];
- u16 cur_hpf1, cur_hpf2, cur_lna;
+ u16 uninitialized_var(cur_hpf1), uninitialized_var(cur_hpf2), cur_lna;
u32 real, imag;
enum ieee80211_band band;
--
1.6.3.3
On Thu, 2010-12-09 at 16:28 +0100, Rafał Miłecki wrote:
> I actually asked for some hardware donations on my blog and in news on
> polish portal, but didn't receive any serious offer.
There probably are still money donations left to buy some ... ?
> Johannes: is there any chance you could put this card in some machine
> I could get ssh access to? Or is that some daily-user-card or you
> don't really have free machine? Of course I don't need that now, first
> we have to make PHY 2 support more complete. But maybe after
> Christmas/new year I could focus on that.
I can't, unless I magically get a new laptop -- this card is built into
my macbook that I use all the time. I'd have a mostly-free machine, and
I don't use the card, but it's not a replacable part.
johannes
2010/12/9 Johannes Berg <[email protected]>:
> On Thu, 2010-12-09 at 09:20 -0600, Larry Finger wrote:
>
>> It has a rev 2 PHY, and a rev 4 0x2055 radio.
>>
>> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
>> 4324A-BRCM1036?
>
> It says BCM94322 on the image, and if that's any indication, I have a
> 4322 with pci ID 14e4:432b (but it's an Apple build):
>
> b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3
I actually asked for some hardware donations on my blog and in news on
polish portal, but didn't receive any serious offer.
Johannes: is there any chance you could put this card in some machine
I could get ssh access to? Or is that some daily-user-card or you
don't really have free machine? Of course I don't need that now, first
we have to make PHY 2 support more complete. But maybe after
Christmas/new year I could focus on that.
--
Rafał
On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>
> and the device is never release (by who?). I have to reboot.
That's a bug in the ipv6 code, upgrade your kernel :-)
johannes
On Dec 8, 2010, at 4:15 PM, Larry Finger wrote:
> Rafał,
>
> The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
> hours under normal conditions - I have not yet tried any stress tests. Other
> than the PHY errors that you noted, my link has only reported 2 other unusual
> events. I have had 3 "Deauthentication for reason 3" from which it recovered in
> one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
> dropped" events. Again, these caused no problems.
Hi Rafał,
I confirm Larry's feedbacks. I tried both on a 32bit and a 64bit architectures (the first is frodo), and it works. I too see only CCK packets. On 64bit arch (Atom) it works but when I try to unload the module I get this
[ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
and the device is never release (by who?). I have to reboot.
I'm using two cards, one reports
[ 311.439406] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[ 311.480046] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[ 311.480075] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
The other (an Apple original card) reports
[ 82.726931] b43-phy0: Broadcom 4321 WLAN found (core revision 11)
[ 82.768030] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 1
[ 82.768062] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
Thanks,
-Francesco
Informativa sulla privacy: http://help.ing.unibs.it/privacy.php
W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <[email protected]> napisał:
> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
>> Signed-off-by: Rafał Miłecki <[email protected]>
>> ---
>> drivers/net/wireless/b43/main.c | 6 ++++++
>> drivers/net/wireless/b43/phy_common.c | 7 +++++++
>> drivers/net/wireless/b43/phy_common.h | 2 ++
>> drivers/net/wireless/b43/phy_n.c | 7 -------
>> 4 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> index fa48803..670fd7b 100644
>> --- a/drivers/net/wireless/b43/main.c
>> +++ b/drivers/net/wireless/b43/main.c
>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
>>
>> flags |= B43_TMSLOW_PHYCLKEN;
>> flags |= B43_TMSLOW_PHYRESET;
>> + if (dev->phy.type == B43_PHYTYPE_N) {
>> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
>
> Is channel_type already set at this time?
Yeah, that core switching seems to be a little tricky. I didn't figure
it out completely yet. We may need to fix that, or fix calls to this
function.
Thanks for reviewing!
--
Rafał
2010/12/9 Johannes Berg <[email protected]>:
> On Thu, 2010-12-09 at 16:28 +0100, Rafał Miłecki wrote:
>> I actually asked for some hardware donations on my blog and in news on
>> polish portal, but didn't receive any serious offer.
>
> There probably are still money donations left to buy some ... ?
The problem I was afraid of was recognizing PHY revision without
buying a card, just from looking at photos. It seems however, that
will be the only solution.
>> Johannes: is there any chance you could put this card in some machine
>> I could get ssh access to? Or is that some daily-user-card or you
>> don't really have free machine? Of course I don't need that now, first
>> we have to make PHY 2 support more complete. But maybe after
>> Christmas/new year I could focus on that.
>
> I can't, unless I magically get a new laptop -- this card is built into
> my macbook that I use all the time. I'd have a mostly-free machine, and
> I don't use the card, but it's not a replacable part.
OK, I'll just think about buying some card :)
--
Rafał
On 12/09/2010 09:37 AM, Rafał Miłecki wrote:
> 2010/12/9 Johannes Berg <[email protected]>:
>> On Thu, 2010-12-09 at 16:28 +0100, Rafał Miłecki wrote:
>>> I actually asked for some hardware donations on my blog and in news on
>>> polish portal, but didn't receive any serious offer.
>>
>> There probably are still money donations left to buy some ... ?
>
> The problem I was afraid of was recognizing PHY revision without
> buying a card, just from looking at photos. It seems however, that
> will be the only solution.
>
>
>>> Johannes: is there any chance you could put this card in some machine
>>> I could get ssh access to? Or is that some daily-user-card or you
>>> don't really have free machine? Of course I don't need that now, first
>>> we have to make PHY 2 support more complete. But maybe after
>>> Christmas/new year I could focus on that.
>>
>> I can't, unless I magically get a new laptop -- this card is built into
>> my macbook that I use all the time. I'd have a mostly-free machine, and
>> I don't use the card, but it's not a replacable part.
>
> OK, I'll just think about buying some card :)
I sent a question to the seller of the card I mentioned earlier asking them to
tell me the PCI IDs and explaining why I needed to know. If they answer, we will
at least know if it is a 14e4:432b. If so, then it certainly will have a PHY rev
> 2. At that price, I'm willing to buy it myself, but there should be money
available to get things for Rafał. Who has those funds? I think the last time I
got something though the donations, it was Stefano, but that was a long time ago.
Rafał: If I get a rev > 2 card, you can certainly ssh into my computer for
testing, or I can do the runs here and send you the dumps.
Larry
Larry
On Thu, 2010-12-09 at 15:23 +0100, Rafał Miłecki wrote:
> W dniu 9 grudnia 2010 15:19 użytkownik Michael Büsch <[email protected]> napisał:
> > On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
> >> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <[email protected]> napisał:
> >> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <[email protected]> napisał:
> >> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> >> >>> Signed-off-by: Rafał Miłecki <[email protected]>
> >> >>> ---
> >> >>> drivers/net/wireless/b43/main.c | 6 ++++++
> >> >>> drivers/net/wireless/b43/phy_common.c | 7 +++++++
> >> >>> drivers/net/wireless/b43/phy_common.h | 2 ++
> >> >>> drivers/net/wireless/b43/phy_n.c | 7 -------
> >> >>> 4 files changed, 15 insertions(+), 7 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >> >>> index fa48803..670fd7b 100644
> >> >>> --- a/drivers/net/wireless/b43/main.c
> >> >>> +++ b/drivers/net/wireless/b43/main.c
> >> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >> >>>
> >> >>> flags |= B43_TMSLOW_PHYCLKEN;
> >> >>> flags |= B43_TMSLOW_PHYRESET;
> >> >>> + if (dev->phy.type == B43_PHYTYPE_N) {
> >> >>> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >> >>
> >> >> Is channel_type already set at this time?
> >> >
> >> > Yeah, that core switching seems to be a little tricky. I didn't figure
> >> > it out completely yet. We may need to fix that, or fix calls to this
> >> > function.
> >> >
> >> > Thanks for reviewing!
> >>
> >> In other words: it will work for now, but we need to fix that in
> >> future if we want to get 40 MHz channels working.
> >
> > That's exactly what I was saying. ;)
> > To answer my original question: No, channel_type is not set, but the
> > code will work for non-40mhz.
> >
> > This seems a bit tricky to fix, though. Maybe we should reset the
> > wireless core twice. Once initially and once again after the
> > configuration was set. The first reset would just be to be able
> > to access the PHY and wireless core at all to probe it.
>
> Even more tricky is that we already reset code twice... At least in
> b43_wireless_core_attach. Will have to redesign that a little.
I don't think so.
We will have to live with at least two resets.
The first is to make the device accessible, so that we can fetch
the device type and revision numbers (phy type, rev, radio type,....)
After that is done, the device is shut down completely and reinitialized
when the interface comes up with the correct parameters.
It is important that no device setup is done whatsoever at attach stage.
Doing so would also break suspend/resume.
I do not think a redesign of the init code is required.
--
Greetings Michael.
On 12/09/2010 08:11 AM, Rafał Miłecki wrote:
> 2010/12/8 Larry Finger <[email protected]>:
>> I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
>> As shown in the NetworkManager log attached, Authentication is successful, but
>> DHCP fails. Either the transmit data is improperly encrypted, or the decryption
>> fails. I will use wireshark to sort that out. Note: Using software encryption
>> makes no difference.
>
> Hm, I expected software encryption to work, that's weird. I don't
> really have nice access to my development machine, so some tests would
> be great.
Actually, when I got wireshark all setup on my netbook and tried again, WPA2
worked with hardware encryption. I'm not sure what the problem was the first time.
I still have no idea why OFDM rates are failing. Any thoughts?
My device lists the following:
Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n
[14e4:4328] (rev 03)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
It has a rev 2 PHY, and a rev 4 0x2055 radio.
I am willing to buy a higher PHY rev device for testing. Any idea what is in a
4324A-BRCM1036? See
http://cgi.ebay.com/Broadcom-Mini-PCI-e-802-11-a-b-g-n-Wireless-Card-/190477425068?pt=LH_DefaultDomain_0&hash=item2c5956d9ac.
Larry
Signed-off-by: Rafał Miłecki <[email protected]>
---
drivers/net/wireless/b43/main.c | 6 ++++++
drivers/net/wireless/b43/phy_common.c | 7 +++++++
drivers/net/wireless/b43/phy_common.h | 2 ++
drivers/net/wireless/b43/phy_n.c | 7 -------
4 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index fa48803..670fd7b 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
flags |= B43_TMSLOW_PHYCLKEN;
flags |= B43_TMSLOW_PHYRESET;
+ if (dev->phy.type == B43_PHYTYPE_N) {
+ if (b43_channel_type_is_40mhz(dev->phy.channel_type))
+ flags |= B43_TMSLOW_PHYCLKSPEED_160MHZ;
+ else
+ flags |= B43_TMSLOW_PHYCLKSPEED_80MHZ;
+ }
ssb_device_enable(dev->dev, flags);
msleep(2); /* Wait for the PLL to turn on. */
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index 0a91fc3..412f1b6 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -429,6 +429,13 @@ void b43_phyop_switch_analog_generic(struct b43_wldev *dev, bool on)
b43_write16(dev, B43_MMIO_PHY0, on ? 0 : 0xF4);
}
+
+bool b43_channel_type_is_40mhz(enum nl80211_channel_type channel_type)
+{
+ return (channel_type == NL80211_CHAN_HT40MINUS ||
+ channel_type == NL80211_CHAN_HT40PLUS);
+}
+
/* http://bcm-v4.sipsolutions.net/802.11/PHY/Cordic */
struct b43_c32 b43_cordic(int theta)
{
diff --git a/drivers/net/wireless/b43/phy_common.h b/drivers/net/wireless/b43/phy_common.h
index 2ed60e5..2401bee 100644
--- a/drivers/net/wireless/b43/phy_common.h
+++ b/drivers/net/wireless/b43/phy_common.h
@@ -436,6 +436,8 @@ int b43_phy_shm_tssi_read(struct b43_wldev *dev, u16 shm_offset);
*/
void b43_phyop_switch_analog_generic(struct b43_wldev *dev, bool on);
+bool b43_channel_type_is_40mhz(enum nl80211_channel_type channel_type);
+
struct b43_c32 b43_cordic(int theta);
#endif /* LINUX_B43_PHY_COMMON_H_ */
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index d41da7f..3517341 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -88,13 +88,6 @@ static void b43_nphy_rf_control_override(struct b43_wldev *dev, u16 field,
static void b43_nphy_rf_control_intc_override(struct b43_wldev *dev, u8 field,
u16 value, u8 core);
-static inline bool b43_channel_type_is_40mhz(
- enum nl80211_channel_type channel_type)
-{
- return (channel_type == NL80211_CHAN_HT40MINUS ||
- channel_type == NL80211_CHAN_HT40PLUS);
-}
-
void b43_nphy_set_rxantenna(struct b43_wldev *dev, int antenna)
{//TODO
}
--
1.6.3.3
2010/12/9 Larry Finger <[email protected]>:
> I am willing to buy a higher PHY rev device for testing. Any idea what is in a
> 4324A-BRCM1036? See
> http://cgi.ebay.com/Broadcom-Mini-PCI-e-802-11-a-b-g-n-Wireless-Card-/190477425068?pt=LH_DefaultDomain_0&hash=item2c5956d9ac.
Shipping to: United States
:(
--
Rafał
On Thu, 2010-12-09 at 15:23 +0100, Rafał Miłecki wrote:
> W dniu 9 grudnia 2010 15:19 użytkownik Michael Büsch <[email protected]> napisał:
> > On Thu, 2010-12-09 at 15:13 +0100, Rafał Miłecki wrote:
> >> W dniu 9 grudnia 2010 15:12 użytkownik Rafał Miłecki <[email protected]> napisał:
> >> > W dniu 7 grudnia 2010 22:08 użytkownik Michael Büsch <[email protected]> napisał:
> >> >> On Tue, 2010-12-07 at 21:55 +0100, Rafał Miłecki wrote:
> >> >>> Signed-off-by: Rafał Miłecki <[email protected]>
> >> >>> ---
> >> >>> drivers/net/wireless/b43/main.c | 6 ++++++
> >> >>> drivers/net/wireless/b43/phy_common.c | 7 +++++++
> >> >>> drivers/net/wireless/b43/phy_common.h | 2 ++
> >> >>> drivers/net/wireless/b43/phy_n.c | 7 -------
> >> >>> 4 files changed, 15 insertions(+), 7 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> >> >>> index fa48803..670fd7b 100644
> >> >>> --- a/drivers/net/wireless/b43/main.c
> >> >>> +++ b/drivers/net/wireless/b43/main.c
> >> >>> @@ -1150,6 +1150,12 @@ void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags)
> >> >>>
> >> >>> flags |= B43_TMSLOW_PHYCLKEN;
> >> >>> flags |= B43_TMSLOW_PHYRESET;
> >> >>> + if (dev->phy.type == B43_PHYTYPE_N) {
> >> >>> + if (b43_channel_type_is_40mhz(dev->phy.channel_type))
> >> >>
> >> >> Is channel_type already set at this time?
The more I think about this, the wronger it looks to me.
Why do we care about the channel type at reset time anyway?
I guess the channel type is a parameter that can change any time on an
operating card. So just unconditionally set B43_TMSLOW_PHYCLKSPEED_80MHZ
at reset time and set the correct TMSLOW bits later when channel_type is
actually changed. That seems to be the only sane thing to do.
I guess we don't want to fully reset the device when channel_type
changes, do we?
--
Greetings Michael.
2010/12/8 Larry Finger <[email protected]>:
> I have a bit more info regarding the problem with WPA2 encryption on an N PHY.
> As shown in the NetworkManager log attached, Authentication is successful, but
> DHCP fails. Either the transmit data is improperly encrypted, or the decryption
> fails. I will use wireshark to sort that out. Note: Using software encryption
> makes no difference.
Hm, I expected software encryption to work, that's weird. I don't
really have nice access to my development machine, so some tests would
be great.
--
Rafał