The REGULATORY_CUSTOM_REG can be used during early init with
the goal of overriding the wiphy's default regulatory settings
in case the alpha2 of the device is not known. In the case that
the alpha2 becomes known lets avoid having drivers having to
clear the REGULATORY_CUSTOM_REG flag by doing it for them
when regulatory_hint() is used.
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
}
wiphy_apply_custom_regulatory(wiphy, regd);
- if (!ath_is_world_regd(reg))
- wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
ath_reg_apply_radar_flags(wiphy);
ath_reg_apply_world_flags(wiphy, NL80211_REGDOM_SET_BY_DRIVER, reg);
return 0;
* initiator is %REGDOM_SET_BY_CORE). Drivers that use
* wiphy_apply_custom_regulatory() should have this flag set
* or the regulatory core will set it for the wiphy.
+ * If you use regulatory_hint() *after* using
+ * wiphy_apply_custom_regulatory() the wireless core will
+ * clear the REGULATORY_CUSTOM_REG for your wiphy as it would be
+ * implied that the device somehow gained knowledge of its region.
* @REGULATORY_STRICT_REG: tells us that the wiphy for this device
* has regulatory domain that it wishes to be considered as the
* superset for regulatory rules. After this device gets its regulatory
if (WARN_ON(!alpha2 || !wiphy))
return -EINVAL;
+ wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
+
request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;