On Wed, Jun 29, 2011 at 10:56:33AM +0200, Michel Alexandre Salim wrote: > I agree with you and Adrian; it should ideally be in the 802.11 > stack. But as Ben noted, it does have a useful purpose -- for > debugging. > > If the maintainers are agreeable to a shared mac80211 mechanism, > which is the preferred way to handle this -- get this in, then > refactor *both* iwlagn and ath9k to use it, or to implement a shared > mechanism, demonstrate it with ath9k, then fix iwlagn later? I don't follow this.. Why would we get this into ath9k first if the more appropriate way of doing this would be to modify mac80211 in the first place. I see no point in doing driver specific hacks for this unless there really is some driver specific issues that are being worked around and that does not seem to be the case here. As far as being able to disable 802.11n in general is concerned, it would much better to do that as a parameter for the connection (e.g., new nl80211 attribute for NL80211_CMD_ASSOCIATE) rather than a module parameter. This workaround seems to be needed with some APs and global disabling of 802.11n does not sound like the ideal mechanism for that. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
