[PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Michael Buesch]

This is the first part for the rewrite of the b43 PHY API.
This is needed in order to make development of N and LP code possible.

PLEASE TEST TEST TEST TEST TEST

Lots of testing on lots of different devices is needed to ensure this
doesn't introduce regressions due to typos.
95% of the patch just moves large parts of the PHY code from one file
to another. More move-patches will follow.
5% of the patch introduces an "ops" based PHY API.

Please test on all of your devices.

http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch
Apply against wireless-testing.git

(Not attached to the mail, as it is really big)

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Larry Finger]

Michael Buesch wrote:
> This is the first part for the rewrite of the b43 PHY API.
> This is needed in order to make development of N and LP code possible.
> 
> PLEASE TEST TEST TEST TEST TEST
> 
> Lots of testing on lots of different devices is needed to ensure this
> doesn't introduce regressions due to typos.
> 95% of the patch just moves large parts of the PHY code from one file
> to another. More move-patches will follow.
> 5% of the patch introduces an "ops" based PHY API.
> 
> Please test on all of your devices.

The patch works fine on the 802.11g portion of my BCM4312/1, which 
seems to be the same as a BCM4311/1. This card has a PCIe format. I 
also tested on my PCMCIA version of a BCM4318. That card works, but 
the maximum transmit rate is only about 1/2 of what I get without it. 
The card has a rev 09 802.11 core, a rev 7 PHY, and a rev 3 analog 
part. I still have to test on a PCI format BCM4306/3 card, but I 
suspect that you have already tested the 4306.

Larry

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Larry Finger]

Larry Finger wrote:
> 
> The patch works fine on the 802.11g portion of my BCM4312/1, which seems 
> to be the same as a BCM4311/1. This card has a PCIe format. I also 
> tested on my PCMCIA version of a BCM4318. That card works, but the 
> maximum transmit rate is only about 1/2 of what I get without it. The 
> card has a rev 09 802.11 core, a rev 7 PHY, and a rev 3 analog part. I 
> still have to test on a PCI format BCM4306/3 card, but I suspect that 
> you have already tested the 4306.

Forget what I said about the loss of transmit rate. Once I did a 
proper test, it is the same with or without the patch. For the 
BCM4318, the b43 rate is slightly reduced from using bcm43xx. The 
difference is not really great, but a reproducible reduction from 16.6 
to 14.2 Mbs with the iwconfig rate set at 54 Mbs. By comparison, the 
BCM4312 is over 20 Mbs.

Larry

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Michael Buesch]

On Saturday 16 August 2008, Larry Finger wrote:
> Larry Finger wrote:
> > 
> > The patch works fine on the 802.11g portion of my BCM4312/1, which seems 
> > to be the same as a BCM4311/1. This card has a PCIe format. I also 
> > tested on my PCMCIA version of a BCM4318. That card works, but the 
> > maximum transmit rate is only about 1/2 of what I get without it. The 
> > card has a rev 09 802.11 core, a rev 7 PHY, and a rev 3 analog part. I 
> > still have to test on a PCI format BCM4306/3 card, but I suspect that 
> > you have already tested the 4306.
> 
> Forget what I said about the loss of transmit rate. Once I did a 
> proper test, it is the same with or without the patch. For the 
> BCM4318, the b43 rate is slightly reduced from using bcm43xx. The 
> difference is not really great, but a reproducible reduction from 16.6 
> to 14.2 Mbs with the iwconfig rate set at 54 Mbs. By comparison, the 
> BCM4312 is over 20 Mbs.

Thanks a lot for retesting.
Loss of TX rate would be the worst thing that can happen with this patch, as
it's very very hard to debug due to the size.

I didn't test it on all of my devices, yet. I just tried a 4306, where it
doesn't cause any regression.

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Ehud Gavron]

Works fine here.  iperf same results as prior to patch. 

b43-phy0: Broadcom 4311 WLAN found
b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2

2.6.27-rc2-wl on Ubuntu 8.04 (don't even ask how long it takes to build 
a new kernel and create a debian package and install it...)

Ehud

Michael Buesch wrote:
> This is the first part for the rewrite of the b43 PHY API.
> This is needed in order to make development of N and LP code possible.
>
> PLEASE TEST TEST TEST TEST TEST
>
> Lots of testing on lots of different devices is needed to ensure this
> doesn't introduce regressions due to typos.
> 95% of the patch just moves large parts of the PHY code from one file
> to another. More move-patches will follow.
> 5% of the patch introduces an "ops" based PHY API.
>
> Please test on all of your devices.
>
> http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch
> Apply against wireless-testing.git
>
> (Not attached to the mail, as it is really big)
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>   

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Larry Finger]

