Broadcom releases an open-source driver for its wireless chipsets | Hacker News Reader

Broadcom releases an open-source driver for its wireless chipsets

lwn.net

82 pointsgoplexian27 comments

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.

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.

As I understand it, ATI is almost doing that by providing information to authors of open-source drivers.

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... 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.

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

They typically laser-cut traces etc nowadays.

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

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

http://www.lmgtfy.com/?q=geforce+softmodding

It is. Making a new chip is very very expensive, but copying it is cheap. People demand millions of low end systems but only thousands of high end.

What companies do is use mass production for lowering the price not only of their low-end chips but high end too. They just disable and don't test the "advanced features" in low end cards.

With drivers you could enable it. Some blocks could be damaged(as it was not tested) but as a much lower price you just can buy new cheap ones.

Drivers are IP. When a company goes tits that usually the last asset to be sold.

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.

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.

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.)

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)

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.

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/

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.

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.

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?

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

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.

From the comments: "Has hell frozen over?"

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

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

All of FOSS is not Linux.

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 :)

I'm not a driver author, but I'd hazard a guess that the source for a Linux driver is a lot easier to port to BSD than the binary.

Reply on news.ycombinator.com