Re: [PATCH] b43: add config option to force QoS off
On Sunday 13 December 2009 17:45:31 Albert Herranz wrote: > The b43 driver includes a capability mechanism that open source firmwares > (like OpenFWWF) can use to inform the driver about supported > characteristics. > The OpenFWWF firmware doesn't support yet QoS and reflects that via > its capabilities word. > QoS is enabled by default when b43 starts (unless modparam_qos is set to 0). > If the capabilities word of the firmware loaded informs that QoS is not > supported then QoS is disabled. > > Unfortunately, due to an unidentified bug, this automatic disabling of > QoS doesn't work properly. It works, though, if QoS is disabled from the very > beginning. 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 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. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add config option to force QoS off
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 > > > > 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). johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add config option to force QoS off
2009/12/14 Johannes Berg : > 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 >> > >> > 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 Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add config option to force QoS off
On Mon, 2009-12-14 at 22:43 +0100, Rafał Miłecki wrote: > 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)? Afaict the driver never reloads the firmware from userspace, it just reprograms it onto the device, so your question is moot. However, it does register _before_ loading it, the new async work allows it to do it the other way around. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