Ehud Gavron wrote:
> Works fine here.  iperf same results as prior to patch.
> b43-phy0: Broadcom 4311 WLAN found
> b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> 
> 2.6.27-rc2-wl on Ubuntu 8.04 (don't even ask how long it takes to build 
> a new kernel and create a debian package and install it...)

I know, which is one of the reasons I don't use a Debian-based distro. 
I want nothing to do with one whose stated goal is to make it so 
difficult to change the kernel that the users won't do it.

Larry

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Holger Schurig]

> I know, which is one of the reasons I don't use a Debian-based
> distro. I want nothing to do with one whose stated goal is to
> make it so difficult to change the kernel that the users won't
> do it.

Huh?  I use "make install modules_install" from my kernel source 
dir (which I usually get via git) and that works fine, as in 
every distro on earth.

Hehe, but I seldom use distro kernels, not even when I used Red 
Hat or Mandrake in old times :-)

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Michael Buesch]

On Monday 18 August 2008 09:41:10 Holger Schurig wrote:
> > I know, which is one of the reasons I don't use a Debian-based
> > distro. I want nothing to do with one whose stated goal is to
> > make it so difficult to change the kernel that the users won't
> > do it.
> 
> Huh?  I use "make install modules_install" from my kernel source 
> dir (which I usually get via git) and that works fine, as in 
> every distro on earth.

I can only second that.
I simply ignore any distro specific kernel handling and override
the grub/yaboot entries as I desire. I also ignore any rpm or deb
for installing a kernel. I do it this way since the very beginning
and it works fine on debian and non-debian distros.

In general, I do always ignore the packet manager, but install
custom compiled software in a specific directory so it does not
interfere in any way with the distro packets.


-- 
Greetings Michael.

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Larry Finger]

Holger Schurig wrote:
> Huh?  I use "make install modules_install" from my kernel source 
> dir (which I usually get via git) and that works fine, as in 
> every distro on earth.
> 
> Hehe, but I seldom use distro kernels, not even when I used Red 
> Hat or Mandrake in old times :-)

I tried that with Ubuntu 8.04 and the resulting kernel wouldn't boot. 
Only when I went through the process of making the ".deb" and 
installing that did the new kernel start properly. I didn't 
investigate it thoroughly as I was only testing one patch - I quickly 
fled back to openSUSE.

Larry

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Michael Buesch]

On Sunday 17 August 2008 21:26:21 Ehud Gavron wrote:
> Works fine here.  iperf same results as prior to patch. 
> 
> b43-phy0: Broadcom 4311 WLAN found
> b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2

Thanks a lot for testing.

I want to encourage people again to test this patch.
This really needs a lot of testing, because a regression caused by this
would really really be a bad thing.
Even if you think your card was already tested by somebody else, please test
it anyway. There are so many different cards with matching revision numbers
that really are slightly different.

Get wireless-testing.git:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

and apply the patch
http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch

Please test basic features, throughput and longterm stability of the connection.

-- 
Greetings Michael.

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Larry Finger]

Michael Buesch wrote:
> This is the first part for the rewrite of the b43 PHY API.
> This is needed in order to make development of N and LP code possible.
> 
> PLEASE TEST TEST TEST TEST TEST
> 
> Lots of testing on lots of different devices is needed to ensure this
> doesn't introduce regressions due to typos.
> 95% of the patch just moves large parts of the PHY code from one file
> to another. More move-patches will follow.
> 5% of the patch introduces an "ops" based PHY API.
> 
> Please test on all of your devices.

I have now tested on a BCM4311/2 with positive results. The transmit 
throughput is roughly the same at 20.7 Mbs with a 54 Mbs bulk rate.

Larry

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Michael Buesch]

On Thursday 21 August 2008 00:40:32 Larry Finger wrote:
> Michael Buesch wrote:
> > This is the first part for the rewrite of the b43 PHY API.
> > This is needed in order to make development of N and LP code possible.
> > 
> > PLEASE TEST TEST TEST TEST TEST
> > 
> > Lots of testing on lots of different devices is needed to ensure this
> > doesn't introduce regressions due to typos.
> > 95% of the patch just moves large parts of the PHY code from one file
> > to another. More move-patches will follow.
> > 5% of the patch introduces an "ops" based PHY API.
> > 
> > Please test on all of your devices.
> 
> I have now tested on a BCM4311/2 with positive results. The transmit 
> throughput is roughly the same at 20.7 Mbs with a 54 Mbs bulk rate.

Thanks :)

I'll also do more testing and submit the patch soon.

