Fix regulatory domain handling to reset bands properly
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): d2ef482bcf01fc515224cd508d730590a5294df2.1697719099.git.dberlin@dberlin.org
As an aside, the alternative would be to simply not ignore any attempts to set the regulatory domain, regardless of whether it's 00 or the chip is already set to that country.
It doesn't happen that often, so it's not clear it's worth avoiding it at all. There are some things i'd have to fix to make it work resiliently well (for example, i know we set the 2g bw cap where we do because it has to be done with the interface down), but i can fix those if needed.
Quoted 120 lines · Daniel Berlin
Currently, we ignore the default country in the reg notifier. We also register a custom regulatory domain, which is set as the default.
As a result, the chip is likely to be set to the correct country, but the regulatory domain will not match it.When the regulatory notifier is then called, we see the countries are the same and do not change anything, even though the domain is wrong.
This patch forces us to reset the bands on the first country change even if the chip is already set to that country.
We also restore the original band info before reconstructing channel info, as the new regdom power limits may be higher than what is currently set.
Signed-off-by Daniel Berlin <[email protected]>--- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 38 +++++++++++++++---- .../broadcom/brcm80211/brcmfmac/cfg80211.h | 2 + 2 files changed, 33 insertions(+), 7 deletions(-)drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +31
-7@@ -7199,11 +7199,23 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg, goto fail_pbuf; } +/* Changing regulatory domain may change channels and limits +* To ensure that we correctly set the new band info, copy the original +* info first. +*/ band = wiphy->bands[NL80211_BAND_2GHZ ]; -if (band) +if (band) { +memcpy (band->channels, &__wl_2ghz_channels, +sizeof (__wl_2ghz_channels)); + band->n_channels =ARRAY_SIZE (__wl_2ghz_channels);for (i =0 ; i < band->n_channels; i++) band->channels[i].flags =IEEE80211_CHAN_DISABLED ; + } band = wiphy->bands[NL80211_BAND_5GHZ ]; -if (band) +if (band) { +memcpy (band->channels, &__wl_5ghz_channels, +sizeof (__wl_5ghz_channels)); + band->n_channels =ARRAY_SIZE (__wl_5ghz_channels);for (i =0 ; i < band->n_channels; i++) band->channels[i].flags =IEEE80211_CHAN_DISABLED ; + }@@ -7210,8 +7222,11 @@ band = wiphy->bands[NL80211_BAND_6GHZ ]; -if (band) +if (band) { +memcpy (band->channels, &__wl_6ghz_channels, +sizeof (__wl_6ghz_channels)); + band->n_channels =ARRAY_SIZE (__wl_6ghz_channels);for (i =0 ; i < band->n_channels; i++) band->channels[i].flags =IEEE80211_CHAN_DISABLED ; - + } total =le32_to_cpu (list->count);if (total >BRCMF_MAX_CHANSPEC_LIST ) { bphy_err(drvr, "Invalid count of channel Spec. (%u)\n",@@ -8601,9 +8616,17 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy *wiphy, } err =brcmf_translate_country_code (ifp->drvr, req->alpha2, &ccreq); -if (err) -return ; - +if (err) { +/* Because we ignore the default country code above, +* we will start out in our custom reg domain, but the chip +* may already be set to the right country. +* As such, we force the bands to be re-set the first +* time we try to set a country for real. +*/ +if (err != -EAGAIN || !cfg->force_band_setup) +return ; + } + cfg->force_band_setup = false; err =brcmf_fil_iovar_data_set (ifp,"country" , &ccreq,sizeof (ccreq));if (err) {bphy_err (drvr,"Firmware rejected country setting\n" );@@ -8670,6 +8693,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr, cfg->pub = drvr;init_vif_event (&cfg->vif_event);INIT_LIST_HEAD (&cfg->vif_list); + cfg->force_band_setup = true; vif =brcmf_alloc_vif (cfg,NL80211_IFTYPE_STATION );if (IS_ERR (vif))drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h +2
-1@@ -327,6 +327,7 @@ struct brcmf_cfg80211_wowl {* @dongle_up: indicate whether dongle up or not. * @roam_on: on/off switch for dongle self-roaming. * @scan_tried: indicates if first scan attempted. +* @force_band_setup: indicates if we should force band setup * @dcmd_buf: dcmd buffer. * @extra_buf: mainly to grab assoc information. * @debugfsdir: debugfs folder for this device. @@ -357,6 +358,7 @@ struct brcmf_cfg80211_info {bool pwr_save;bool dongle_up;bool scan_tried; +bool force_band_setup;u8 *dcmd_buf;u8 *extra_buf;struct dentry *debugfsdir; --2.41.0
Quoted 7 lines · Daniel Berlin
As an aside, the alternative would be to simply not ignore any attempts to set the regulatory domain, regardless of whether it's 00 or the chip is already set to that country.
It doesn't happen that often, so it's not clear it's worth avoiding it at all. There are some things i'd have to fix to make it work resiliently well (for example, i know we set the 2g bw cap where we do because it has to be done with the interface down), but i can fix those if needed.
Please do not top post.
The firmware has its own regulatory information (actually the CLM blob holds that information) which is independent of the wireless regulatory database in the kernel. As such trying to configure country '00' will simply fail as it is not known inside CLM blob. The firmware needs a country abbreviation *and* a revision. Hence we require a mapping of country code to <abbrev,rev> tuple. If that mapping is not in place we bail out setting the country in the regulatory notifier.
From the description below it is not clear what problem is fixed here in terms of user experience.
Regards,
Arend
Quoted 24 lines · Daniel Berlin
Quoted 23 lines
Currently, we ignore the default country in the reg notifier. We also register a custom regulatory domain, which is set as the default.
As a result, the chip is likely to be set to the correct country, but the regulatory domain will not match it.When the regulatory notifier is then called, we see the countries are the same and do not change anything, even though the domain is wrong.
This patch forces us to reset the bands on the first country change even if the chip is already set to that country.
We also restore the original band info before reconstructing channel info, as the new regdom power limits may be higher than what is currently set.
Signed-off-by Daniel Berlin <[email protected]>--- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 38 +++++++++++++++---- .../broadcom/brcm80211/brcmfmac/cfg80211.h | 2 + 2 files changed, 33 insertions(+), 7 deletions(-)
Quoted 17 lines · Arend van Spriel
Quoted 7 lines · Daniel Berlin
As an aside, the alternative would be to simply not ignore any attempts to set the regulatory domain, regardless of whether it's 00 or the chip is already set to that country.
It doesn't happen that often, so it's not clear it's worth avoiding it at all. There are some things i'd have to fix to make it work resiliently well (for example, i know we set the 2g bw cap where we do because it has to be done with the interface down), but i can fix those if needed.Please do not top post.
The firmware has its own regulatory information (actually the CLM blob holds that information) which is independent of the wireless regulatory database in the kernel. As such trying to configure country '00' will simply fail as it is not known inside CLM blob.
Quoted 7 lines
The firmware needs a
country abbreviation *and* a revision. Hence we require a mapping of country code to <abbrev,rev> tuple. If that mapping is not in place we bail out setting the country in the regulatory notifier.From the description below it is not clear what problem is fixed here
in terms of user experience.
As far as the stack and kernel are concerned, it gets stuck in the custom regulatory domain ('99') and sets the max power levels, bandwidth caps, etc in the capabilities to match.
If you look at the phy info, it will clearly show you this. You are correct that the chip maintains its own view of power levels (though most drivers set them, we do not), but the bandwidth caps are respected, for example.
Note also that '00' is recognized by at least this firmware, though I agree it depends on whether/what is done in the CLM blob.
All that said, even if it changed nothing in the chip itself, it would still be displaying completely wrong info to the user.
I'm happy to update the description if that is your main concern.
Quoted 28 lines
Regards,
ArendQuoted 24 lines · Daniel Berlin
Quoted 23 lines
Currently, we ignore the default country in the reg notifier. We also register a custom regulatory domain, which is set as the default.
As a result, the chip is likely to be set to the correct country, but the regulatory domain will not match it.When the regulatory notifier is then called, we see the countries are the same and do not change anything, even though the domain is wrong.
This patch forces us to reset the bands on the first country change even if the chip is already set to that country.
We also restore the original band info before reconstructing channel info, as the new regdom power limits may be higher than what is currently set.
Signed-off-by Daniel Berlin <[email protected]>--- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 38 +++++++++++++++---- .../broadcom/brcm80211/brcmfmac/cfg80211.h | 2 + 2 files changed, 33 insertions(+), 7 deletions(-)