Message ID | 1341357315-8053-5-git-send-email-rodrigue@qca.qualcomm.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
Hi Luis, Please split this series -- I won't apply the Atheros driver patches :-) > + * @NL80211_ATTR_USER_REG_HINT_TYPE: type of regulatory hint passed from > + * userspace. If unset it is assumed the hint comes directly from > + * a user. If set code could specify exactly what type of source > + * was used to provide the hint. For the different types of > + * allowed user regulatory hints see nl80211_user_reg_hint_type. Please mention what the data type is, but see below > + * @NL80211_FEATURE_CELL_BASE_REG_HINTS: This driver has been tested > + * to work properly to suppport receiving regulatory hints from > + * cellular base stations. Typo "support", but I don't understand the reasoning behind this flag? First you hide away behind the certification Kconfig thing ...? Maybe you just need to explain better exactly what the cell-base-station regulatory hint does. > + [NL80211_ATTR_USER_REG_HINT_TYPE] = { .type = NLA_U8 }, Not much point in using a u8, I think you should just use a u32. > - r = regulatory_hint_user(data); > + if (info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE]) > + user_reg_hint_type = > + nla_get_u8(info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE]); Need to verify that it's a valid number, I think, otherwise you can pass random junk like 0x42 into the regulatory framework. > @@ -3869,6 +3877,11 @@ static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info) > cfg80211_regdomain->dfs_region))) > goto nla_put_failure; > > + if (reg_last_request_cell_base() && Is that really worthwhile as a function call like this rather than some sort of _get_hint_type()? > +#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS So I'm not really convinced about this. It seems this Kconfig should better be a Kconfig that enables other Kconfig only, not enabling other features. How else would anyone be able to do due diligence and check what exactly this enables that they need to test? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I've skipped the other comments as I can address those in a new series. On Wed, Jul 4, 2012 at 2:42 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > So I'm not really convinced about this. It seems this Kconfig should > better be a Kconfig that enables other Kconfig only, not enabling other > features. How else would anyone be able to do due diligence and check > what exactly this enables that they need to test? Makes sense, so would we then have CONFIG_REG_HINT_CELL_BASE_STATION ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2012-07-04 at 09:26 -0700, Luis R. Rodriguez wrote: > I've skipped the other comments as I can address those in a new series. > > On Wed, Jul 4, 2012 at 2:42 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > > So I'm not really convinced about this. It seems this Kconfig should > > better be a Kconfig that enables other Kconfig only, not enabling other > > features. How else would anyone be able to do due diligence and check > > what exactly this enables that they need to test? > > Makes sense, so would we then have CONFIG_REG_HINT_CELL_BASE_STATION ? I don't know how fine-grained it should be? Maybe it should be more generic and be a config for all (future) kinds of user hints? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 5, 2012 at 12:45 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Wed, 2012-07-04 at 09:26 -0700, Luis R. Rodriguez wrote: >> I've skipped the other comments as I can address those in a new series. >> >> On Wed, Jul 4, 2012 at 2:42 AM, Johannes Berg <johannes@sipsolutions.net> wrote: >> > So I'm not really convinced about this. It seems this Kconfig should >> > better be a Kconfig that enables other Kconfig only, not enabling other >> > features. How else would anyone be able to do due diligence and check >> > what exactly this enables that they need to test? >> >> Makes sense, so would we then have CONFIG_REG_HINT_CELL_BASE_STATION ? > > I don't know how fine-grained it should be? Maybe it should be more > generic and be a config for all (future) kinds of user hints? Well so in this case the cell base station hint support gets used and trusted on the wireless core if CONFIG_REG_HINT_CELL_BASE_STATION is set. Whether or not a *driver* trusts and uses it as well will depend on whether or not they set the NL80211_FEATURE_CELL_BASE_REG_HINTS feature on their wiphy->features. The way I was thinking about drivers going about enabling / disabling was to let the driver have its own kconfig option for this. The reason is that firmware may require some implementation / changes / testing to ensure that a device won't poop out if this is used. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-07-05 at 09:48 -0700, Luis R. Rodriguez wrote: > On Thu, Jul 5, 2012 at 12:45 AM, Johannes Berg > <johannes@sipsolutions.net> wrote: > > On Wed, 2012-07-04 at 09:26 -0700, Luis R. Rodriguez wrote: > >> I've skipped the other comments as I can address those in a new series. > >> > >> On Wed, Jul 4, 2012 at 2:42 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > >> > So I'm not really convinced about this. It seems this Kconfig should > >> > better be a Kconfig that enables other Kconfig only, not enabling other > >> > features. How else would anyone be able to do due diligence and check > >> > what exactly this enables that they need to test? > >> > >> Makes sense, so would we then have CONFIG_REG_HINT_CELL_BASE_STATION ? > > > > I don't know how fine-grained it should be? Maybe it should be more > > generic and be a config for all (future) kinds of user hints? > > Well so in this case the cell base station hint support gets used and > trusted on the wireless core if CONFIG_REG_HINT_CELL_BASE_STATION is > set. Whether or not a *driver* trusts and uses it as well will depend > on whether or not they set the NL80211_FEATURE_CELL_BASE_REG_HINTS > feature on their wiphy->features. The way I was thinking about drivers > going about enabling / disabling was to let the driver have its own > kconfig option for this. The reason is that firmware may require some > implementation / changes / testing to ensure that a device won't poop > out if this is used. Oh, that explains the extra flag there, I pretty much thought it was useless. I guess that could be useful for when you ship some device with builtin wireless but allow plugging in other wireless? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 5, 2012 at 11:39 PM, Johannes Berg <johannes@sipsolutions.net> wrote: > Oh, that explains the extra flag there, I pretty much thought it was > useless. I guess that could be useful for when you ship some device with > builtin wireless but allow plugging in other wireless? That, but also it means there are two hops for a device to use the cell base station hint: onus option, and then the feature flag, which could be wrapped itself around a driver specific kconfig option. Reason for the feature flag is devices may need a firmware update in order for them to work properly. As for the onus and the cell base station hint though, it is true though that the onus option would alone enable the core cell base station hints, so the onus option itself would be flipping a switch for a feature. I could extend the patch to include a core specific base station hint kconfig option, because as you say there is no specific switch to select the feature right now for the core. That would mean at most 3 options that would need to be enabled for the feature for a specific device. Thoughts ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2012-07-06 at 07:05 -0700, Luis R. Rodriguez wrote: > That, but also it means there are two hops for a device to use the > cell base station hint: onus option, and then the feature flag, which > could be wrapped itself around a driver specific kconfig option. > Reason for the feature flag is devices may need a firmware update in > order for them to work properly. > > As for the onus and the cell base station hint though, it is true > though that the onus option would alone enable the core cell base > station hints, so the onus option itself would be flipping a switch > for a feature. I could extend the patch to include a core specific > base station hint kconfig option, because as you say there is no > specific switch to select the feature right now for the core. I guess the question is -- what does that code really enable, if the driver doesn't also set the feature flag? If it doesn't mean anything without the flag I think we don't need the extra core option? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 6, 2012 at 7:11 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Fri, 2012-07-06 at 07:05 -0700, Luis R. Rodriguez wrote: > >> That, but also it means there are two hops for a device to use the >> cell base station hint: onus option, and then the feature flag, which >> could be wrapped itself around a driver specific kconfig option. >> Reason for the feature flag is devices may need a firmware update in >> order for them to work properly. >> >> As for the onus and the cell base station hint though, it is true >> though that the onus option would alone enable the core cell base >> station hints, so the onus option itself would be flipping a switch >> for a feature. I could extend the patch to include a core specific >> base station hint kconfig option, because as you say there is no >> specific switch to select the feature right now for the core. > > I guess the question is -- what does that code really enable, if the > driver doesn't also set the feature flag? If it doesn't mean anything > without the flag I think we don't need the extra core option? Ah -- good question. It'd just be the core. The core can support the base station hint or not but apart from the core we could technically also have a scenario today where perhaps one 802.11 card does support the station hint another does not. It is true that with no 802.11 card present having the core makes no sense but in practice we would, or at the very least we'd have the mac80211_hwsim. So as I designed this I realized we really did have to consider the core getting this Vs a card getting this hint. The core getting the hint would only happen as-is with the onus option enabled, so if we want the onus option only to be a gate to other options then technically the feature would be for the core, while drivers would have the options to enable / disable the same feature given that this requires testing / maybe some changes in the firmware. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2012-07-06 at 08:47 -0700, Luis R. Rodriguez wrote: > > I guess the question is -- what does that code really enable, if the > > driver doesn't also set the feature flag? If it doesn't mean anything > > without the flag I think we don't need the extra core option? > > Ah -- good question. It'd just be the core. The core can support the > base station hint or not but apart from the core we could technically > also have a scenario today where perhaps one 802.11 card does support > the station hint another does not. It is true that with no 802.11 card > present having the core makes no sense but in practice we would, or at > the very least we'd have the mac80211_hwsim. > > So as I designed this I realized we really did have to consider the > core getting this Vs a card getting this hint. The core getting the > hint would only happen as-is with the onus option enabled, so if we > want the onus option only to be a gate to other options then > technically the feature would be for the core, while drivers would > have the options to enable / disable the same feature given that this > requires testing / maybe some changes in the firmware. I'm not sure I really understand what you're saying :-) What I really wanted to know though is this: If the core code is enabled, what effect does receiving a "blessed" hint have on devices that don't set the flag? If there's no effect vs. an "unblessed" hint, then I think we don't need another option? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 6, 2012 at 8:51 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Fri, 2012-07-06 at 08:47 -0700, Luis R. Rodriguez wrote: > >> > I guess the question is -- what does that code really enable, if the >> > driver doesn't also set the feature flag? If it doesn't mean anything >> > without the flag I think we don't need the extra core option? >> >> Ah -- good question. It'd just be the core. The core can support the >> base station hint or not but apart from the core we could technically >> also have a scenario today where perhaps one 802.11 card does support >> the station hint another does not. It is true that with no 802.11 card >> present having the core makes no sense but in practice we would, or at >> the very least we'd have the mac80211_hwsim. >> >> So as I designed this I realized we really did have to consider the >> core getting this Vs a card getting this hint. The core getting the >> hint would only happen as-is with the onus option enabled, so if we >> want the onus option only to be a gate to other options then >> technically the feature would be for the core, while drivers would >> have the options to enable / disable the same feature given that this >> requires testing / maybe some changes in the firmware. > > I'm not sure I really understand what you're saying :-) > > What I really wanted to know though is this: If the core code is > enabled, what effect does receiving a "blessed" hint have on devices > that don't set the flag? If there's no effect vs. an "unblessed" hint, > then I think we don't need another option? Ah, OK so yes, as it is right now if the core accepts the hint but devices do not listen to it we do have an effect right now which I alluded to in my cover letter: country IE hints won't be listened to after a base station hint gets accepted. Whether or not we want to process country IE hints *after* a cell base station hint gets accepted is debatable -- I decided that its easier to implement to ignore country IE hints after a cell base station hint and I also decided cell base station hints are likely something you'd prefer to review over country IE hints. We can certainly change this and I'm open to it. So yes, as it is right now if you enable onus but your device does not support he feature you may detect a regression: country IE hints would not be processed if you did receive a base station hint that the core processed. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2012-07-06 at 09:07 -0700, Luis R. Rodriguez wrote: > > What I really wanted to know though is this: If the core code is > > enabled, what effect does receiving a "blessed" hint have on devices > > that don't set the flag? If there's no effect vs. an "unblessed" hint, > > then I think we don't need another option? > > Ah, OK so yes, as it is right now if the core accepts the hint but > devices do not listen to it we do have an effect right now which I > alluded to in my cover letter: country IE hints won't be listened to > after a base station hint gets accepted. Whether or not we want to > process country IE hints *after* a cell base station hint gets > accepted is debatable -- I decided that its easier to implement to > ignore country IE hints after a cell base station hint and I also > decided cell base station hints are likely something you'd prefer to > review over country IE hints. We can certainly change this and I'm > open to it. > > So yes, as it is right now if you enable onus but your device does not > support he feature you may detect a regression: country IE hints would > not be processed if you did receive a base station hint that the core > processed. It seems this might be a problem, in the case that I mentioned before: you do take all the necessary steps to enable this, but then somebody plugs in a USB device (say this is a tablet-like device?) It seems it would be better to make the base station/country IE hint also depend on the feature flag? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 6, 2012 at 9:15 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Fri, 2012-07-06 at 09:07 -0700, Luis R. Rodriguez wrote: > >> > What I really wanted to know though is this: If the core code is >> > enabled, what effect does receiving a "blessed" hint have on devices >> > that don't set the flag? If there's no effect vs. an "unblessed" hint, >> > then I think we don't need another option? >> >> Ah, OK so yes, as it is right now if the core accepts the hint but >> devices do not listen to it we do have an effect right now which I >> alluded to in my cover letter: country IE hints won't be listened to >> after a base station hint gets accepted. Whether or not we want to >> process country IE hints *after* a cell base station hint gets >> accepted is debatable -- I decided that its easier to implement to >> ignore country IE hints after a cell base station hint and I also >> decided cell base station hints are likely something you'd prefer to >> review over country IE hints. We can certainly change this and I'm >> open to it. >> >> So yes, as it is right now if you enable onus but your device does not >> support he feature you may detect a regression: country IE hints would >> not be processed if you did receive a base station hint that the core >> processed. > > It seems this might be a problem, in the case that I mentioned before: > you do take all the necessary steps to enable this, but then somebody > plugs in a USB device (say this is a tablet-like device?) Agreed however see below. > It seems it would be better to make the base station/country IE hint > also depend on the feature flag? Agreed, at first I figured this'd be complex to figure out dynamically but it does not have to be: upon wiphy registration we could detect if a device has the feature enabled and peg core_base_hint_enabled++ or whatever and then allow them through. Upon deregistration we'd core_base_hint_enabled-- and only enable the feature if its > 0. Seems doable. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 6, 2012 at 9:31 AM, Luis R. Rodriguez <rodrigue@qca.qualcomm.com> wrote: > upon wiphy registration we could detect if > a device has the feature enabled and peg core_base_hint_enabled++ or > whatever and then allow them through. Upon deregistration we'd > core_base_hint_enabled-- and only enable the feature if its > 0. > > Seems doable. Yeah.. I like this -- it means we wouldn't have to add a kconfig for the feature, instead each driver could define a kconfig of its own for it. I'll respin, thanks! Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h index 74cc55c..2235533 100644 --- a/include/linux/nl80211.h +++ b/include/linux/nl80211.h @@ -1242,6 +1242,12 @@ enum nl80211_commands { * @NL80211_ATTR_BG_SCAN_PERIOD: Background scan period in seconds * or 0 to disable background scan. * + * @NL80211_ATTR_USER_REG_HINT_TYPE: type of regulatory hint passed from + * userspace. If unset it is assumed the hint comes directly from + * a user. If set code could specify exactly what type of source + * was used to provide the hint. For the different types of + * allowed user regulatory hints see nl80211_user_reg_hint_type. + * * @NL80211_ATTR_MAX: highest attribute number currently defined * @__NL80211_ATTR_AFTER_LAST: internal use */ @@ -1493,6 +1499,8 @@ enum nl80211_attrs { NL80211_ATTR_BG_SCAN_PERIOD, + NL80211_ATTR_USER_REG_HINT_TYPE, + /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, @@ -2045,6 +2053,22 @@ enum nl80211_dfs_regions { }; /** + * enum nl80211_user_reg_hint_type - type of user regulatory hint + * + * @NL80211_USER_REG_HINT_USER: a user sent the hint. This is always + * assumed if the attribute is not set. + * @NL80211_USER_REG_HINT_CELL_BASE: the hint comes from a cellular + * base station. Device drivers that have been tested to work + * properly to support this type of hint can enable these hints + * by setting the NL80211_FEATURE_CELL_BASE_REG_HINTS feature + * capability on the struct wiphy. + */ +enum nl80211_user_reg_hint_type { + NL80211_USER_REG_HINT_USER = 0, + NL80211_USER_REG_HINT_CELL_BASE = 1, +}; + +/** * enum nl80211_survey_info - survey information * * These attribute types are used with %NL80211_ATTR_SURVEY_INFO @@ -2933,11 +2957,15 @@ enum nl80211_ap_sme_features { * @NL80211_FEATURE_HT_IBSS: This driver supports IBSS with HT datarates. * @NL80211_FEATURE_INACTIVITY_TIMER: This driver takes care of freeing up * the connected inactive stations in AP mode. + * @NL80211_FEATURE_CELL_BASE_REG_HINTS: This driver has been tested + * to work properly to suppport receiving regulatory hints from + * cellular base stations. */ enum nl80211_feature_flags { NL80211_FEATURE_SK_TX_STATUS = 1 << 0, NL80211_FEATURE_HT_IBSS = 1 << 1, NL80211_FEATURE_INACTIVITY_TIMER = 1 << 2, + NL80211_FEATURE_CELL_BASE_REG_HINTS = 1 << 3, }; /** diff --git a/include/net/regulatory.h b/include/net/regulatory.h index a5f7993..61c394a 100644 --- a/include/net/regulatory.h +++ b/include/net/regulatory.h @@ -52,6 +52,9 @@ enum environment_cap { * DFS master operation on a known DFS region (NL80211_DFS_*), * dfs_region represents that region. Drivers can use this and the * @alpha2 to adjust their device's DFS parameters as required. + * @user_reg_hint_type: if the @initiator was of type + * %NL80211_REGDOM_SET_BY_USER, this clasifies the type + * of hint passed. This could be any of the %NL80211_USER_REG_HINT_* * @intersect: indicates whether the wireless core should intersect * the requested regulatory domain with the presently set regulatory * domain. @@ -70,6 +73,7 @@ enum environment_cap { struct regulatory_request { int wiphy_idx; enum nl80211_reg_initiator initiator; + enum nl80211_user_reg_hint_type user_reg_hint_type; char alpha2[2]; u8 dfs_region; bool intersect; diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 77102e6..037cc57a 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -294,6 +294,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = { [NL80211_ATTR_NOACK_MAP] = { .type = NLA_U16 }, [NL80211_ATTR_INACTIVITY_TIMEOUT] = { .type = NLA_U16 }, [NL80211_ATTR_BG_SCAN_PERIOD] = { .type = NLA_U16 }, + [NL80211_ATTR_USER_REG_HINT_TYPE] = { .type = NLA_U8 }, }; /* policy for the key attributes */ @@ -3480,6 +3481,7 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info) { int r; char *data = NULL; + enum nl80211_user_reg_hint_type user_reg_hint_type; /* * You should only get this when cfg80211 hasn't yet initialized @@ -3499,7 +3501,13 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info) data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]); - r = regulatory_hint_user(data); + if (info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE]) + user_reg_hint_type = + nla_get_u8(info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE]); + else + user_reg_hint_type = NL80211_USER_REG_HINT_USER; + + r = regulatory_hint_user(data, user_reg_hint_type); return r; } @@ -3869,6 +3877,11 @@ static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info) cfg80211_regdomain->dfs_region))) goto nla_put_failure; + if (reg_last_request_cell_base() && + nla_put_u8(msg, NL80211_ATTR_USER_REG_HINT_TYPE, + NL80211_USER_REG_HINT_CELL_BASE)) + goto nla_put_failure; + nl_reg_rules = nla_nest_start(msg, NL80211_ATTR_REG_RULES); if (!nl_reg_rules) goto nla_put_failure; diff --git a/net/wireless/reg.c b/net/wireless/reg.c index b2b3222..3644159 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -911,6 +911,56 @@ static void handle_band(struct wiphy *wiphy, handle_channel(wiphy, initiator, band, i); } +static bool reg_request_cell_base(struct regulatory_request *request) +{ + if (request->initiator != NL80211_REGDOM_SET_BY_USER) + return false; + if (request->user_reg_hint_type != NL80211_USER_REG_HINT_CELL_BASE) + return false; + return true; +} + +bool reg_last_request_cell_base(void) +{ + assert_cfg80211_lock(); + + mutex_lock(®_mutex); + return reg_request_cell_base(last_request); + mutex_unlock(®_mutex); +} + +#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS + +/* Core specific check */ +static int reg_ignore_cell_hint(struct regulatory_request *pending_request) +{ + if (reg_request_cell_base(last_request)) { + if (!regdom_changes(pending_request->alpha2)) + return -EALREADY; + return 0; + } + return 0; +} + +/* Device specific check */ +static bool reg_dev_ignore_cell_hint(struct wiphy *wiphy) +{ + if (!(wiphy->features & NL80211_FEATURE_CELL_BASE_REG_HINTS)) + return true; + return false; +} +#else +static int reg_ignore_cell_hint(struct regulatory_request *pending_request) +{ + return -EOPNOTSUPP; +} +static int reg_dev_ignore_cell_hint(struct wiphy *wiphy) +{ + return true; +} +#endif + + static bool ignore_reg_update(struct wiphy *wiphy, enum nl80211_reg_initiator initiator) { @@ -944,6 +994,9 @@ static bool ignore_reg_update(struct wiphy *wiphy, return true; } + if (reg_request_cell_base(last_request)) + return reg_dev_ignore_cell_hint(wiphy); + return false; } @@ -1307,6 +1360,13 @@ static int ignore_request(struct wiphy *wiphy, return 0; case NL80211_REGDOM_SET_BY_COUNTRY_IE: + if (reg_request_cell_base(last_request)) { + /* Trust a Cell base station over the AP's country IE */ + if (regdom_changes(pending_request->alpha2)) + return -EOPNOTSUPP; + return -EALREADY; + } + last_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx); if (unlikely(!is_an_alpha2(pending_request->alpha2))) @@ -1351,6 +1411,12 @@ static int ignore_request(struct wiphy *wiphy, return REG_INTERSECT; case NL80211_REGDOM_SET_BY_USER: + if (reg_request_cell_base(pending_request)) + return reg_ignore_cell_hint(pending_request); + + if (reg_request_cell_base(last_request)) + return -EOPNOTSUPP; + if (last_request->initiator == NL80211_REGDOM_SET_BY_COUNTRY_IE) return REG_INTERSECT; /* @@ -1640,7 +1706,8 @@ static int regulatory_hint_core(const char *alpha2) } /* User hints */ -int regulatory_hint_user(const char *alpha2) +int regulatory_hint_user(const char *alpha2, + enum nl80211_user_reg_hint_type user_reg_hint_type) { struct regulatory_request *request; @@ -1654,6 +1721,7 @@ int regulatory_hint_user(const char *alpha2) request->alpha2[0] = alpha2[0]; request->alpha2[1] = alpha2[1]; request->initiator = NL80211_REGDOM_SET_BY_USER; + request->user_reg_hint_type = user_reg_hint_type; queue_regulatory_request(request); @@ -1906,7 +1974,7 @@ static void restore_regulatory_settings(bool reset_user) * settings, user regulatory settings takes precedence. */ if (is_an_alpha2(alpha2)) - regulatory_hint_user(user_alpha2); + regulatory_hint_user(user_alpha2, NL80211_USER_REG_HINT_USER); if (list_empty(&tmp_reg_req_list)) return; @@ -2081,9 +2149,16 @@ static void print_regdomain(const struct ieee80211_regdomain *rd) else { if (is_unknown_alpha2(rd->alpha2)) pr_info("Regulatory domain changed to driver built-in settings (unknown country)\n"); - else - pr_info("Regulatory domain changed to country: %c%c\n", - rd->alpha2[0], rd->alpha2[1]); + else { + if (reg_request_cell_base(last_request)) + pr_info("Regulatory domain changed " + "to country: %c%c by Cell Station\n", + rd->alpha2[0], rd->alpha2[1]); + else + pr_info("Regulatory domain changed " + "to country: %c%c\n", + rd->alpha2[0], rd->alpha2[1]); + } } print_dfs_region(rd->dfs_region); print_rd_rules(rd); @@ -2364,7 +2439,8 @@ int __init regulatory_init(void) * as a user hint. */ if (!is_world_regdom(ieee80211_regdom)) - regulatory_hint_user(ieee80211_regdom); + regulatory_hint_user(ieee80211_regdom, + NL80211_USER_REG_HINT_USER); return 0; } diff --git a/net/wireless/reg.h b/net/wireless/reg.h index e2aaaf5..ba1097e 100644 --- a/net/wireless/reg.h +++ b/net/wireless/reg.h @@ -22,7 +22,8 @@ bool is_world_regdom(const char *alpha2); bool reg_is_valid_request(const char *alpha2); bool reg_supported_dfs_region(u8 dfs_region); -int regulatory_hint_user(const char *alpha2); +int regulatory_hint_user(const char *alpha2, + enum nl80211_user_reg_hint_type user_reg_hint_type); int reg_device_uevent(struct device *dev, struct kobj_uevent_env *env); void reg_device_remove(struct wiphy *wiphy); @@ -33,6 +34,7 @@ void regulatory_exit(void); int set_regdom(const struct ieee80211_regdomain *rd); void regulatory_update(struct wiphy *wiphy, enum nl80211_reg_initiator setby); +bool reg_last_request_cell_base(void); /** * regulatory_hint_found_beacon - hints a beacon was found on a channel