Anybody who didn't test his device, yet, please do so. If you discover
a breakage after the merge, that will be _very_ unfortunate and we will have
to live with the breakage until it is fixed (which can be very hard to do).

-- 
Greetings Michael.

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Sean Hodges]

On Sat, 2008-08-16 at 00:29 +0200, Michael Buesch wrote:
> This is the first part for the rewrite of the b43 PHY API.
> This is needed in order to make development of N and LP code possible.
> 
> PLEASE TEST TEST TEST TEST TEST
> 
> Lots of testing on lots of different devices is needed to ensure this
> doesn't introduce regressions due to typos.
> 95% of the patch just moves large parts of the PHY code from one file
> to another. More move-patches will follow.
> 5% of the patch introduces an "ops" based PHY API.
> 
> Please test on all of your devices.
> 
> http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch
> Apply against wireless-testing.git

As a novice to driver development, is there some way I can help with
testing this?

I have no experience of driver development/testing, but have an N-PHY
BCM4328 wireless NIC that is just itching to be eventually freed from
ndiswrapper :) I'd be happy to lend some help testing new patches and
feeding back results, if I could get a few pointers on where to get
started...

I'm running 2.6.24-19 kernel release, and my card is listed by lspci as:

06:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n
(rev 03)


Sean

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Michael Buesch]

On Thursday 21 August 2008 18:16:23 Sean Hodges wrote:
> On Sat, 2008-08-16 at 00:29 +0200, Michael Buesch wrote:
> > This is the first part for the rewrite of the b43 PHY API.
> > This is needed in order to make development of N and LP code possible.
> > 
> > PLEASE TEST TEST TEST TEST TEST
> > 
> > Lots of testing on lots of different devices is needed to ensure this
> > doesn't introduce regressions due to typos.
> > 95% of the patch just moves large parts of the PHY code from one file
> > to another. More move-patches will follow.
> > 5% of the patch introduces an "ops" based PHY API.
> > 
> > Please test on all of your devices.
> > 
> > http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch
> > Apply against wireless-testing.git
> 
> As a novice to driver development, is there some way I can help with
> testing this?
> 
> I have no experience of driver development/testing, but have an N-PHY

To say it once again:
Despite the fact that the subject of this email mentiones N and LP PHYs, it
implements _nothing_ N and LP related. It just _prepares_ the code for the
future when we will add N and LP stuff (and other PHY stuff. Also A/B/G related).

-- 
Greetings Michael.

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Sean Hodges]

Thanks for the repeated explanation, the offer remains when it might be
needed.

Sean


On Thu, 2008-08-21 at 18:58 +0200, Michael Buesch wrote:
> On Thursday 21 August 2008 18:16:23 Sean Hodges wrote:
> > On Sat, 2008-08-16 at 00:29 +0200, Michael Buesch wrote:
> > > This is the first part for the rewrite of the b43 PHY API.
> > > This is needed in order to make development of N and LP code possible.
> > > 
> > > PLEASE TEST TEST TEST TEST TEST
> > > 
> > > Lots of testing on lots of different devices is needed to ensure this
> > > doesn't introduce regressions due to typos.
> > > 95% of the patch just moves large parts of the PHY code from one file
> > > to another. More move-patches will follow.
> > > 5% of the patch introduces an "ops" based PHY API.
> > > 
> > > Please test on all of your devices.
> > > 
> > > http://bu3sch.de/patches/wireless-testing/20080816-0023/patches/002-b43-phy-ops.patch
> > > Apply against wireless-testing.git
> > 
> > As a novice to driver development, is there some way I can help with
> > testing this?
> > 
> > I have no experience of driver development/testing, but have an N-PHY
> 
> To say it once again:
> Despite the fact that the subject of this email mentiones N and LP PHYs, it
> implements _nothing_ N and LP related. It just _prepares_ the code for the
> future when we will add N and LP stuff (and other PHY stuff. Also A/B/G related).
> 

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Rafał Miłecki]

