2009/12/14 Johannes Berg <[email protected]>: > On Sun, 2009-12-13 at 19:17 +0100, Albert Herranz wrote: > >> > Well, something in mac80211 was changed that breaks this. >> > mac80211 currently seems to assume that the number of queues does not >> > change >> > after ieee80211_register, which was not the case previously. This breaks >> > the QoS disable, because b43 modifies the nr of queues variable in the >> > ieee80211_hw structure. >> > >> >> This patch adds a config option to allow disabling QoS from the beginning. >> >> This is the only way to workaround the described problem when building the >> >> b43 driver in-kernel, as in that case modparam_qos can't be changed. >> >> >> >> Signed-off-by: Albert Herranz <[email protected]> >> > >> > Why are we currently adding all kind of workaround patches instead of >> > fixing the bugs? >> > This bug's been there for months, so I don't see a reason to push out a >> > workaround now. >> > >> >> I'm fine not pushing this workaround upstream. I can carry the workaround >> locally. >> >> Is someone (apart from you) aware of this bug and looking at mac80211 to fix >> it? > > I don't even consider it a bug in mac80211. Once you register your > capabilities, they're fair game. If you need to register them based on > firmware capabilities, load the firmware before you register, like I did > with my [RFC] patch to ar9170 (which I'll be sending soon since the > required patch is going into mainline).
I believe we ieee80211_register_hw in b43 once but it may happen we reload firmware while having device still registered. Should we really ieee80211_unregister_hw and ieee80211_register_hw on every time we reload firmware (as we may load one with other capabilities)? -- Rafał _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
