> I'm not so sure about this. This patching might be US-specific and we > cannot simply apply the setting for top channel of another domain > instead of channel 11. One option would be to set the value only under > the US regulatory domain. ?? What the patch does is replace the top channel which is hardcoded to 11 by the top channel given by the current regulatory domain. How can that be wrong? Except that you may want to init the regulatory domain from the EEPROM but I'm not sure how the ieee80211 code works wrt. that. johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- From: "Holden Karau" <[email protected]>
- Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- From: Daniel Drake <[email protected]>
- Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- From: "Holden Karau" <[email protected]>
- Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- From: Daniel Drake <[email protected]>
- Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- From: Uli Kunitz <[email protected]>
- [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- Prev by Date: Re: [PATCH] lockdep: annotate DECLARE_WAIT_QUEUE_HEAD
- Next by Date: Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support
- Previous by thread: Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- Next by thread: Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
- Index(es):