MjAwOC84LzE2IE1pY2hhZWwgQnVlc2NoIDxtYkBidTNzY2guZGU+Ogo+IFRoaXMgaXMgdGhlIGZp
cnN0IHBhcnQgZm9yIHRoZSByZXdyaXRlIG9mIHRoZSBiNDMgUEhZIEFQSS4KPiBUaGlzIGlzIG5l
ZWRlZCBpbiBvcmRlciB0byBtYWtlIGRldmVsb3BtZW50IG9mIE4gYW5kIExQIGNvZGUgcG9zc2li
bGUuCj4KPiBQTEVBU0UgVEVTVCBURVNUIFRFU1QgVEVTVCBURVNUCj4KPiBMb3RzIG9mIHRlc3Rp
bmcgb24gbG90cyBvZiBkaWZmZXJlbnQgZGV2aWNlcyBpcyBuZWVkZWQgdG8gZW5zdXJlIHRoaXMK
PiBkb2Vzbid0IGludHJvZHVjZSByZWdyZXNzaW9ucyBkdWUgdG8gdHlwb3MuCj4gOTUlIG9mIHRo
ZSBwYXRjaCBqdXN0IG1vdmVzIGxhcmdlIHBhcnRzIG9mIHRoZSBQSFkgY29kZSBmcm9tIG9uZSBm
aWxlCj4gdG8gYW5vdGhlci4gTW9yZSBtb3ZlLXBhdGNoZXMgd2lsbCBmb2xsb3cuCj4gNSUgb2Yg
dGhlIHBhdGNoIGludHJvZHVjZXMgYW4gIm9wcyIgYmFzZWQgUEhZIEFQSS4KPgo+IFBsZWFzZSB0
ZXN0IG9uIGFsbCBvZiB5b3VyIGRldmljZXMuCj4KPiBodHRwOi8vYnUzc2NoLmRlL3BhdGNoZXMv
d2lyZWxlc3MtdGVzdGluZy8yMDA4MDgxNi0wMDIzL3BhdGNoZXMvMDAyLWI0My1waHktb3BzLnBh
dGNoCj4gQXBwbHkgYWdhaW5zdCB3aXJlbGVzcy10ZXN0aW5nLmdpdAoKQXBwbGllZCB0byB0b2Rh
eSB3aXJlbGVzcy10ZXN0aW5nIGdpdC4gQ29ubmVjdGVkIHRvIG15IEFQIHdpdGhvdXQKcHJvYmxl
bSwgY29ubmVjdGlvbiBzdGFibGUgZm9yIDkwbWluIGFuZCA2MDBNQiBvZiBkb3dubG9hZC4gSSBk
aWRuJ3QKdGVzdCBzcGVlZCBwZXJmb3JtYW5jZSBhcyBteSBhbnRlbm5hIGluIGJyb2tlbi4gU28g
ZXZlcnl0aGluZyBzZWVtcyB0bwp3b3JrIGZpbmUgZm9yIG1lLgoKYjQzLXBjaS1icmlkZ2UgMDAw
MDowNjowNS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDIxIChsZXZlbCwgbG93KSAtPiBJUlEgMjEKYjQz
LXBoeTA6IEJyb2FkY29tIDQzMTggV0xBTiBmb3VuZApiNDMtcGh5MCBkZWJ1ZzogRm91bmQgUEhZ
OiBBbmFsb2cgMywgVHlwZSAyLCBSZXZpc2lvbiA3CmI0My1waHkwIGRlYnVnOiBGb3VuZCBSYWRp
bzogTWFudWYgMHgxN0YsIFZlcnNpb24gMHgyMDUwLCBSZXZpc2lvbiA4CmlucHV0OiBiNDMtcGh5
MCBhcyAvZGV2aWNlcy92aXJ0dWFsL2lucHV0L2lucHV0OApmaXJtd2FyZTogcmVxdWVzdGluZyBi
NDMvdWNvZGU1LmZ3CmZpcm13YXJlOiByZXF1ZXN0aW5nIGI0My9wY201LmZ3CmZpcm13YXJlOiBy
ZXF1ZXN0aW5nIGI0My9iMGcwaW5pdHZhbHM1LmZ3CmZpcm13YXJlOiByZXF1ZXN0aW5nIGI0My9i
MGcwYnNpbml0dmFsczUuZncKYjQzLXBoeTA6IExvYWRpbmcgZmlybXdhcmUgdmVyc2lvbiA0MTAu
MjE2MCAoMjAwNy0wNS0yNiAxNTozMjoxMCkKYjQzLXBoeTAgZGVidWc6IENoaXAgaW5pdGlhbGl6
ZWQKYjQzLXBoeTAgZGVidWc6IDMyLWJpdCBETUEgaW5pdGlhbGl6ZWQKUmVnaXN0ZXJlZCBsZWQg
ZGV2aWNlOiBiNDMtcGh5MDo6dHgKUmVnaXN0ZXJlZCBsZWQgZGV2aWNlOiBiNDMtcGh5MDo6cngK
UmVnaXN0ZXJlZCBsZWQgZGV2aWNlOiBiNDMtcGh5MDo6cmFkaW8KYjQzLXBoeTAgZGVidWc6IFdp
cmVsZXNzIGludGVyZmFjZSBzdGFydGVkCmI0My1waHkwIGRlYnVnOiBBZGRpbmcgSW50ZXJmYWNl
IHR5cGUgMgpiNDMtcGh5MDogUmFkaW8gdHVybmVkIG9uIGJ5IHNvZnR3YXJlCgotLSAKUmFmYcWC
IE1pxYJlY2tpCg==

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY

