> >> 2. And then if userspace sends a wiphy idx to the NL80211_CMD_GET_REG, >> we'll return wiphy->regd for that case as well? > > That's right, for now we'd be able to send the regd when either > NL80211_ATTR_WIPHY_SELF_MANAGED_REG is set or when > NL80211_ATTR_WIPHY_SELF_MANAGED_REG is not set but regulatory_hint() > was used. Note that some users may have REGULATORY_CUSTOM_REG. and > then later use regulatory_hint(), this is done to for example set a > more restrictive custom world regdomain and then later use the CRDA > data for a specific alpha2. Well always sending wiphy->regd whenever it is set is easy, but it might be problematic I guess: 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. 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
