Broadcom's wireless drivers, one year later [LWN.net]

Broadcom's wireless drivers, one year later

Posted Aug 31, 2011 17:56 UTC (Wed) by mjg59 (subscriber, #23239)
In reply to: Broadcom's wireless drivers, one year later by jezuch
Parent article: Broadcom's wireless drivers, one year later

If b43 got far enough to say "unknown phy" then it's unlikely that the Broadcom driver will work. It sounds like an SSB chip, whereas brcmsmac only handles BCMA ones.

Understanding the difference between the two drivers depends on understanding the setup of Broadcom's hardware. Each chip contains its own internal bus plus some glue to the host bus. On PCs, that'll typically be to PCI or PCIe. The internal bus may then be either SSB (for older chips) or BCMA (for newer chips). b43 doesn't include the code for handling these buses - instead, that's in separate ssb and bcma layers. Given that similar phys can be present on both SSB and BCMA hardware, that simplifies the programming - b43 simply binds to the phy, no matter what the chip's bus architecture.

I've no idea if it's true, but a commonly cited reason for brcmsmac not supporting older hardware is that the older hardware is unable to run firmware that can prevent the OS from programming arbitrary frequencies, and so FCC paranoia comes into play. In any case, brcmsmac doesn't support any ssb chips and there's no indication from Broadcom that it ever will. We could keep b43 for ssb devices and leave bcma devices to brcmsmac, but that would result in some duplication of phy code. We could merge ssb support into brcmsmac, but that would cause the driver to diverge from Broadcom's internal codebase and may well make it harder for them to merge code back and forth. We could deprecate brcmsmac and devote all development efforts to b43, but there's little sign that Broadcom would have any interest in that.

All of these solutions suck, but at some point Broadcom have to take some responsibility. If they'd been more cooperative 7 years ago, b43 wouldn't exist at all.

to post comments

Broadcom's wireless drivers, one year later

Posted Sep 1, 2011 2:15 UTC (Thu) by paragw (guest, #45306) [Link] (2 responses)

"We could keep b43 for ssb devices and leave bcma devices to brcmsmac, but that would result in some duplication of phy code."

That to me sounds like the only practical option - even attractive one given the others. If we are not talking tens of thousands of LOC - I don't see why that it would be so bad.

May be some portion of "baked" phy code can be made common and shared across b43 and brcmsmac - the one that is totally obvious and is not likely to change much.

Broadcom's wireless drivers, one year later

Posted Sep 1, 2011 23:48 UTC (Thu) by mb (subscriber, #50428) [Link] (1 responses)

> That to me sounds like the only practical option - even attractive one given the others. If we are not talking tens of thousands of LOC - I don't see why that it would be so bad.

What about embedded BCMA? brcmsmac doesn't support it.

Broadcom's wireless drivers, one year later

Posted Sep 2, 2011 3:10 UTC (Fri) by paragw (guest, #45306) [Link]

>What about embedded BCMA? brcmsmac doesn't support it.

That's drivers/bcma right? Additional 1727 lines of code on top of b43+ssb - which isn't all that bad. May be getting rid of duplicate hardware support from b43 could compensate some.

Broadcom's wireless drivers, one year later

Posted Sep 10, 2011 9:46 UTC (Sat) by slashdot (guest, #22014) [Link] (1 responses)

There's always to option to leave things as they are now.

bcsmsmac stays in staging forever, and gets worked on by Broadcom engineers.

End-users mostly use b43 instead, and the b43 developers port any new feature appearing in bcsmsmac to b43 (with acknowledgements, preferably).

Broadcom's wireless drivers, one year later

Posted Sep 11, 2011 0:36 UTC (Sun) by butlerm (guest, #13312) [Link]

I agree. I don't see why Broadcom doesn't develop an open reference driver on an out of tree basis, according to whatever conventions they prefer, and let developers of compatible drivers use it as a reference.

That way they maintain 100% control, one code base that they can deploy across multiple operating systems, and others can do whatever they feel is appropriate for local standards, code sharing, and long term maintenance.