On Wed, Jun 11, 2014 at 1:45 AM, Arik Nemtsov <arik@xxxxxxxxxx> wrote: > On Wed, Jun 11, 2014 at 10:33 AM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >> On 11-06-14 08:55, Arik Nemtsov wrote: >>> >>> Define a new wiphy callback allowing drivers to provide regulatory >>> settings. >>> >>> Only The first wiphy registered with this callback will be able to provide >>> regulatory domain info. If such a wiphy exists, it takes precedence over >>> other data sources. >> >> >> I should probably dig through linux-wireless archive for background info, >> but how is this different from the wiphy_apply_custom_regulatory() call. Is >> this for devices that have a regulatory database of sorts in the device >> firmware? >> > Yea that's basically it. And we want the get the info dynamically from > FW upon country changes. Currently a few drivers exist that have regulatory data in firmware and what we end up doing is allowing that through the usage of the custom flag and then having the reg_notififer() poke firmware and and ensure its OK with all the changes. It however has no way to then splat data from firmware onto the wiphy dynamically, and although this could be done through the custom firmware thing that is only for initialization and before registration. Having the API explicit should also allow us to extract vendor's regulatory data and then do our own serialized analysis of regulatory data to populate the public regdb. Using the firmware regulatory data is an architecture that is plain stupid and non-scalable so if people want to shoot themsevles on the foot with that stupidity I think its fine to let it through so long as we can extract their regulatory data, which this helps accomplish. Let the best firmware design win. 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
