From: Stefano Radaelli <stefano.r@variscite.com>
Update the WiFi and Bluetooth configuration on the i.MX8MM VAR-SOM
to match the latest SOM hardware revision.
The SOM now integrates an NXP IW61x wireless module. WiFi is connected
via SDIO and Bluetooth via UART.
This patch:
- Adds an mmc-pwrseq node to handle module reset and power sequencing.
- Updates the USDHC1 node to use the new power sequence and required
pinctrl configuration.
- Adds the Bluetooth child node under UART2.
- Removes the legacy Broadcom WiFi device node.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
.../boot/dts/freescale/imx8mm-var-som.dtsi | 41 ++++++++++++++-----
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index cdcd8faad65e..e2b1919d7188 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -22,6 +22,14 @@ clk40m: oscillator {
clock-output-names = "can_osc";
};
+ iw61x_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+
reg_audio_supply: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "wm8904-supply";
@@ -392,11 +400,15 @@ &snvs_pwrkey {
/* Bluetooth */
&uart2 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
+ pinctrl-0 = <&pinctrl_uart2>, <&pinctrl_bt>;
assigned-clocks = <&clk IMX8MM_CLK_UART2>;
assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
uart-has-rtscts;
status = "okay";
+
+ bluetooth_iw61x: bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
};
&usbotg1 {
@@ -413,21 +425,15 @@ &usbotg2 {
/* WIFI */
&usdhc1 {
- #address-cells = <1>;
- #size-cells = <0>;
pinctrl-names = "default", "state_100mhz", "state_200mhz";
- pinctrl-0 = <&pinctrl_usdhc1>;
- pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
- pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_wifi>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_wifi>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_wifi>;
bus-width = <4>;
non-removable;
keep-power-in-suspend;
+ mmc-pwrseq = <&iw61x_pwrseq>;
status = "okay";
-
- brcmf: wifi@1 {
- reg = <1>;
- compatible = "brcm,bcm4329-fmac";
- };
};
/* SD */
@@ -465,6 +471,12 @@ &wdog1 {
};
&iomuxc {
+ pinctrl_bt: bluetoothgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6 0xc1
+ >;
+ };
+
pinctrl_can: cangrp {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x16
@@ -710,4 +722,11 @@ pinctrl_wdog: wdoggrp {
MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x166
>;
};
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_WP_GPIO2_IO20 0x140
+ MX8MM_IOMUXC_SD1_RESET_B_GPIO2_IO10 0xc1
+ >;
+ };
};
--
2.47.3Hi Stefano, On Tue, Feb 17, 2026 at 3:43 PM Stefano Radaelli <stefano.radaelli21@gmail.com> wrote: > > From: Stefano Radaelli <stefano.r@variscite.com> > > Update the WiFi and Bluetooth configuration on the i.MX8MM VAR-SOM > to match the latest SOM hardware revision. > > The SOM now integrates an NXP IW61x wireless module. WiFi is connected > via SDIO and Bluetooth via UART. > > This patch: > - Adds an mmc-pwrseq node to handle module reset and power sequencing. > - Updates the USDHC1 node to use the new power sequence and required > pinctrl configuration. > - Adds the Bluetooth child node under UART2. > - Removes the legacy Broadcom WiFi device node. What about users who still have boards with the Broadcom Wi-Fi chip? Will Wifi on the old boards stop working?
Hi Fabio! On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote: > > What about users who still have boards with the Broadcom Wi-Fi chip? > > Will Wifi on the old boards stop working? The Broadcom-based WiFi module was used on earlier revisions of the VAR-SOM-MX8MM. That hardware revision is no longer in production and is not available for new orders. All currently manufactured and shipped VAR-SOM-MX8MM modules integrate the NXP IW61x instead. Since the wireless module is soldered on the SOM and not selectable via the carrier board, the device tree must reflect the hardware that is actually present on the module. This series aligns mainline with the current production revision of the SOM. Customers using older hardware revisions still have access to the corresponding device tree descriptions in earlier kernel versions. Upstream support is being aligned with the actively produced hardware. The same applies to the Ethernet PHY update included in this series, which reflects the PHY used on the current (and future) SOM revision. Best regards, Stefano
On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote: > Hi Fabio! > > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote: > > > > What about users who still have boards with the Broadcom Wi-Fi chip? > > > > Will Wifi on the old boards stop working? > > The Broadcom-based WiFi module was used on earlier revisions of the > VAR-SOM-MX8MM. That hardware revision is no longer in production and > is not available for new orders. All currently manufactured and shipped > VAR-SOM-MX8MM modules integrate the NXP IW61x instead. This common problem, we met similar case. After replace new compenent, it should be new boards, or new revision. I don't suggest directly replace it to broken old one. You can create dt overlay files for new boards. Krzysztof Kozlowski: how about other vendor handle similar case? Any guide line for that? Frank > > Since the wireless module is soldered on the SOM and not selectable via > the carrier board, the device tree must reflect the hardware that is > actually present on the module. This series aligns mainline with the > current production revision of the SOM. > > Customers using older hardware revisions still have access to the > corresponding device tree descriptions in earlier kernel versions. > Upstream support is being aligned with the actively produced hardware. > > The same applies to the Ethernet PHY update included in this series, > which reflects the PHY used on the current (and future) SOM revision. > > Best regards, > Stefano
Hi Frank, On Wed, Feb 18, 2026 at 11:35:23AM -0500, Frank Li wrote: > On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote: > > Hi Fabio! > > > > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote: > > > > > > What about users who still have boards with the Broadcom Wi-Fi chip? > > > > > > Will Wifi on the old boards stop working? > > > > The Broadcom-based WiFi module was used on earlier revisions of the > > VAR-SOM-MX8MM. That hardware revision is no longer in production and > > is not available for new orders. All currently manufactured and shipped > > VAR-SOM-MX8MM modules integrate the NXP IW61x instead. > > This common problem, we met similar case. After replace new compenent, it > should be new boards, or new revision. > > I don't suggest directly replace it to broken old one. You can create dt > overlay files for new boards. > > Krzysztof Kozlowski: > how about other vendor handle similar case? Any guide line for > that? > > Frank > Thanks for the feedback! We understand the concern about potential regressions on older SOM revisions. However, since the wireless module is soldered on the SOM and not configurable, we are aligning the upstream device tree with the hardware revision that is currently in production. This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM platforms already present in mainline (e.g. i.MX8MP, i.MX93), which use the IW61x wireless module as well. The intention is to keep the VAR-SOM family consistent in mainline with the hardware that is actively produced. If there is a strong requirement to preserve an explicit description of the older Broadcom-based revision in mainline, we can evaluate adding a separate description. Best regards, Stefano
Hello everyone, On Wed, Feb 18, 2026 at 06:18:16PM +0100, Stefano Radaelli wrote: > Hi Frank, > > On Wed, Feb 18, 2026 at 11:35:23AM -0500, Frank Li wrote: > > On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote: > > > Hi Fabio! > > > > > > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote: > > > > > > > > What about users who still have boards with the Broadcom Wi-Fi chip? > > > > > > > > Will Wifi on the old boards stop working? > > > > > > The Broadcom-based WiFi module was used on earlier revisions of the > > > VAR-SOM-MX8MM. That hardware revision is no longer in production and > > > is not available for new orders. All currently manufactured and shipped > > > VAR-SOM-MX8MM modules integrate the NXP IW61x instead. > > > > This common problem, we met similar case. After replace new compenent, it > > should be new boards, or new revision. > > > > I don't suggest directly replace it to broken old one. You can create dt > > overlay files for new boards. > > > > Krzysztof Kozlowski: > > how about other vendor handle similar case? Any guide line for > > that? > > > > Frank > > > > Thanks for the feedback! > > We understand the concern about potential regressions on older SOM > revisions. However, since the wireless module is soldered on the SOM > and not configurable, we are aligning the upstream device tree with > the hardware revision that is currently in production. > > This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM > platforms already present in mainline (e.g. i.MX8MP, i.MX93), which > use the IW61x wireless module as well. The intention is to keep the > VAR-SOM family consistent in mainline with the hardware that is > actively produced. > > If there is a strong requirement to preserve an explicit description > of the older Broadcom-based revision in mainline, we can evaluate > adding a separate description. > > Best regards, > Stefano Do you have any update about this topic? Thank you a lot, Best Regards, Stefano
On Tue, Feb 24, 2026 at 03:57:10PM +0100, Stefano Radaelli wrote: > Hello everyone, > > On Wed, Feb 18, 2026 at 06:18:16PM +0100, Stefano Radaelli wrote: > > Hi Frank, > > > > On Wed, Feb 18, 2026 at 11:35:23AM -0500, Frank Li wrote: > > > On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote: > > > > Hi Fabio! > > > > > > > > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote: > > > > > > > > > > What about users who still have boards with the Broadcom Wi-Fi chip? > > > > > > > > > > Will Wifi on the old boards stop working? > > > > > > > > The Broadcom-based WiFi module was used on earlier revisions of the > > > > VAR-SOM-MX8MM. That hardware revision is no longer in production and > > > > is not available for new orders. All currently manufactured and shipped > > > > VAR-SOM-MX8MM modules integrate the NXP IW61x instead. > > > > > > This common problem, we met similar case. After replace new compenent, it > > > should be new boards, or new revision. > > > > > > I don't suggest directly replace it to broken old one. You can create dt > > > overlay files for new boards. > > > > > > Krzysztof Kozlowski: > > > how about other vendor handle similar case? Any guide line for > > > that? > > > > > > Frank > > > > > > > Thanks for the feedback! > > > > We understand the concern about potential regressions on older SOM > > revisions. However, since the wireless module is soldered on the SOM > > and not configurable, we are aligning the upstream device tree with > > the hardware revision that is currently in production. > > > > This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM > > platforms already present in mainline (e.g. i.MX8MP, i.MX93), which > > use the IW61x wireless module as well. The intention is to keep the > > VAR-SOM family consistent in mainline with the hardware that is > > actively produced. Actually it becomes two boards. Change components is quite common. Direct change at dts is not friendly for old boards users. > > > > If there is a strong requirement to preserve an explicit description > > of the older Broadcom-based revision in mainline, we can evaluate > > adding a separate description. > > > > Best regards, > > Stefano > > Do you have any update about this topic? If can't auto detected, I think keep old dts, use overlay change to new one. For example, board.dtb you can rename board.dtb to board-revA.dtb new board.dtb, by apply verb.dtso to board-revA.dtb. Or you direct use board-revb.dtb. If change is big, you can create new one. Frank > > Thank you a lot, > Best Regards, > Stefano
Hi Frank,
On Tue, Feb 24, 2026 at 04:30:28PM -0500, Frank Li wrote:
>
> If can't auto detected, I think keep old dts, use overlay change to new
> one.
>
> For example, board.dtb
>
> you can rename board.dtb to board-revA.dtb
> new board.dtb, by apply verb.dtso to board-revA.dtb. Or you direct use
> board-revb.dtb.
>
> If change is big, you can create new one.
>
> Frank
Thanks for the clarification, I understand that the preferred approach
would be to keep the existing Broadcom-based DTS unchanged and add a
separate description for the IW612-based revision.
My only concern is avoiding confusion in mainline.
The Broadcom-based SOM revision is obsolete and no longer manufactured.
All currently produced VAR-SOM-MX8MM modules use the IW612 module, and
this will remain the only production hardware going forward.
I would like to avoid giving the impression that we are actively
supporting two parallel SOM revisions in mainline, while in reality
only the IW612-based hardware exists in production.
For this reason, would it be acceptable to:
- move the Broadcom-based description into an explicitly legacy
revision-specific DTS (kept unchanged for existing users), and
- update the main imx8mm-var-som DTS to reflect the current
IW612-based hardware?
This would preserve compatibility for older boards, but ensure that
the primary DTS in mainline represents the hardware that is actually
produced and aligns with the rest of the VAR-SOM family.
Thank you again for your support and your patience!
Best regards,
Stefano
On Thu, Feb 26, 2026 at 06:44:59PM +0100, Stefano Radaelli wrote: > Hi Frank, > > On Tue, Feb 24, 2026 at 04:30:28PM -0500, Frank Li wrote: > > > > If can't auto detected, I think keep old dts, use overlay change to new > > one. > > > > For example, board.dtb > > > > you can rename board.dtb to board-revA.dtb > > new board.dtb, by apply verb.dtso to board-revA.dtb. Or you direct use > > board-revb.dtb. > > > > If change is big, you can create new one. > > > > Frank > > Thanks for the clarification, I understand that the preferred approach > would be to keep the existing Broadcom-based DTS unchanged and add a > separate description for the IW612-based revision. > > My only concern is avoiding confusion in mainline. > > The Broadcom-based SOM revision is obsolete and no longer manufactured. > All currently produced VAR-SOM-MX8MM modules use the IW612 module, and > this will remain the only production hardware going forward. > > I would like to avoid giving the impression that we are actively > supporting two parallel SOM revisions in mainline, while in reality > only the IW612-based hardware exists in production. > > For this reason, would it be acceptable to: > > - move the Broadcom-based description into an explicitly legacy > revision-specific DTS (kept unchanged for existing users), and > - update the main imx8mm-var-som DTS to reflect the current > IW612-based hardware? The direction is correct. Just try to reduce duplicate the same code. Frank > > This would preserve compatibility for older boards, but ensure that > the primary DTS in mainline represents the hardware that is actually > produced and aligns with the rest of the VAR-SOM family. > > Thank you again for your support and your patience! > > Best regards, > Stefano
© 2016 - 2026 Red Hat, Inc.