Thread (29 messages) 29 messages, 6 authors, 2026-08-20

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

From: George Valkov <hidden>
Date: 2026-08-17 13:48:15
Also in: linux-devicetree, linux-wireless, lkml, stable

On Mon, 17 Aug 2026 at 16:25, Krzysztof Kozlowski [off-list ref] wrote:
On 17/08/2026 15:20, George Valkov wrote:
quoted
On Mon, 17 Aug 2026 at 14:07, Krzysztof Kozlowski [off-list ref] wrote:
quoted
On 17/08/2026 12:43, George Valkov wrote:
quoted
On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski [off-list ref] wrote:
quoted
On Fri, Aug 14, 2026 at 03:50:23PM +0300, Georgi Valkov wrote:
quoted
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.
quoted
Does b4 diff work?

b4 diff '20260814125025.90522-1-gvalkov@gmail.com'
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!

quoted
quoted
quoted
quoted
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

quoted
quoted
quoted
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

quoted
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help