Re: [PATCH 1/3] dt-bindings: net: wireless: add flag marvell,ignore-regulatory-hint

On Mon, 17 Aug 2026 at 16:25, Krzysztof Kozlowski <[email protected]> wrote:
>
> On 17/08/2026 15:20, George Valkov wrote:
> > On Mon, 17 Aug 2026 at 14:07, Krzysztof Kozlowski <[email protected]> wrote:
> >>
> >> On 17/08/2026 12:43, George Valkov wrote:
> >>> On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski <[email protected]> wrote:
> >>>>
> >>>> On Fri, Aug 14, 2026 at 03:50:23PM +0300, Georgi Valkov wrote:
> >>>>> WRT3200ACM and WRT32x routers always report a fixed US regulatory domain
> >>>>> from the mwifiex ROM, which conflicts with the platform regulatory
> >>>>> configuration on units sold outside the US market. For example:
> >>>>> - phy0 mwlwifi 5 GHz, hard-coded region 98 EU mapped to FR
> >>>>> - phy1 mwlwifi 2.4 GHz, hard-coded region 98 EU mapped to FR
> >>>>> - phy2 mwifiex 2.4 and 5 GHz, hard-coded region US
> >>>>
> >>>> v1 as reply to v3 in big thread. How tools can parse that?
> >>>
> >>> Hello Krzysztof,
> >>> I apologise, I forgot to add the v4 tag to the subject.
> >>> I have documented the changes between each revision.
> >>> I saw my mistake after sending the mail. But I wasn't sure
> >>> what to do? I will make sure to add v5 to my next revision.
> >>>
> >>>> Does b4 diff work?
> >>>>
> >>>> b4 diff '[email protected]'
> >>>
> >>> What is b4?
> >>
> >> Tool used by maintainers and contributors to handle/send patches. See
> >> korg docs (or just google "What is b4 Linux kernel").
> >
> > Thanks!
> >
> >
> >>>>> When the system boots, it detects a conflict between the user selected
> >>>>> region and the radios, e.g. BG FR US, and applies extreme restrictions,
> >>>>> preventing use of 5 GHz and DFS channels. This also affects phy0.
> >>>>>
> >>>>> Add a device-tree flag, which allows affected platforms to ignore
> >>>>> an incorrect regulatory hint from ROM, so userspace can set the
> >>>>> correct platform regulatory domain.
> >>>>>
> >>>>> [1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
> >>>>> [2] https://github.com/openwrt/openwrt/issues/9956
> >>>>>
> >>>>> Tested-on: WRT3200ACM, OpenWrt
> >>>>
> >>>> Not a valid tag, drop.
> >>>
> >>> I believe the tag is helpful because it describes that my changes
> >>> have been tested on a certain device and platform. It's a common
> >>> practice in OpenWrt contributions. My last two accepted patches
> >>> have this tag. Should I still remove it?
> >>
> >> Drop the tag everywhere and instead on the patches which were possible
> >> to be tested mention how did you test it.
> >
> > ok
> >
> >
> >>>> And you cannot even do that, otherwise explain me
> >>>> how did your device execute THIS (exactly THIS) code?
> >>>
> >>> I am not used to your terminology and this gets me completely confused.
> >>> You have not quoted any particular code change, so I'm not sure what
> >>> you are referring to. Here is a summary of the patch series:
> >>
> >> Tested means executing or parsing or using the code on the device under
> >> test. How can you execute/parse/use this code on the device?
> >
> > Test procedure:
> > Compile, FLASH and run OpenWrt firmware for WRT3200ACM.
> > This compiles the Linux kernel along with all dts files and drivers.
> >
> > 1. Before the fix
> > Notice how each radio has its own country:
> > iw reg get
> > https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
> >
> > If the user sets their correct country code, e.g. BG, then global
> > will be set to BG. This conflicts with FR from phy0 and phy1.
> > And also conflicts with phy2 which reports US.
> > Result: the main radio phy0 does not start.
> >
> > 2. With the fix applied
> > iw reg get
> > phy2 does not appear in the list, so there is no conflict with the US
> > region. I can address phy0 and phy1 later in another PR. They need
> > a similar device-tree flag in the board file. The actual driver is not part
> > of Linux. So I'm not sure if there is any place to add documentation?
> > Result: phy0 and phy2 work. 5 GHz and DFS work.
> >
> > I also used this test code to confirm that the flag is set:
> > mwifiex_dbg(adapter, ERROR,
> >             "[%s][%pfwP] ignore-regulatory-hint %u ++\n",
> >             dev_name(adapter->dev), dev_fwnode(adapter->dev),
> >             device_property_read_bool(adapter->dev,
> >                                       "marvell,ignore-regulatory-hint"));
> >
> > [   19.927595] mwifiex_sdio mmc0:0001:1:
> > [mmc0:0001:1][wifi@1] ignore-regulatory-hint 1 ++
>
> You are not responding to the actual problem.
>
> In very simple words, like one or two sentences, explain me how this
> YAML file affected `iw reg get`?

It does not affect `iw reg get`.
I was asked to document the flag there, before I use it.
Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml


> >>> Patch 1 documents a new flag: marvell,ignore-regulatory-hint.
> >>> Patch 2 adds a device-tree node with the radio and the flag.
> >>> Patch 3 skips the regulatory_hint() call when the flag is set.
> >>
> >> I can read your patchsets and above does not proof how can you test binding.
> >
> > Ah, you mean how I tested if the device-tree changes are valid?
> > I have almost no experience with dts. I ran this command before
> > sending v4, and I think it seems fine. Here's a link to the output:
> > make dt_binding_check
> > https://httpstorm.com/share/.openwrt/test/2026-08-17_mwifiex/dt_binding_check-01.txt
>
> This is a make process, so build stage. Nothing related to testing on DUT.
>
> Building kernel (and running standard tools) is not testing, so I repeat
> - do not introduce "tested" statements to commits which is impossible to
> test by the definition of "tested" in Linux kernel. We discuss all this
> in this very specific patch, not some other patches.

ok, I will drop the Tested-on tag for patch 1 and 2.
For patch 3, which can be tested, I need to describe how
I tested the changes, e.g: iw reg get, and print the flag.

Note taken. Thank you!

Georgi Valkov