On Mon, Jun 23, 2014 at 11:48 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx> wrote: > On Mon, Jun 23, 2014 at 09:34:13PM +0300, Arik Nemtsov wrote: >> On Mon, Jun 23, 2014 at 9:26 PM, Luis R. Rodriguez >> <mcgrof@xxxxxxxxxxxxxxxx> wrote: >> > On Mon, Jun 23, 2014 at 08:14:43PM +0300, Arik Nemtsov wrote: >> >> On Thu, Jun 19, 2014 at 2:34 AM, Luis R. Rodriguez >> >> <mcgrof@xxxxxxxxxxxxxxxx> wrote: >> >> > On Tue, Jun 10, 2014 at 11:55 PM, Arik Nemtsov <arik@xxxxxxxxxx> wrote: >> >> >> Allow driver and user hints to set the "world" regulatory domain, >> >> > >> >> > NACK - as expressed in the other patch, letting the drivers to use the >> >> > new API to set the world regulatory domain doesn't make sense as we >> >> > have custom apply stuff, and the world regulatory domain is not >> >> > something dynamic. >> >> >> >> Well we want to set the world regdomain from FW. This obviously >> >> happens after wiphy registration, so I don't think the custom apply >> >> can be used here? (since we generally want cfg80211 to own the >> >> regdomain settings). >> > >> > Can the driver not obtain the world regulatory domain from firmware >> > prior to wiphy registration? Why not? >> >> Since the FW is not running yet :) > > Is that a limitation that can be corrected on the driver ? Can the wiphy > registration be moved to after wiphy firmware is loaded ? If this is too > hard I see this as a good reason to extend the API or add a new similar > call that would allow for this case. The reason for the restriction on wiphy > registration was due to the fact that we didn't want to mess with _orig > parameters after wiphy registration, and we didn't want drivers poking > with those. The _orig parameters then can be set by cfg80211 through two > ways, one is the driver say reads EEPROM stuff and sets the channel > structs with the restrictions it had prior to wiphy registration or if > drivers could deduce a regulatory domain structure they could use the > wiphy_apply_custom_regulatory() which would do the same for them. > > Note that what this does is let drivers fill a set of channel data > structures and then with these mechanisms set the max allowed superset. > Anything after this is a subset of the original set of allowed > parameters. Please review handle_channel(). > > The difficulty in allowing changing the _orig stuff after wiphy > registration is we'd then have to ensure that the current state > of the regulatory machine is replicated on the device driver. Just > consider doing this properly and I think we'll be good. We can't access the FW before wiphy registration. In some scenarios the module is loaded during system boot, before we can really access the HW bus. We only start the FW on the first ifup. To allow ifup, we need the wiphy registered. We have no "hook" where we can register the wiphy after the wifi HW bus if fully available. Nor do we want to find this hook, because of multiple platforms etc. But I'm not sure why you're mentioning the workings of handle_channel() for this patch. It doesn't allow changing the original flags set at registration. It just allows drivers and the user to assign the world regdomain, and also to change the native "00" definitions with the FW regdomain. It shouldn't harm anything AFAICT. > >> > One thing to be careful on all this new API design is to ensure that >> > upon disconnect we want the driver to go back to the original state, >> > whatever that is. >> >> This particular part is unrelated to connection state AFAICT. It just >> allows someone (driver, user) to set the "00" regdomain. > > There are two things here, one is the custom world regulatory domain > that firmware is setting, the other is the new API to allow an alpha2 > regulatory domain. The resetting of regulatory domains needs to ensure > that if the first regulatory domain was a world regulatory domain, and > then a driver alpha2 is set these regulatory domains will be applied in > the same order when it disconnects. If the APIs are used properly this > is guaranteed already for us and its one reason for seeing if we can > just use existing APIs. See restore_custom_reg_settings() as an example. I believe there's no issue introduced by this code. Arik -- 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
