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

Broadcom's wireless drivers, one year later

Posted Aug 29, 2011 23:56 UTC (Mon) by PaulWay (guest, #45600)
Parent article: Broadcom's wireless drivers, one year later

Forgive this for being somewhat blunt, but how did this go on for eleven months without anyone pointing out that the Broadcom developers were aiming for a twin of b43? Why didn't someone back in September 2010 say to them "well, that's nice and all, and we can help you get that ready for inclusion into the kernel, but we already have this perfectly good driver, why don't you save yourself some work and just improve that?" Why didn't Rafał say something at that stage, rather than eleven months down the track?

It's obvious, perhaps, in hindsight. I'm sure there are reasons that these delays occurred. And I can understand from Broadcom's perspective it may still think that it needs to support its own code rather than someone else's. But in general we've been asking, begging, and extending olive branches to hardware manufacturers; we really need to make these interactions work. If more manufacturers thought they could piggy-back on the existing work of the Linux kernel and help out rather than having to write everything from scratch and then go through the arduous process of preparing it for mainline only to meet resistance from existing driver maintainers.

Have fun,

Paul

to post comments

Broadcom's wireless drivers, one year later

Posted Aug 30, 2011 0:54 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

the key is that a year ago the b43 driver didn't support a lot of hardware that the broadcom driver already supported, and there was little (if anything) that the b43 driver supported that the broadcom driver didn't support

so it was easy to see the broadcom driver as being a superset of the b43 driver.

they probably thought that it would be less work to modify the already working broadcom driver to fit the kernel better than it would be to modify the reverse engineered b43 driver to support all the other stuff.

as it appears to have turned out, the team working to improve the b43 driver was able to add support faster than the broadcom team was able to revamp their driver to fit the kernel.

it could have easily turned out the other way. If the changes had not turned out to be as intrusive, or if the b43 team had not been as quick to add new support we could easily be celebrating replacing the reverse engineered driver that works for most people most of the time with a driver that supports all the chipsets all of the time because the people developing it understand the chipsets better.

and there is still the unanswered question of how much the broadcom driver being in staging helped the b43 driver team

Broadcom's wireless drivers, one year later

Posted Aug 30, 2011 17:44 UTC (Tue) by mlankhorst (subscriber, #52260) [Link]

To be fair, if you read the thread you do see there are things that just work better with brcmsmac driver, especially 802.11n, but it lacks features that b43 has, like using it on a SoC router as AP. Especially the PHY code might be useful for b43.

Disclaimer: I'm not a wireless-dev :)