Broadcom BCM4306/BCM2050 support
Quoted 3 lines · David S. Miller
Don't expect specs or opensource drivers for any of these pieces of hardware until these vendors figure out a way to hide the frequency programming interface.
What did Intersil do? How did the linux-wlan-ng project handle this?
Quoted 5 lines
The only halfway plausible idea I've seen is to not document the frequency programming registers, and users get a "region" key file that has opaque register values to program into the appropriate registers. The file is per-region (one for US, Germany, etc.)and the wireless kernel driver reads in this file to do the frequency programming.
Here in The Netherlands, it is quite common to use a US version of Windows and to keep (most of) the regional settings of the US. So on Windows, most of the time the region is likely to be wrong. I gues that in cases where things are critical, a different firmware version is used.
It is not really a practical problem however, because the allowed frequencies have become pretty the same over time. The same applies to modems: they are also country-specific. But in practice, it is not really a concern.
But how to go furter with this? Does someone have contacts within Broadcom?
Regards,
Bas.
--------------------------------------------------------------------------------
Quoted 5 lines · On Tue, Apr 29, 2003 at 02:51:12PM +0200, [email protected] wrote:
Quoted 3 lines
Don't expect specs or opensource drivers for any of these pieces of hardware until these vendors figure out a way to hide the frequency programming interface.
What did Intersil do? How did the linux-wlan-ng project handle this?
The linux-wlan-ng project only handles the prism2/2.5/3 chipsets, which are *extremely* well documented (and 2.4G-only), so there really isn't anything to "handle"; from the driver perspective you just say "give
me channel X" and that's it. If the eeprom-based tables say you can
use the channel, it lets you; otherwise it's No Soup For You.
Intersil is a poor example; they've generally been quite forthcoming with documentation. Granted, the docs for the PrismGT/etc stuff are pretty bad, but you can get them without selling your soul.
(it's also worth mentioning that Intersil partially funded linux-wlan-ng's development)
RF tables and regulation might be an excuse chipset companies use to hide their specs, but the real reasons tend to be a bit more along the lines of:
"We want to protect our valuable IP"
...which translates to:
"We want to protect our violations of other people's valuable IP"
It's CYA, plain and simple. They're so terrified of litigation that they feel that *any* semi-public information (even if only source code) is a threat.
Many of them genuinely want to provide Linux support, in the form of binary drivers much like Windows has. Then they balk when realizing what a support hell (and $$$) it will be to pull it off without providing source code, thanks to the monolothic nature of the Linux kernel.
Or at least that's been my experience in the past year.
- Pizza
Signature · 3 lines
Solomon Peachy pizza@f*cktheusers.org
ICQ #1318444
Quidquid latine dictum sit, altum viditur Melbourne, FLQuoted 11 lines · Stuffed Crust
RF tables and regulation might be an excuse chipset companies use to hide their specs, but the real reasons tend to be a bit more along the lines of:
"We want to protect our valuable IP"
...which translates to:
"We want to protect our violations of other people's valuable IP"
It's CYA, plain and simple.
This is very far from the truth. And as Alan and myself have been talking to upper management entities at various wireless card companies we know the real reason has to do with making regulation agencies happy. They do have drivers, and they do want to publish them and yes they recognize that this will expose a lot of their IP and they accept that.
Signature · 1 line
David S. Miller <[email protected]>