On 9/22/07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > So in the first part I covered how information on channel restrictions > is communicated between the central regulatory control agent and drivers > and/or mac80211. > > This second part is rather short, but important. > > Devices that are capable of operating in a wide range of regulatory > restrictions usually also have country information encoded in their > EEPROM. I understand that Intel devices will need to make this EEPROM > information part of their channels list because the firmware rejects > tuning to other channels, but most devices fully enforce these > restrictions in software. > > Hence, it is necessary that drivers are able to set the regulatory > domain they think they are operating in. It would probably be possible > to override by the user, but when the user has just booted it would be > good to be able to read the EEPROM of a wireless card to set the initial > operating domain. > > For this, we need two exported functions: > > void cfg80211_regulatory_set_alpha2(const char *alpha2); > void cfg80211_regulatory_set_domain(int ieee80211_domain); > > These functions, when called, internally look up the value and, if > found, update each registered wiphy's channels list for the new > restrictions. They also set the internal domain to the value given > (well, I suppose the _set_domain function internally looks up an alpha2 > value and calls the other one). Also, it will call the notifier chain I > talked about earlier so drivers can be notified of the change if > necessary. > > Similarly, userspace can set the alpha2 value through some > nl80211/configfs API which will also cause the the same updates and > notifier chain calls. > > I think this covers all the public API to regulatory control. Did I miss > anything? Everything else should be internal. That's the plan ;) For now I only have support to change regdomain through configfs though, I have to add support for the driver changing the regdomain though, which I think should just consists of a loop over al wiphys and updating their channel/power info. The rare exception we'd have to deal with is when the user is on a channel already which is going to be disabled but like we spoke about this -- we can just disable it, I still think we should notify the user but whatever, this is a pretty rare thing to deal with, we'll figure it out. Luis - 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
