On Sun, 2014-11-16 at 13:06 +0200, Arik Nemtsov wrote: > We intend to add a patch to wpa_s to always add the wiphy_idx to > NL80211_CMD_GET_REG. With the current approach only drivers with > SELF_MANAGED_REG will get wiphy->regd back. This is ok since these are > new drivers, which are familiar with this API. > > But if we use your suggestion and always return wiphy->regd, then some > driver like ath9k that uses regulatory_hint() will now get it's > private regd returned to the wpa_s that manages it. I'm not saying > it's necessarily bad, but it's different than what was returned > before. The cfg80211 regdomain is intersected with wiphy->regd, so now > ath9k will start getting more permissive channels in usermode. > > So we thought it's best to enable the new behavior only if the driver > explicitly wants it, using a new regulatory flag. How does this work the other way around - i.e. a newer wpa_s requesting per-wiphy information but it not being present? It seems to me that either way what the kernel should return is the information that will actually be applied when validated, which is of course not possible when there are wiphy-specific regdomains and a global one is requested (unless there's just one wiphy, which might be something to consider making work?) I also don't actually see a driver regulatory flag in this patch, as expected, so not sure what exactly you're talking about above? johannes -- 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