[Benoît Knecht]

Michael Buesch wrote:
> PLEASE TEST TEST TEST TEST TEST

I tested your patch on my 4318, and it seems performance and stability
are pretty much the same as unpatched wireless-testing. Here's what
dmesg has to say:
# dmesg | grep b43
b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
b43-phy0: Broadcom 4318 WLAN found
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
b43-phy0 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config
firmware: requesting b43/ucode5.fw
firmware: requesting b43/pcm5.fw
firmware: requesting b43/b0g0initvals5.fw
firmware: requesting b43/b0g0bsinitvals5.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 debug: Chip initialized
b43-phy0 debug: 32-bit DMA initialized
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0: Radio turned on by software
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
00:16:b6:a3:26:91
b43-phy0 debug: Using hardware based encryption for keyidx: 1, mac:
ff:ff:ff:ff:ff:ff

and the exact description of my card:
# lspci -vn
0001:10:12.0 0280: 14e4:4318 (rev 02)
        Subsystem: 106b:4318
        Flags: bus master, fast devsel, latency 16, IRQ 52
        Memory at 80084000 (32-bit, non-prefetchable) [size=3D8K]
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

I transfered some files around using both patched and unpatched
wireless-testing, and I get very similar results in both cases:
around 2.6 MB/s upload and 3.5 MB/s download. This is a couple rooms
away from the AP, with a signal quality of 58/100.

I will continue using this kernel for some time, and will report back
here if I notice anything peculiar.

I hope I didn't forget anything useful, but the bottom line is that I
didn't see any difference between patched and unpatched
wireless-testing, and if you need me to run some more tests, I'd be
happy to; please let me know.

--
Beno=C3=AEt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Niklas Wulf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I tested this one on my Macbook Pro (3,1).

# lspci -v
0b:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n
(rev 05)
Subsystem: Apple Computer Inc. Device 008c
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 97300000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information <?>
Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Capabilities: [d0] Express Endpoint, MSI 00
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb

It is not recognized by the driver... should it? I don't get a wireless
device listed in ifconfig nor does dmesg show any device.

# ifconfig
eth0 [...]
lo [...]

# dmesg
[...]
Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]
[...]

I'm kind of new to all this wireless stuff. Linuxwireless.org tells me
4328 does not work because of missing N Phys support, so I hoped this
patch would make some difference.

A problem could be the wrong firmware version. OS X says the Chip has
4.150.10.__6__ but I can only find 4.150.10.5. Is this important?

PS: This is my first mail-list-post. Tell me if something's not okay,
please ;-)

Greetings Niklas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIq12JmLNpi6N88eMRApqkAKC+HIt4LDcKcBJVywv5rQsRxpZUcACeI2OF
IoTteOy1itgYu1qtHQfgvbU=
=wM1s
-----END PGP SIGNATURE-----

Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311

[Larry Finger]

Niklas Wulf wrote:
> I tested this one on my Macbook Pro (3,1).
> 
> # lspci -v
> 0b:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n
> (rev 05)
> Subsystem: Apple Computer Inc. Device 008c
> Flags: bus master, fast devsel, latency 0, IRQ 16
> Memory at 97300000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [58] Vendor Specific Information <?>
> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
> Enable-
> Capabilities: [d0] Express Endpoint, MSI 00
> Kernel driver in use: b43-pci-bridge
> Kernel modules: ssb
> 
> It is not recognized by the driver... should it? I don't get a wireless
> device listed in ifconfig nor does dmesg show any device.

No, the driver is not loading correctly because the N PHY is not yet 
supported. The reverse engineering for that device is barely started.

> # ifconfig
> eth0 [...]
> lo [...]
> 
> # dmesg
> [...]
> Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]
> [...]
> 
> I'm kind of new to all this wireless stuff. Linuxwireless.org tells me
> 4328 does not work because of missing N Phys support, so I hoped this
> patch would make some difference.

No, that patch is just preparation for what will happen in the future 
when both LP and N PHYs are supported.

> A problem could be the wrong firmware version. OS X says the Chip has
> 4.150.10.__6__ but I can only find 4.150.10.5. Is this important?

Driver 4.150.10.5 is a MIPS driver for Linux. Obviously 4.150.10.6 is 
an OS X driver. I wouldn't expect any difference in the embedded 
firmware between them.

Larry