From: "Mingyen Hsieh (謝明諺)" <Mingyen.Hsieh@mediatek.com>
To: "nbd@nbd.name" <nbd@nbd.name>,
"nico.escande@gmail.com" <nico.escande@gmail.com>,
"lorenzo@kernel.org" <lorenzo@kernel.org>
Cc: "linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"Leon Yen (顏良儒)" <Leon.Yen@mediatek.com>,
"Deren Wu (武德仁)" <Deren.Wu@mediatek.com>,
"Shayne Chen (陳軒丞)" <Shayne.Chen@mediatek.com>,
"Quan Zhou (周全)" <Quan.Zhou@mediatek.com>,
"KM Lin (林昆民)" <km.lin@mediatek.com>,
"Sean Wang" <Sean.Wang@mediatek.com>,
"Soul Huang (黃至昶)" <Soul.Huang@mediatek.com>,
"Posh Sun (孫瑞廷)" <posh.sun@mediatek.com>,
"Eric-SY Chang (張書源)" <Eric-SY.Chang@mediatek.com>,
"CH Yeh (葉志豪)" <ch.yeh@mediatek.com>,
"Robin Chiu (邱國濱)" <robin.chiu@mediatek.com>,
"Ryder Lee" <Ryder.Lee@mediatek.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] wifi: mt76: mt7921: avoid undesired changes of the preset regulatory domain
Date: Mon, 22 Apr 2024 06:32:11 +0000 [thread overview]
Message-ID: <98f3d7bcbf235c70190f28ec6371244c047b6df3.camel@mediatek.com> (raw)
In-Reply-To: <D0KMHQSFOY0B.3P66MD08H96FZ@gmail.com>
On Mon, 2024-04-15 at 12:26 +0200, Nicolas Escande wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On Mon Apr 15, 2024 at 7:53 AM CEST, Mingyen Hsieh (謝明諺) wrote:
> > On Fri, 2024-04-12 at 11:27 +0200, Nicolas Escande wrote:
> > >
> > > External email : Please do not click links or open attachments
> until
> > > you have verified the sender or the content.
> > > On Fri Apr 12, 2024 at 10:53 AM CEST, Mingyen Hsieh wrote:
> > > > From: Leon Yen <leon.yen@mediatek.com>
> > > >
> > > > Some countries have strict RF restrictions where changing the
> > > regulatory
> > > > domain dynamically based on the connected AP is not acceptable.
> > > > This patch disables Beacon country IE hinting when a valid
> country
> > > code
> > > > is set from usersland (e.g., by system using iw or CRDA).
> > >
> > > I always had trouble fully understanding the regulation but isn't
> the
> > > country
> > > code IE sole purpose to adapt the regulatory of the client ?
> > >
> > Hi Nicolas,
> >
> > Yes, it is. However, if the users have set the specific country
> code
> > based on their region to the driver, they do not expect the country
> > setting to be changed by the country code IE as the AP cannot be
> > entirely trusted.
>
> Hi,
>
> In AP mode, I understand that the hardware/firmware (and so user mode
> to some
> extend) is the source of truth about which country/market the product
> has passed
> certification and what not. Thus the country code of an AP should be
> trusted.
> If you put an AP from another market at some place, you are
> responsible for that
>
> But in STA mode the end user should not need to know which regulation
> follow,
> right ? The AP's Country code IE is where the sta gets the final
> info. So no,
> the AP should be trusted, and the user should not (and not the other
> way around)
>
> Of course, I am no an expert on this. I just want to check if there
> was some
> though behind this change. You guys make Wifi chips, you know what
> you are doing
>
> Thanks
Hi,
Sorry for late response. Firstly, the "users" for driver doesn't mean
end users here; instead, it means the freamework of a Linux based
operation system that set the country code via nl80211. Some devices
shipped with a preset country code setting and set it to the driver
during boot by using iw or CRDA, as mentioned in the commit message.
These devices may get local RF certificated only with their preset
country setting, so manufacturers do not anticipate any changes to the
country setting.
Secondly, some APs with incorrect country settings may be placed in a
public area either accidentally or intentionally. The devices connected
to those APs could potentially violate the local RF rules if beacon
country IE hinting is not disabled in this situation.
This patch tries to solve the issue described above by disabling beacon
country IE hinting on devices coming with preset country settings. Of
course, the country IE hinting remains enabled on devices lacking
preset country code settings to adapt the regulatory domain information
based on the connected AP.
Thanks
> >
> > Best Regards,
> > Yen.
> >
> > > >
> > > > Signed-off-by: Leon Yen <leon.yen@mediatek.com>
> > > > Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
> > > > ---
> > > > drivers/net/wireless/mediatek/mt76/mt7921/init.c | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> > > b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> > > > index ef0c721d26e3..3c9a5fcd6924 100644
> > > > --- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> > > > +++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> > > > @@ -135,6 +135,13 @@ mt7921_regd_notifier(struct wiphy *wiphy,
> > > > dev->mt76.region = request->dfs_region;
> > > > dev->country_ie_env = request->country_ie_env;
> > > >
> > > > +if (request->initiator == NL80211_REGDOM_SET_BY_USER) {
> > > > +if (dev->mt76.alpha2[0] == '0' && dev->mt76.alpha2[1] == '0')
> > > > +wiphy->regulatory_flags &= ~REGULATORY_COUNTRY_IE_IGNORE;
> > > > +else
> > > > +wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE;
> > > > +}
> > > > +
> > > > if (pm->suspended)
> > > > return;
> > > >
> > >
>
prev parent reply other threads:[~2024-04-22 6:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 8:53 [PATCH] wifi: mt76: mt7921: avoid undesired changes of the preset regulatory domain Mingyen Hsieh
2024-04-12 9:27 ` Nicolas Escande
2024-04-15 5:53 ` Mingyen Hsieh (謝明諺)
2024-04-15 10:26 ` Nicolas Escande
2024-04-22 6:32 ` Mingyen Hsieh (謝明諺) [this message]
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=98f3d7bcbf235c70190f28ec6371244c047b6df3.camel@mediatek.com \
--to=mingyen.hsieh@mediatek.com \
--cc=Deren.Wu@mediatek.com \
--cc=Eric-SY.Chang@mediatek.com \
--cc=Leon.Yen@mediatek.com \
--cc=Quan.Zhou@mediatek.com \
--cc=Ryder.Lee@mediatek.com \
--cc=Sean.Wang@mediatek.com \
--cc=Shayne.Chen@mediatek.com \
--cc=Soul.Huang@mediatek.com \
--cc=ch.yeh@mediatek.com \
--cc=km.lin@mediatek.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=nbd@nbd.name \
--cc=nico.escande@gmail.com \
--cc=posh.sun@mediatek.com \
--cc=robin.chiu@mediatek.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 read-only IMAP folder(s) and NNTP newsgroup(s).