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 USv1 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, OpenWrtNot 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.okquoted
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.txtThis 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