[PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

[PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

[Georgi Valkov]

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

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.

Implement a device-tree flag, which allows affected platforms to ignore
an incorrect regulatory hint in the ROM, so userspace can set the correct
platform regulatory domain. The radios in WRT3200ACM/WRT32x are locked to
the hard-coded configuration for which they are certified, so the only
impact is that the region conflict is avoided and the 5 GHz radios can
be used.

The change affects only platforms which explicitly define this flag, and
helps overcome the incorrect behaviour of proprietary radio firmware.

[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956

Tested-on: WRT3200ACM, OpenWrt
Cc: stable@vger.kernel.org
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
---
Hi Jeff,
I did not consider the idea suggested by openwrt-ai, because I do not
understand it and I do not know how to implement it.
Any help is welcome!

v3:
I implemented and tested a better approach with no board specific code:
1. check for a device-tree flag in mwifiex_register_cfg80211in()
  !of_property_read_bool(of_root, "marvell,ignore-regulatory-hint")
2. add this flag to the root device tree of each affected board
Currently this affects only armada-385-linksys-rango.dts,
because Linux has no dts for venom. OpenWrt will take care of that.
This approach is more flexible and scalable, because the flag can
also be used in other drivers, e.g. mwlwifi (not part of Linux).

v2:
Replace the compatible device names, which are currently only available on
OpenWrt with board names which are available on both Linux and OpenWrt.

 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index abc703441c5d..0239b1c9214b 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4899,7 +4899,14 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
 				country_code =
 					mwifiex_11d_code_2_region(
 						adapter->region_code);
+
+				/* Allow platforms to ignore an incorrect
+				 * regulatory hint from ROM, so userspace
+				 * can set the correct regulatory domain.
+				 */
 				if (country_code &&
+				    !of_property_read_bool(of_root,
+							   "marvell,ignore-regulatory-hint") &&
 				    regulatory_hint(wiphy, country_code))
 					mwifiex_dbg(priv->adapter, ERROR,
 						    "regulatory_hint() failed\n");
-- 
2.55.0

[PATCH v3 2/2] ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint

[Georgi Valkov]

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

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 marvell,ignore-regulatory-hint to the WRT3200ACM
device-tree, which signals mwifiex to ignore an incorrect regulatory hint
in the ROM, so userspace can set the correct platform regulatory domain.
The radios in WRT3200ACM/WRT32x are locked to the hard-coded configuration
for which they are certified, so the only impact is that the region
conflict is avoided and the 5 GHz radios can be used.

The Linux kernel sources do not have support for WRT32x. An equivalent
patch for these routers has to be sent to OpenWrt.

[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956

Tested-on: WRT3200ACM, OpenWrt
Cc: stable@vger.kernel.org
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
---
 arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
index 4ab45f294de2..6e283e223ca4 100644
--- a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
@@ -14,6 +14,7 @@ / {
 	model = "Linksys WRT3200ACM";
 	compatible = "linksys,rango", "linksys,armada385", "marvell,armada385",
 		     "marvell,armada380";
+	marvell,ignore-regulatory-hint;
 };
 
 &expander0 {
-- 
2.55.0

Re: [PATCH v3 2/2] ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The device-specific property `marvell,ignore-regulatory-hint` is incorrectly placed in the global root node (`/`), lacking binding documentation and causing the quirk to erroneously apply to all `mwifiex` devices.
- [Medium] The `mwifiex` driver directly accesses the global `of_root` variable, which is undefined when `CONFIG_OF` is disabled, violating the driver model and risking linker errors.
--

--- Patch [2]: [PATCH v3 2/2] ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint ---
commit 7033e1a77e69407f0088e5cd43fbc6b4fc03d549
Author: Georgi Valkov <gvalkov@gmail.com>

ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint

This patch adds the marvell,ignore-regulatory-hint flag to the WRT3200ACM
device tree. It prevents the system from applying extreme restrictions due
to conflicts between the user-selected region and the radios' hard-coded
US region.

> diff --git a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
> index 4ab45f294de22..6e283e223ca4c 100644
> --- a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
> +++ b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
> @@ -14,6 +14,7 @@ / {
>  	model = "Linksys WRT3200ACM";
>  	compatible = "linksys,rango", "linksys,armada385", "marvell,armada385",
>  		     "marvell,armada380";
> +	marvell,ignore-regulatory-hint;

[Severity: High]
Does adding this device-specific property to the global root node (/) instead
of a dedicated device node cause a regression where it applies universally?

Because the driver in drivers/net/wireless/marvell/mwifiex/cfg80211.c queries
this property from the root node:

mwifiex_register_cfg80211():
                if (country_code &&
                    !of_property_read_bool(of_root,
                                           "marvell,ignore-regulatory-hint") &&
                    regulatory_hint(wiphy, country_code))

this board quirk will be broadcast globally across the system.

If a user connects a generic USB mwifiex Wi-Fi adapter to this router, it
appears the driver would incorrectly apply the board quirk to the external
adapter, potentially causing a regression in regulatory compliance by ignoring
its valid regulatory hint.

Would it be safer to use of_machine_is_compatible() for this platform quirk?

[Severity: Medium]
Will querying of_root directly in the mwifiex driver cause a compilation
regression when CONFIG_OF is disabled?

Since of_root is only defined in drivers/of/base.c, and the mwifiex driver
does not depend on CONFIG_OF, this relies entirely on the compiler's dead-code
elimination to drop the of_root symbol reference when of_property_read_bool()
expands to an inline dummy.

Relying on dead code elimination for undefined symbols can be brittle.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807182124.41572-1-gvalkov@gmail.com?part=2

Re: [PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] A vendor/device-specific workaround property (`marvell,ignore-regulatory-hint`) is incorrectly read from the global root device tree node (`of_root`) rather than the device's own OF node. Device Tree must correctly model hardware topology by placing device-specific properties in the node representing that physical device. Placing a vendor-specific property in the root node applies it globally to the entire system. If a system contains multiple Marvell Wi-Fi adapters (e.g., one built-in and one plugged in via USB or PCIe) and only one requires the regulatory hint to be ignored, this global flag will incorrectly apply the quirk to all of them. The driver should read this property from its own device node (e.g., `adapter->dev->of_node` or `adapter->dt_node`).
--

--- Patch [1]: [PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x ---
commit 3a34f3fd7103c1109fdfbb027f11821961b37978
Author: Georgi Valkov <gvalkov@gmail.com>

wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

This commit introduces a device-tree flag to allow affected platforms to
ignore incorrect regulatory hints hardcoded in the mwifiex ROM. This enables
userspace to set the correct platform regulatory domain and prevents extreme
restrictions on 5 GHz and DFS channels.

[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956

> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -4899,7 +4899,14 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
>  				country_code =
>  					mwifiex_11d_code_2_region(
>  						adapter->region_code);
> +
> +				/* Allow platforms to ignore an incorrect
> +				 * regulatory hint from ROM, so userspace
> +				 * can set the correct regulatory domain.
> +				 */
>  				if (country_code &&
> +				    !of_property_read_bool(of_root,
> +							   "marvell,ignore-regulatory-hint") &&

[Severity: Medium]
Is it intentional to read the device-specific property from the global of_root
node rather than the adapter's own device node (e.g., adapter->dev->of_node
or adapter->dt_node)?

If a system contains multiple Marvell Wi-Fi adapters and only one requires
this workaround, reading from the root node will globally apply the quirk to
all adapters in the system.

Would it be better to adhere to device tree architectural principles by
placing and reading this property in the node representing the specific
physical device?

>  				    regulatory_hint(wiphy, country_code))
>  					mwifiex_dbg(priv->adapter, ERROR,
>  						    "regulatory_hint() failed\n");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807182124.41572-1-gvalkov@gmail.com?part=1

Re: [PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

[Johannes Berg]

On Fri, 2026-08-07 at 21:21 +0300, Georgi Valkov wrote:
> 
> +				/* Allow platforms to ignore an incorrect
> +				 * regulatory hint from ROM, so userspace
> +				 * can set the correct regulatory domain.
> +				 */
>  				if (country_code &&
> +				    !of_property_read_bool(of_root,
> +							   "marvell,ignore-regulatory-hint") &&
>  				    regulatory_hint(wiphy, country_code))

You're supposed to always update bindings first, no?

johannes

Re: [PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

[George Valkov]

Hello Johannes, and thank you for your quick reply!

> You're supposed to always update bindings first, no?
To me the logical order is to implement the feature in the driver and
then enable it in each board which needs it. For Linux just WRT3200ACM.
A separate patch for WRT32x should be sent to OpenWrt.

Please let me know if I should reverse the order.


Hello Sashiko AI,
Yes, I intentionally implemented the flag as a root node.
This way the new device-tree property can be reused for the
other radios, which use mwlwifi, and also require this fix.

It would be inefficient and impractical to define a separate
device-tree property for each radio, where it is actually the
board that is affected, so it should be a per-board setting.

Also my attempts to use per device nodes or the parent always
return false so they are not usable.

I do not understand the part about dependence on CONFIG_OF.
of_property_read_bool() returns false when the flag is not
defined. This preserves the original behaviour as if it is
set to false, so the feature is disabled.
External radios which do not implement support for this flag
are not affected.

v2 of this PR used of_machine_is_compatible, but there was an
objection that this adds platform code to the driver.

How can I add binding documentation and where?

On Fri, 7 Aug 2026 at 21:39, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2026-08-07 at 21:21 +0300, Georgi Valkov wrote:
> >
> > +                             /* Allow platforms to ignore an incorrect
> > +                              * regulatory hint from ROM, so userspace
> > +                              * can set the correct regulatory domain.
> > +                              */
> >                               if (country_code &&
> > +                                 !of_property_read_bool(of_root,
> > +                                                        "marvell,ignore-regulatory-hint") &&
> >                                   regulatory_hint(wiphy, country_code))
>
> You're supposed to always update bindings first, no?
>
> johannes

Re: [PATCH v3 1/2] wifi: mwifiex: ignore ROM regulatory hint on WRT3200ACM/WRT32x

[Brian Norris]

On Fri, Aug 07, 2026 at 10:49:40PM +0300, George Valkov wrote:
> Hello Johannes, and thank you for your quick reply!
> 
> > You're supposed to always update bindings first, no?
> To me the logical order is to implement the feature in the driver and
> then enable it in each board which needs it. For Linux just WRT3200ACM.
> A separate patch for WRT32x should be sent to OpenWrt.
> 
> Please let me know if I should reverse the order.

Johannes is asking about the binding documentation (.txt or .yaml), not
the .c (driver) or .dts/.dtsi files. You haven't included
"marvell,ignore-regulatory-hint" in any valid binding document, so it's
not a valid property to use in this driver.

See Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
for the correct binding file relevant to this driver.

> Hello Sashiko AI,
> Yes, I intentionally implemented the flag as a root node.
> This way the new device-tree property can be reused for the
> other radios, which use mwlwifi, and also require this fix.
> 
> It would be inefficient and impractical to define a separate
> device-tree property for each radio, where it is actually the
> board that is affected, so it should be a per-board setting.

I'm not sure what you're saying here. Device Tree Blobs are inherently a
per-board object. The question here is simply where within the Device
Tree we want to add a property.

I believe that you're describing problems with the radio, and so you
should add DT properties to the node for the radio(s) in question, not
the root node.

> Also my attempts to use per device nodes or the parent always
> return false so they are not usable.

That seems like something you need to figure out. Just because you found
it difficult doesn't mean we should accept the wrong approach.

IIUC, you're using a PCIe-based WiFi card, and that's enabled in
arch/arm/boot/dts/marvell/armada-385-linksys.dtsi:

&pcie1 {
        /* Marvell 88W8864, 5GHz-only */
        status = "okay";
};

&pcie2 {
        /* Marvell 88W8864, 2GHz-only */
        status = "okay";
};

I think those are the "port" nodes, and there currently is no node that
actually represents the PCIe endpoint device (i.e., your wifi cards).
You need to add those as children, like:

&pcie1 {
...
	wifi@0 {
		compatible = "pciXXXX,YYYY"; /* figure out the appropriate IDs here */
		marvell,ignore-regulatory-hint;
		...
	};
};
...

> I do not understand the part about dependence on CONFIG_OF.
> of_property_read_bool() returns false when the flag is not
> defined. This preserves the original behaviour as if it is
> set to false, so the feature is disabled.
> External radios which do not implement support for this flag
> are not affected.

I think if you stop using 'of_root', you'll dodge this problem. And you
should not be looking at of_root.

> v2 of this PR used of_machine_is_compatible, but there was an
> objection that this adds platform code to the driver.
> 
> How can I add binding documentation and where?

Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml. See
the other hints above too.

Side question: did you consider Jeff's suggestion from v2, to try the
'reg_alpha2' module param? It might already do what you need, and it
only requires you configure your OpenWrt builds properly, I think.

Brian

> On Fri, 7 Aug 2026 at 21:39, Johannes Berg <johannes@sipsolutions.net> wrote:
> >
> > On Fri, 2026-08-07 at 21:21 +0300, Georgi Valkov wrote:
> > >
> > > +                             /* Allow platforms to ignore an incorrect
> > > +                              * regulatory hint from ROM, so userspace
> > > +                              * can set the correct regulatory domain.
> > > +                              */
> > >                               if (country_code &&
> > > +                                 !of_property_read_bool(of_root,
> > > +                                                        "marvell,ignore-regulatory-hint") &&
> > >                                   regulatory_hint(wiphy, country_code))
> >
> > You're supposed to always update bindings first, no?
> >
> > johannes

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

[Georgi Valkov]

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

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
Cc: stable@vger.kernel.org
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
---
Thank you Brian and Johannes!

> Just because you found it difficult doesn't mean we should accept the
> wrong approach.

I agree. Guidance and careful inspection helps reach a good solution.

> IIUC, you're using a PCIe-based WiFi card, and that's enabled in
> arch/arm/boot/dts/marvell/armada-385-linksys.dtsi:
>
> &pcie1 {
>         /* Marvell 88W8864, 5GHz-only */
>         status = "okay";
> };
>
> &pcie2 {
>         /* Marvell 88W8864, 2GHz-only */
>         status = "okay";
> };

No, you are referring to the main radios, which are not part of these
patch series. Would you allow me to also add the flag to them? Their
driver is not part of Linux so only dt bindings need to be added.

The changes here target the third radio:
- phy2: Marvell 88W8887 802.11ac/b/g/n 2.4 / 5 GHz, region US
- compatible = marvell,sd8897 works

I cannot confirm if any other devices from the family need the fix
or not, so I intentionally target the board dts, and not the include:
armada-385-linksys.dtsi

> Side question: did you consider Jeff's suggestion from v2, to try the
> 'reg_alpha2' module param? It might already do what you need, and it
> only requires you configure your OpenWrt builds properly, I think.

A universal solution is better than targeting OpenWrt only.
And unfortunately I have no idea how to implement this.

> I'm not sure what you're saying here

In v3 I wanted to reuse a flag for both drivers. Using a root flag was
objected, so in v4 I added a flag for mwifiex, and I would like to add
the same flag to mwlwifi later.

- driver
dev_name(adapter->dev) = mmc0:0001:1
dev_fwnode(adapter->dev) = wifi@1
marvell,ignore-regulatory-hint = 1

- procfs
/proc/device-tree/soc/internal-regs/sdhci@d8000/wifi@1
compatible = marvell,sd8897
marvell,ignore-regulatory-hint
name = wifi
reg

v4:
1. Add binding documentation for flag marvell,ignore-regulatory-hint
2. Add dt for sd8897 and move the flag there, I used sample from docs
3. Use device_property_read_bool in the driver

v3:
I implemented and tested a better approach with no board specific code:
1. check for a device-tree flag in mwifiex_register_cfg80211in()
  !of_property_read_bool(of_root, "marvell,ignore-regulatory-hint")
2. add this flag to the root device tree of each affected board
Currently this affects only armada-385-linksys-rango.dts,
because Linux has no dts for venom. OpenWrt will take care of that.
This approach is more flexible and scalable, because the flag can
also be used in other drivers, e.g. mwlwifi (not part of Linux).

v2:
Replace the compatible device names, which are currently only available on
OpenWrt with board names which are available on both Linux and OpenWrt.

 .../devicetree/bindings/net/wireless/marvell,sd8787.yaml    | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
index 930b700b73d0..5f235cb9f3e5 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
@@ -59,6 +59,12 @@ properties:
     description: Calibration data for sub-band 3 in the 5GHz band.
     maxItems: 502
 
+  marvell,ignore-regulatory-hint:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Ignore an incorrect regulatory hint from ROM,
+      so userspace can set the correct regulatory domain.
+
   marvell,wakeup-pin:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-- 
2.55.0

[PATCH 2/3] ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint

[Georgi Valkov]

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

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 flag marvell,ignore-regulatory-hint to the WRT3200ACM device-tree,
which signals mwifiex to ignore an incorrect regulatory hint from ROM,
so userspace can set the correct platform regulatory domain. The radios
in WRT3200ACM/WRT32x are locked to the hard-coded configuration for which
they are certified, so the only impact is that the region conflict is
avoided and the 5 GHz radios can be used.

The Linux kernel sources do not have support for WRT32x. An equivalent
patch for these routers has to be sent to OpenWrt.

[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956

Tested-on: WRT3200ACM, OpenWrt, make dt_binding_check: pass
Cc: stable@vger.kernel.org
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
---
 arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
index 4ab45f294de2..c5f94463ef71 100644
--- a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
@@ -165,6 +165,12 @@ &sdhci {
 	wp-inverted;
 	bus-width = <8>;
 	status = "okay";
+
+	wifi@1 {
+		compatible = "marvell,sd8897";
+		reg = <1>;
+		marvell,ignore-regulatory-hint;
+	};
 };
 
 &usb3_1_vbus {
-- 
2.55.0

Re: [PATCH 2/3] ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing `#address-cells` and `#size-cells` in the `&sdhci` node causes the `wifi@1` child node's `reg` property to be malformed, triggering dtc compilation warnings.
--

--- Patch [2]: [PATCH 2/3] ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint ---
commit 28267c9e17b352aed9318b01c48207c391929954
Author: Georgi Valkov <gvalkov@gmail.com>

ARM: dts: armada: WRT3200ACM: add marvell,ignore-regulatory-hint

This commit adds the marvell,ignore-regulatory-hint flag to the WRT3200ACM
device tree. It creates a new wifi@1 child node within the sdhci node to
instruct mwifiex to ignore incorrect regulatory hints from ROM.

> diff --git a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
> index 4ab45f294de22..c5f94463ef710 100644
> --- a/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
> +++ b/arch/arm/boot/dts/marvell/armada-385-linksys-rango.dts
> @@ -165,6 +165,12 @@ &sdhci {
>  	wp-inverted;
>  	bus-width = <8>;
>  	status = "okay";
> +
> +	wifi@1 {
> +		compatible = "marvell,sd8897";
> +		reg = <1>;

[Severity: Low]
Does the parent &sdhci node need #address-cells = <1>; and #size-cells = <0>;
defined so the dtc compiler can correctly parse the reg = <1>; property?

Without these, dtc falls back to default cell sizes, which can cause
compilation warnings about invalid property lengths.

> +		marvell,ignore-regulatory-hint;
> +	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260814125025.90522-1-gvalkov@gmail.com?part=2

[PATCH 3/3] wifi: mwifiex: add dt flag to ignore incorrect ROM regulatory hint

[Georgi Valkov]

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

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.

Implement 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. This avoids the region conflict and allows
the 5 GHz radios to be used.

The change affects only platforms which explicitly define this flag, and
helps overcome the incorrect behaviour of proprietary radio firmware.

[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956

Tested-on: WRT3200ACM, OpenWrt
Cc: stable@vger.kernel.org
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index abc703441c5d..26978158a0ad 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4899,7 +4899,14 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
 				country_code =
 					mwifiex_11d_code_2_region(
 						adapter->region_code);
+
+				/* Allow platforms to ignore an incorrect
+				 * regulatory hint from ROM, so userspace
+				 * can set the correct regulatory domain.
+				 */
 				if (country_code &&
+				    !device_property_read_bool(adapter->dev,
+							       "marvell,ignore-regulatory-hint") &&
 				    regulatory_hint(wiphy, country_code))
 					mwifiex_dbg(priv->adapter, ERROR,
 						    "regulatory_hint() failed\n");
-- 
2.55.0

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

[Krzysztof Kozlowski]

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?

Does b4 diff work?

b4 diff '20260814125025.90522-1-gvalkov@gmail.com'


> 
> 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. And you cannot even do that, otherwise explain me
how did your device execute THIS (exactly THIS) code?

> Cc: stable@vger.kernel.org

Drop, what is the bug being fixed here?

Anyway, property looks like SW choice. You must describe hardware
instead.

Best regards,
Krzysztof

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

[George Valkov]

On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> 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 '20260814125025.90522-1-gvalkov@gmail.com'

What is b4?


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


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

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.

> > Cc: stable@vger.kernel.org
>
> Drop, what is the bug being fixed here?

Without these patch series:
- all 5 GHz radios are unusable and DFS channels do not work

With the fix applied:
- all 5 GHz radios work correctly, the platform is allowed to use
  the correct regulatory domain for which the device is certified

So this is indeed a bug fix and a very important one too.
I thought the commit description and forum links make this clear enough.
I can send more links if you wish, or just search: WRT3200ACM DFS.
There are endless conversations and many people looking for a fix.

> Anyway, property looks like SW choice. You must describe hardware
> instead.

I am sorry, I do not understand what you want me to do?
Can you please send a diff or a clear description suitable for people
who have way less experience than you?

Georgi Valkov

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

[Krzysztof Kozlowski]

On 17/08/2026 12:43, George Valkov wrote:
> On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> 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 '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").


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

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

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

> 
>>> Cc: stable@vger.kernel.org
>>
>> Drop, what is the bug being fixed here?
> 


Best regards,
Krzysztof

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

[George Valkov]

On Mon, 17 Aug 2026 at 14:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 17/08/2026 12:43, George Valkov wrote:
> > On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> 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 '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!


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


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

I have not inspected the output from rebuilding the kernel yet:
make target/linux/{clean,compile} -j 1 V=s
https://httpstorm.com/share/.openwrt/test/2026-08-17_mwifiex/linux-01.txt

Sashiko AI said that #address-cells and #size-cells are missing,
so I am currently looking for a way to find the correct values.
The radio works without them, but I should address all issues,
before sending v5. Please write a list of tests I should run!
How can I confirm the values are correct?

Thanks for your help!
Georgi Valkov

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

[Krzysztof Kozlowski]

On 17/08/2026 15:20, George Valkov wrote:
> On Mon, 17 Aug 2026 at 14:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 17/08/2026 12:43, George Valkov wrote:
>>> On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> 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 '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!
> 
> 
>>>>> 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`?


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

Best regards,
Krzysztof

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

[George Valkov]

On Mon, 17 Aug 2026 at 16:25, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 17/08/2026 15:20, George Valkov wrote:
> > On Mon, 17 Aug 2026 at 14:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 17/08/2026 12:43, George Valkov wrote:
> >>> On Mon, 17 Aug 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> 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 '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!
> >
> >
> >>>>> 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