

Broadcom releases an open-source driver for its wireless chipsets - goplexian
http://lwn.net/Articles/404248/

======
Zak
I don't understand why more commodity hardware companies aren't doing this.
Drivers are an actual competitive advantage with 3D video cards and possibly a
few other things, but I can't see it for wireless chipsets. It seems to me
that making the drivers open source might actually reduce costs, with no real
down sides.

~~~
yason
3D video cards are a commodity, too, these days. Even they could offer open-
source reference drivers that allow for full basic utilization of the
hardware, albeit at suboptimal performance. The heavily-optimized trade secret
like cool codepaths could be offered in binary drivers for those who want the
last drop of perf.

~~~
dfox
The business problem of open source 3D drivers lies not so much in secret
know-how in the drivers but in this:
[http://steveblank.com/2009/04/16/supermac-war-
story-7-buildi...](http://steveblank.com/2009/04/16/supermac-war-
story-7-building-the-whole-product/) High-end graphics cards tend to be
exactly same as consumer level cards, save for few bits in some configuration
memory that is used by driver to disable more advanced features/reduce
performance.

~~~
cdavid
Is this relevant to the current 3d cards market ? I somehow doubt it.

~~~
wmf
It is relevant; people are "softmodding" GeForces into Quadros, theoretically
costing Nvidia millions in revenue. Open-source drivers might make this even
easier.

~~~
ciupicri
Do you have more details about this? Maybe a link or something.

~~~
wmf
<http://www.lmgtfy.com/?q=geforce+softmodding>

------
JoeAltmaier
I struggled with vendor drivers for chipsets for years (yes this company too).
They are generally awful. Most are warmed-over demo drivers from the original
silicon vendor, intended to exercise chip features but no diligence to adhere
to specs, protocols, handle (any) error conditions, be readable or
supportable.

Vendor "support" for their driver means a third-string intern/student who
hashes together patches that reveal profound ignorance of the architecture.

Its not just NIH; the chain of custody from silicon designer to you just
doesn't include ANYBODY who has your interests/your customer's interests in
mind. They are more concerned with making the driver portable across their
product line, doing it cheaply, getting it to market at the same time their
hardware releases etc.

Any robustness/architecture/responsible software processes have to be your
business and yours alone. This probably means rewriting the whole driver,
using the demo driver for reference but ONLY for chip-specific info.

~~~
wmf
I agree completely with what you said (e.g. the BCM5700 driver was rewritten
as tg3), but in this case it's much better to have a crappy vendor driver than
to have nothing from the vendor, which was the situation yesterday.

------
acqq
Congratulations Broadcom! It's nice to see you becoming a Linux-friendly
company! It's certainly a new chapter in the history of the company!

(People who use Linux and your chipsets already know why this is such a good
news.)

------
jallmann
Great to see this. Broadcom also came out with drivers for its CrystalHD
decoder chip a while ago (<http://www.broadcom.com/support/crystal_hd/>) and
they are actively involved in community development of the driver
(<http://groups.google.com/group/crystalhd-development>)

------
jey
I'm looking at the source and the code that interfaces with the PHY has had
every single comment stripped out of it. I don't see the point of that, it'll
just take a bit longer for the code to be understood... after all, these guys
have even black-box reverse-engineered many NICs.

~~~
woodall
For those who didn't know

"black box" reverse engineering - systems are observed without examining
internal structure.

"white box" reverse engineering - the inner workings of the system are
inspected.

<http://www.chillingeffects.org/reverse/faq.cgi#QID188>

<http://multimedia.cx/eggs/black-box-re/>

------
kelnos
Unfortunately, it looks like the new driver only supports 3 chipsets, and none
of the "older" SSB-based ones. Granted, it's a new driver, and they say it's
designed with the idea that other chipsets can be added, but it's still a
little disappointing.

(I say "older," because my BCM4322 is such a chipset, and it's in my 15-month-
old MacBook Pro. How is that "old?")

Regardless, whatever their motivations, it's a nice start. I wonder if they
plan to collaborate with the guys working on the b43 driver at all. They
support a ton of chipsets, and (at least from my perspective) the main
deficiency is the not-yet-finished (partly due to the reverse-engineering
effort being incomplete) N-PHY support for the 11n chipsets.

------
zacharycohn
Well I'll be hit in the face with a tire iron. Didn't see this one coming.

Now if only this happened two years ago, I'd have been running linux for two
years.

------
morisy
I feel like there has got to be a gotcha or two in there, but if not, this is
great news. I wonder how much the proliferating netbook market is to blame for
it?

~~~
joezydeco
Wanna bet it's so they don't get left behind in the ChromeOS reference
designs?

~~~
kelnos
I hear Google's been putting pressure on manufacturers to avoid using binary
blobs in the kernel on Android. This could be related to that as well.

------
lenni
From the comments: "Has hell frozen over?"

------
GeneralMaximus
This is good news for operating systems besides Linux, too. I might be able to
run Haiku on my laptop now :)

------
konad
Great and all but "Linux drivers are not documentation"!

All of FOSS is not Linux.

~~~
sparky
I agree with you, but if I had to choose between a functional Linux driver and
documentation, even as someone running BSD, I would take the Linux driver
every time. A functional driver with source lends some confidence that nothing
is missing. Documentation can be well-intentioned, but it is rarely so
complete that you could write a major piece of software with nothing else.

Of course, drivers+documentation would be even better :)

