Test kernel with Broadcom BCM43xx wireless support.

[David Woodhouse]

On Thu, 2006-01-05 at 23:15 -0500, Dan Williams wrote:
> NM does try to set the bitrate to 0 in infrastructure mode.  According
> to the WEXT spec, a bitrate of 0 means "default" or "unset", which
> means the card needs to clear any previously set bitrate and switch to
> its default bitrate.

OK, then as soon as we fix the driver to automatically fall back to a
working bitrate, rather than _staying_ at its default bitrate even
though it can't associate with the AP, we should be fine with NM.

NM works OK for me with it anyway, since I can actually use 54M rate
(although it's a lot better if I back down to 11M. I think we also have
a txpower problem with higher rates).

> What exactly are the issues that the driver has with NM?

I don't think any of them are NM's fault at this point. NM just pokes at
it in a manner which is different to most of its testing, and undoes our
workarounds like the 'rate 11M' trick.

One thing I did notice was that while the module lacked a module table
entry for hotplug, NM complained of not knowing its driver name. Then it
repeatedly triggered an assertion about a mutex being NULL. Remove the
entries matching your card from /lib/modules/`uname -r`/modules.pcimap
to reproduce.

I've now added the appropriate table to the bcm43xx driver -- but I'm
not sure I should have done; I'm not entirely sure I _want_ it being
autoloaded just yet. NM ought to have coped, surely?

-- 
dwmw2