On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote: > Sure -- we can have on the ieee80211_conf struct an array of all > regulatory domains stack values that the device supports > (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees > the device has been certified to match the regulatory domain > restrictions as the stack defines it. I believe most modern devices > adhere to the PtMP restrictions pretty loosely and the magic is left > to the driver when the device is being certified so ultimately I see > devices sharing regulatory domains restrictions rather than defining > their own though. I'd consider defining your own device-specific > regulatory domain would be more of an exception we'd have to deal with > but that remains to be seen yet huh.
It sounds overcomplicated to me. I'd rather like to see something like this: 1. As part of the initialization of the hardware, the driver detects that the device is certified for (say) channels 2 to 10 (that's not a real-life example, fortunately :-)). 2. The driver reports this somewhere (softmac drivers would report this to the stack). 3. Based on outside conditions (userspace - or something - tells us about actual regdomain), the stack (or whatever) calls the driver and passes allowed channels etc. to it (if the driver wants that information). There is already previously reported driver's limitation taken in the account in that information. 4. If the outside conditions change (802.11d or user emigrates or something) that callback is called again with a new data. I.e.: - I see no point in building a list of regdomains suported by the hardware. - It's pretty common that the device has some limitation stated in the EPROM and the stack/something should deal with it in a way that is easy to use in a driver. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
