From: Brian Norris <briannorris@chromium.org>
To: yhchuang@realtek.com
Cc: kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
tehuang@realtek.com
Subject: Re: [PATCH v5 1/2] rtw88: add regulatory process strategy for different chipset
Date: Fri, 20 Mar 2020 17:16:45 -0700 [thread overview]
Message-ID: <20200321001645.GA16851@google.com> (raw)
In-Reply-To: <20200313034918.22222-2-yhchuang@realtek.com>
Hi,
On Fri, Mar 13, 2020 at 11:49:17AM +0800, yhchuang@realtek.com wrote:
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index 2f73820cd9ba..635d9964beaa 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1510,8 +1510,10 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
> return ret;
> }
>
> - if (regulatory_hint(hw->wiphy, rtwdev->regd.alpha2))
> - rtw_err(rtwdev, "regulatory_hint fail\n");
> + if (!rtwdev->efuse.country_worldwide) {
> + if (regulatory_hint(hw->wiphy, rtwdev->efuse.country_code))
> + rtw_err(rtwdev, "regulatory_hint fail\n");
Might as well log the error code, whlie you're at it?
> + }
>
> rtw_debugfs_init(rtwdev);
>
> diff --git a/drivers/net/wireless/realtek/rtw88/regd.c b/drivers/net/wireless/realtek/rtw88/regd.c
> index 69744dd65968..500a02b97a9c 100644
> --- a/drivers/net/wireless/realtek/rtw88/regd.c
> +++ b/drivers/net/wireless/realtek/rtw88/regd.c
> @@ -7,6 +7,18 @@
> #include "debug.h"
> #include "phy.h"
>
> +static const struct ieee80211_regdomain rtw88_world_regdom = {
> + .n_reg_rules = 5,
> + .alpha2 = "99",
> + .reg_rules = {
> + REG_RULE(2412 - 10, 2462 + 10, 40, 0, 20, 0),
> + REG_RULE(2467 - 10, 2484 + 10, 40, 0, 20, NL80211_RRF_NO_IR),
> + REG_RULE(5180 - 10, 5240 + 10, 80, 0, 20, NL80211_RRF_NO_IR),
> + REG_RULE(5260 - 10, 5700 + 10, 80, 0, 20,
> + NL80211_RRF_NO_IR | NL80211_RRF_DFS),
> + REG_RULE(5745 - 10, 5825 + 10, 80, 0, 20, NL80211_RRF_NO_IR),
> + }
> +};
These rules look substantially identical to the default world rules
specified in the standard regdb, except for the fact that you're missing
the NO-ODFM part of this band:
# Channel 14. Only JP enables this and for 802.11b only
(2474 - 2494 @ 20), (20), NO-IR, NO-OFDM
So, why do you need to specify a custom one?
...
> static int rtw_regd_notifier_apply(struct rtw_dev *rtwdev,
> struct wiphy *wiphy,
> struct regulatory_request *request)
> {
> - if (request->initiator == NL80211_REGDOM_SET_BY_USER)
> + if (request->initiator == NL80211_REGDOM_SET_BY_DRIVER)
> + return -EINVAL;
> + if (request->initiator == NL80211_REGDOM_SET_BY_USER &&
> + !IS_ENABLED(CONFIG_RTW88_REGD_USER_REG_HINTS))
> + return -EINVAL;
> + if (request->initiator == NL80211_REGDOM_SET_BY_COUNTRY_IE &&
> + !rtw_regd_is_ww(&rtwdev->regd))
> + return -EINVAL;
> + if (request->initiator == NL80211_REGDOM_SET_BY_CORE &&
> + !rtwdev->efuse.country_worldwide) {
> + rtwdev->regd =
> + rtw_regd_find_reg_by_name(rtwdev->efuse.country_code);
> return 0;
> + }
None of these errors actually go anywhere; if you were planning to
ignore these, shouldn't they be surfaced somewhere? Or can't these be
encoded in your regulatory policy instead? Like
REGULATORY_COUNTRY_IE_IGNORE, for one.
And as with your WOWLAN implementation: if there's no way to surface
errors, you should at least log something.
Brian
> rtwdev->regd = rtw_regd_find_reg_by_name(request->alpha2);
> rtw_regd_apply_world_flags(wiphy, request->initiator);
>
next prev parent reply other threads:[~2020-03-21 0:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 3:49 [PATCH v5 0/2] rtw88: update regulatory settings yhchuang
2020-03-13 3:49 ` [PATCH v5 1/2] rtw88: add regulatory process strategy for different chipset yhchuang
2020-03-21 0:16 ` Brian Norris [this message]
2020-03-23 8:41 ` Andy Huang
2020-03-13 3:49 ` [PATCH v5 2/2] rtw88: add adaptivity support for EU/JP regulatory yhchuang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200321001645.GA16851@google.com \
--to=briannorris@chromium.org \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=tehuang@realtek.com \
--cc=yhchuang@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).