* Re: [PATCH v5] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: Midgy Balon @ 2026-03-27 9:07 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Jonas Karlman, linux-rockchip, shawn.lin, jonas, linux-arm-kernel,
devicetree
In-Reply-To: <10821700.nUPlyArG6x@phil>
Hello Heiko,
I apologize for missing Jonas' comments. It will be done for the next
version as requested.
Indeed Claude works "well" :D . I'll be more careful next time.
Thanks,
Midgy
Le mar. 24 mars 2026 à 23:27, Heiko Stuebner <heiko@sntech.de> a écrit :
>
> Hi Jonas,
>
> Am Dienstag, 24. März 2026, 18:15:38 Mitteleuropäische Normalzeit schrieb Jonas Karlman:
> > Hi Heiko,
> >
> > On 3/24/2026 6:04 PM, Heiko Stuebner wrote:
> > >
> > > On Fri, 20 Mar 2026 10:44:41 +0100, MidG971 wrote:
> > >> The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
> > >> provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
> > >> This chip is currently modeled only as a fixed regulator
> > >> (vcc3v3_pi6c_03), with no clock output representation.
> > >>
> > >> The PI6C20100 is a clock generator, not a power supply. Model it
> > >> properly as a gated-fixed-clock, following the pattern established
> > >> for the Rock 5 ITX and other boards with similar PCIe clock buffer
> > >> chips.
> > >>
> > >> [...]
> > >
> > > Applied, thanks!
> >
> > My comments from v3 [1] was not addressed in v4 och v5. E.g.
> > regulator-always-on/boot-on not being removed and redundant comments.
> >
> > [1] https://lore.kernel.org/all/fec0f25d-733a-4b6c-aef1-2ac51bd15798@kwiboo.se/
>
> thank you so much for noticing. Looks like that AI thing is
> working "well" ;-) .
>
> I've droped the patch and recreated the for-next branch now.
>
> @Midgy, please honor feedback in future revisions.
>
> Thanks
> Heiko
>
>
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: renesas: Fix missing cells and reg in Draak/Ebisu panel DTO
From: Laurent Pinchart @ 2026-03-27 9:07 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-2-marek.vasut+renesas@mailbox.org>
On Thu, Mar 26, 2026 at 05:23:58AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into Draak/Ebisu panel DTO to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
It's slightly annoying to have to specify those properties in overlays.
It would be nice to improve the tooling, but a warning-free build is
probably a more important target for now.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
> index 258f8668ca361..90767d74e21b2 100644
> --- a/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
> +++ b/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
> @@ -27,7 +27,12 @@ &lvds1 {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> lvds1_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: renesas: Fix missing cells and reg in Salvator-X panel DTO
From: Laurent Pinchart @ 2026-03-27 9:07 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
Thank you for the patch.
On Thu, Mar 26, 2026 at 05:23:59AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into Salvator-X panel DTO to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
> index c83a30adc6adf..7807c3f80409a 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
> +++ b/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
> @@ -27,7 +27,12 @@ &lvds0 {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> lvds0_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 0/3] Add support for Variscite DART-MX93 and Sonata board
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini
This patch series adds support for the Variscite DART-MX93 system on
module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
v1->v2:
- Remove clock-frequency property from eqos node
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
arm64: dts: freescale: Add support for Variscite DART-MX93
arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
.../boot/dts/freescale/imx93-var-dart.dtsi | 461 ++++++++++++
4 files changed, 1122 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
base-commit: 6c4b48012d57f205c94f25da0c68a4027ea6daf6
--
2.47.3
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini, Conor Dooley
In-Reply-To: <cover.1774601806.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX93 SoM and Variscite
development carrier Board.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
-
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index da2be7114f64..77497a261fd5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1587,6 +1587,12 @@ properties:
- const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM
- const: fsl,imx91
+ - description: Variscite DART-MX93 based boards
+ items:
+ - const: variscite,var-dart-mx93-sonata # Variscite DART-MX93 on Sonata Development Board
+ - const: variscite,var-dart-mx93 # Variscite DART-MX93 SOM
+ - const: fsl,imx93
+
- description: Variscite VAR-SOM-MX93 based boards
items:
- const: variscite,var-som-mx93-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: Add support for Variscite DART-MX93
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini
In-Reply-To: <cover.1774601806.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX93 system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX93 MPU processor
- Up to 2GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Remove clock-frequency property from eqos node
.../boot/dts/freescale/imx93-var-dart.dtsi | 461 ++++++++++++++++++
1 file changed, 461 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
new file mode 100644
index 000000000000..69495bb7fc9f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX93
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx93.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 Module";
+ compatible = "variscite,var-dart-mx93", "fsl,imx93";
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio3 7 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&cm33 {
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = <&mu1 0 1>,
+ <&mu1 1 1>,
+ <&mu1 3 1>;
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ status = "okay";
+};
+
+&eqos {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_eqos>;
+ pinctrl-1 = <&pinctrl_eqos_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ snps,clk-csr = <5>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ };
+ };
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c3_gpio>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk IMX93_CLK_SAI1_GATE>;
+ clock-names = "mclk";
+ AVDD-supply = <&buck5>;
+ CPVDD-supply = <&buck5>;
+ DBVDD-supply = <&buck4>;
+ DCVDD-supply = <&buck5>;
+ MICVDD-supply = <&buck5>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ /* DMIC is connected to IN1L */
+ wlf,in1l-as-dmicdat1;
+ };
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <2237500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+/* BT module */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>, <&pinctrl_bt>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&mu1 {
+ status = "okay";
+};
+
+&mu2 {
+ status = "okay";
+};
+
+&sai1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_sai1>;
+ pinctrl-1 = <&pinctrl_sai1_sleep>;
+ assigned-clocks = <&clk IMX93_CLK_SAI1>;
+ assigned-clock-parents = <&clk IMX93_CLK_AUDIO_PLL>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-3 = <&pinctrl_usdhc3_sleep>, <&pinctrl_usdhc3_wlan>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ keep-power-in-suspend;
+ bus-width = <4>;
+ non-removable;
+ wakeup-source;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
+ >;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
+ MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
+ MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
+ MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
+ MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ MX93_PAD_UART2_TXD__GPIO1_IO07 0x51e
+ >;
+ };
+
+ pinctrl_eqos_sleep: eqos-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
+ MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
+ MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
+ MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
+ MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
+ MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
+ MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
+ MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
+ MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
+ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
+ MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
+ MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__GPIO2_IO28 0x40000b9e
+ MX93_PAD_GPIO_IO29__GPIO2_IO29 0x40000b9e
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__SAI1_TX_BCLK 0x31e
+ MX93_PAD_SAI1_TXFS__SAI1_TX_SYNC 0x31e
+ MX93_PAD_SAI1_TXD0__SAI1_TX_DATA00 0x31e
+ MX93_PAD_SAI1_RXD0__SAI1_RX_DATA00 0x31e
+ MX93_PAD_I2C2_SDA__SAI1_RX_BCLK 0x31e
+ MX93_PAD_I2C2_SCL__SAI1_RX_SYNC 0x31e
+ MX93_PAD_UART2_RXD__SAI1_MCLK 0x31e
+ >;
+ };
+
+ pinctrl_sai1_sleep: sai1-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__GPIO1_IO12 0x31e
+ MX93_PAD_SAI1_TXFS__GPIO1_IO11 0x31e
+ MX93_PAD_SAI1_TXD0__GPIO1_IO13 0x31e
+ MX93_PAD_SAI1_RXD0__GPIO1_IO14 0x31e
+ MX93_PAD_UART2_RXD__GPIO1_IO06 0x31e
+ MX93_PAD_I2C2_SDA__GPIO1_IO03 0x31e
+ MX93_PAD_I2C2_SCL__GPIO1_IO02 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
+ MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x1582
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x40001382
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x40001382
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x40001382
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x40001382
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x40001382
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x4000138e
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x4000138e
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x4000138e
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x4000138e
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x4000138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x400013fe
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x400013fe
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x400013fe
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x400013fe
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x400013fe
+ >;
+ };
+
+ pinctrl_usdhc3_sleep: usdhc3-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__GPIO3_IO20 0x400
+ MX93_PAD_SD3_CMD__GPIO3_IO21 0x400
+ MX93_PAD_SD3_DATA0__GPIO3_IO22 0x400
+ MX93_PAD_SD3_DATA1__GPIO3_IO23 0x400
+ MX93_PAD_SD3_DATA2__GPIO3_IO24 0x400
+ MX93_PAD_SD3_DATA3__GPIO3_IO25 0x400
+ >;
+ };
+
+ pinctrl_usdhc3_wlan: usdhc3wlangrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
+ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x51e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini
In-Reply-To: <cover.1774601806.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX93 system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
-
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
2 files changed, 655 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2da6dc4f8a14..266eddd745c9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -487,6 +487,7 @@ imx93-tqma9352-mba91xxca-rgb-cdtech-dc44-dtbs := imx93-tqma9352-mba91xxca.dtb im
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-rgb-cdtech-dc44.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93w-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx943-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
new file mode 100644
index 000000000000..5513d3b148a2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
@@ -0,0 +1,654 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX93
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "imx93-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 on Sonata-Board";
+ compatible = "variscite,var-dart-mx93-sonata",
+ "variscite,var-dart-mx93",
+ "fsl,imx93";
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ i2c4 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial1 = &lpuart2;
+ serial2 = &lpuart3;
+ serial3 = &lpuart4;
+ serial4 = &lpuart5;
+ serial5 = &lpuart6;
+ serial6 = &lpuart7;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds_gpio>;
+
+ led-emmc {
+ gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ reg_vref_1v8: regulator-adc-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <20000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ethosu_mem: ethosu-region@88000000 {
+ compatible = "shared-dma-pool";
+ reusable;
+ reg = <0x0 0x88000000 0x0 0x8000000>;
+ };
+
+ vdev0vring0: vdev0vring0@87ee0000 {
+ reg = <0 0x87ee0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@87ee8000 {
+ reg = <0 0x87ee8000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@87ef0000 {
+ reg = <0 0x87ef0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@87ef8000 {
+ reg = <0 0x87ef8000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@2021e000 {
+ reg = <0 0x2021e000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@87f00000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87f00000 0 0x100000>;
+ no-map;
+ };
+
+ ele_reserved: ele-reserved@87de0000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87de0000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+/* Use external instead of internal RTC */
+&bbnsm_rtc {
+ status = "disabled";
+};
+
+&eqos {
+ mdio {
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+ };
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec>;
+ pinctrl-1 = <&pinctrl_fec_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&lpi2c1 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-names = "default", "sleep", "gpio";
+ scl-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&pinctrl_captouch>;
+ pinctrl-names = "default";
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+
+ /* USB Type-C Controller */
+ typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <29 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-0 = <&pinctrl_extcon>;
+ pinctrl-names = "default";
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ wakeup-source;
+ };
+};
+
+&lpi2c5 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&lpi2c7 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c7>;
+ pinctrl-1 = <&pinctrl_lpi2c7_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c7_gpio>;
+ scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ };
+};
+
+&lpspi8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi8>;
+ cs-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ /* CAN controller */
+ can0: can@0 {
+ compatible = "microchip,mcp251xfd";
+ reg = <0>;
+ clocks = <&clk40m>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+/* Console (J10) */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+/* Header (J12.4, J12.6) */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ status = "okay";
+};
+
+/* Header (J12.11, J12.13) */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ status = "okay";
+};
+
+&tpm3 {
+ pinctrl-0 = <&pinctrl_tpm3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ no-sdio;
+ no-mmc;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO03__GPIO2_IO03 0x31e
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x31e
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
+ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
+ MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
+ MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x37e
+ MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
+ MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
+ MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
+ MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
+ MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
+ MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
+ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_fec_sleep: fecsleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
+ MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
+ MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
+ MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
+ MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
+ MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
+ MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
+ MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
+ MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
+ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
+ MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
+ MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX93_PAD_PDM_CLK__CAN1_TX 0x139e
+ MX93_PAD_PDM_BIT_STREAM0__CAN1_RX 0x139e
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* GPIO Expanders shared IRQ */
+ MX93_PAD_PDM_BIT_STREAM1__GPIO1_IO10 0x31e
+ >;
+ };
+
+ pinctrl_leds_gpio: ledgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO11__GPIO2_IO11 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
+ MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c1_gpio: lpi2c1-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__GPIO1_IO00 0x31e
+ MX93_PAD_I2C1_SDA__GPIO1_IO01 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c5_gpio: lpi2c5-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__GPIO2_IO22 0x31e
+ MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c7: lpi2c7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__LPI2C7_SCL 0x40000b9e
+ MX93_PAD_GPIO_IO06__LPI2C7_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c7_gpio: lpi2c7-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__GPIO2_IO07 0x31e
+ MX93_PAD_GPIO_IO06__GPIO2_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpspi8: lpspi8grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__GPIO2_IO00 0x31e
+ MX93_PAD_GPIO_IO01__GPIO2_IO01 0x31e
+ MX93_PAD_GPIO_IO12__GPIO2_IO12 0x31e
+ MX93_PAD_GPIO_IO13__LPSPI8_SIN 0x31e
+ MX93_PAD_GPIO_IO14__LPSPI8_SOUT 0x31e
+ MX93_PAD_GPIO_IO15__LPSPI8_SCK 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x31e
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO02__GPIO2_IO02 0x31e
+ >;
+ };
+
+ pinctrl_tpm3: tpm3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO24__TPM3_CH3 0x51e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
+ MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO05__LPUART6_RX 0x31e
+ MX93_PAD_GPIO_IO04__LPUART6_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO09__LPUART7_RX 0x31e
+ MX93_PAD_GPIO_IO08__LPUART7_TX 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 3/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into CSI2 subnode
From: Laurent Pinchart @ 2026-03-27 9:09 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-4-marek.vasut+renesas@mailbox.org>
On Thu, Mar 26, 2026 at 05:24:00AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into CSI2 subnode to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi:49.10-55.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
> index 4d2b0655859ab..3feffa4f16a9a 100644
> --- a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
> @@ -46,7 +46,12 @@ &csi2 {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@0 {
> + reg = <0>;
> +
> csi2_in: endpoint {
> clock-lanes = <0>;
> data-lanes = <1 2>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into DU subnode
From: Laurent Pinchart @ 2026-03-27 9:10 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-5-marek.vasut+renesas@mailbox.org>
On Thu, Mar 26, 2026 at 05:24:01AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into DU subnode to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi:29.10-33.5: Warning (unit_address_vs_reg): /fragment@1/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
> index 36707576030d4..f5412578ee65f 100644
> --- a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
> @@ -26,7 +26,12 @@ &du {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@0 {
> + reg = <0>;
> +
> du_out_rgb: endpoint {
> remote-endpoint = <&adv7513_in>;
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v6] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: MidG971 @ 2026-03-27 9:11 UTC (permalink / raw)
To: heiko
Cc: linux-rockchip, linux-arm-kernel, devicetree, shawn.lin, jonas,
Midgy BALON
From: Midgy BALON <midgy971@gmail.com>
The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
This chip is currently modeled only as a fixed regulator
(vcc3v3_pi6c_03), with no clock output representation.
The PI6C20100 is a clock generator, not a power supply. Model it
properly as a gated-fixed-clock, following the pattern established
for the Rock 5 ITX and other boards with similar PCIe clock buffer
chips.
The gated-fixed-clock node references the regulator as its vdd-supply,
allowing the regulator to be enabled on demand. Remove the
regulator-always-on and regulator-boot-on properties from vcc3v3_pi6c_03
since the clock framework will manage the regulator lifecycle via
vdd-supply. The pcie3x2 node is updated to include the pipe and
reference clocks, matching the approach used in rk3588-rock-5-itx.dts.
Assisted-by: Claude:claude-3-opus
Signed-off-by: Midgy BALON <midgy971@gmail.com>
---
Changes since v5:
- Drop "(100MHz)" from clock node comment, already in clock-frequency (Jonas)
- Drop redundant comment before vcc3v3_pi6c_03 (Jonas)
- Remove regulator-always-on and regulator-boot-on from vcc3v3_pi6c_03 (Jonas)
- Drop Reviewed-by (patch has functional changes since v3 review)
Changes since v4:
- Fix From: line to match Signed-off-by (Heiko)
Changes since v3 [1]:
- Add Reviewed-by from Shawn Lin
Changes since v2 [2]:
- Fix AI attribution: use Assisted-by tag instead of Signed-off-by (Shawn)
- Add missing pipe clock (CLK_PCIE30X2_PIPE_DFT) to pcie3x2 clocks
override (Shawn, referencing David's patch [3])
Changes since v1 [4]:
- Drop phy-supply approach entirely (Jonas, Shawn)
- Model PI6C20100 as gated-fixed-clock instead
- Wire reference clock to pcie3x2 controller
- Follow pattern from rk3588-rock-5-itx.dts
[1] https://lore.kernel.org/linux-rockchip/20260304132957.684616-1-midgy971@gmail.com/
[2] https://lore.kernel.org/linux-rockchip/20260304132957.684616-1-midgy971@gmail.com/
[3] https://lore.kernel.org/linux-rockchip/d981fa84-bd05-ac9d-98ca-89ee47177829@rock-chips.com/T/#m6a8289609e6a60691d3c06358b6322c7aa5e43d1
[4] https://lore.kernel.org/linux-rockchip/20260213151452.535527-1-midgy971@gmail.com/
.../boot/dts/rockchip/rk3568-rock-3b.dts | 20 ++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
index 3d0c1ccfa..d7d85b090 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
@@ -56,7 +56,15 @@ led-0 {
};
};
- /* pi6c pcie clock generator */
+ /* PI6C20100 PCIe reference clock buffer */
+ pcie30_refclk: pcie-clock-generator {
+ compatible = "gated-fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "pcie30_refclk";
+ vdd-supply = <&vcc3v3_pi6c_03>;
+ };
+
vcc3v3_pi6c_03: regulator-3v3-vcc-pi6c-03 {
compatible = "regulator-fixed";
enable-active-high;
@@ -64,8 +72,6 @@ vcc3v3_pi6c_03: regulator-3v3-vcc-pi6c-03 {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pwren_h>;
regulator-name = "vcc3v3_pi6c_03";
- regulator-always-on;
- regulator-boot-on;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
startup-delay-us = <10000>;
@@ -545,6 +551,14 @@ &pcie30phy {
};
&pcie3x2 {
+ clocks = <&cru ACLK_PCIE30X2_MST>, <&cru ACLK_PCIE30X2_SLV>,
+ <&cru ACLK_PCIE30X2_DBI>, <&cru PCLK_PCIE30X2>,
+ <&cru CLK_PCIE30X2_AUX_NDFT>,
+ <&cru CLK_PCIE30X2_PIPE_DFT>,
+ <&pcie30_refclk>;
+ clock-names = "aclk_mst", "aclk_slv",
+ "aclk_dbi", "pclk", "aux",
+ "pipe", "ref";
pinctrl-names = "default";
pinctrl-0 = <&pcie30x2m1_pins>;
reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
--
2.30.2
^ permalink raw reply related
* Re: [PATCH net-next 03/15] net: stmmac: qcom-ethqos: eliminate configure_func
From: Simon Horman @ 2026-03-27 9:23 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <acV29ruRVy_fcwDq@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 06:12:06PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 06:04:53PM +0000, Simon Horman wrote:
> > On Tue, Mar 24, 2026 at 01:11:44PM +0000, Russell King (Oracle) wrote:
> > > Since ethqos_fix_mac_speed() is called via a function pointer, and only
> > > indirects via the configure_func function pointer, eliminate this
> > > unnecessary indirection.
> > >
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> >
> > ...
> >
> > > @@ -623,14 +627,6 @@ static void ethqos_configure_sgmii(struct qcom_ethqos *ethqos,
> > > ethqos_pcs_set_inband(ethqos, interface == PHY_INTERFACE_MODE_SGMII);
> > > }
> > >
> > > -static void ethqos_fix_mac_speed(void *priv, phy_interface_t interface,
> > > - int speed, unsigned int mode)
> > > -{
> > > - struct qcom_ethqos *ethqos = priv;
> > > -
> > > - ethqos->configure_func(ethqos, interface, speed);
> > > -}
> > > -
> > > static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
> > > {
> > > struct qcom_ethqos *ethqos = priv;
> >
> > Hi Russell,
> >
> > FYI, AI generated review reports that the comment in ethqos_clks_config()
> > that references ethqos_fix_mac_speed() should also be updated.
>
> Also already noted (yesterday).
>
> I do keep an eye on patchwork for my own patches - I have a firefox tab
> permanently open for my patches in patchwork:
>
> https://patchwork.kernel.org/project/netdevbpf/list/?submitter=165511
>
> Thanks anyway.
Thanks, and sorry if you told me this before.
I'll try to remember and not spam you with these things going forward.
^ permalink raw reply
* [PATCH] crypto: aspeed/hash: Use memcpy_from_sglist() in aspeed_ahash_dma_prepare()
From: Paul Louvel @ 2026-03-27 9:24 UTC (permalink / raw)
To: Neal Liu, Herbert Xu, David S. Miller, Joel Stanley,
Andrew Jeffery
Cc: Thomas Petazzoni, Paul Louvel, linux-aspeed, linux-crypto,
linux-arm-kernel, linux-kernel
Replace scatterwalk_map_and_copy() with memcpy_from_sglist() in
aspeed_ahash_dma_prepare(). The latter provides a simpler interface
without requiring a direction parameter, making the code easier to
read and less error-prone.
No functional change intended.
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
---
drivers/crypto/aspeed/aspeed-hace-hash.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/aspeed/aspeed-hace-hash.c b/drivers/crypto/aspeed/aspeed-hace-hash.c
index f8f37c9d5f3c..6f0d03cfbefc 100644
--- a/drivers/crypto/aspeed/aspeed-hace-hash.c
+++ b/drivers/crypto/aspeed/aspeed-hace-hash.c
@@ -182,8 +182,7 @@ static int aspeed_ahash_dma_prepare(struct aspeed_hace_dev *hace_dev)
final = true;
} else
length -= remain;
- scatterwalk_map_and_copy(hash_engine->ahash_src_addr, rctx->src_sg,
- rctx->offset, length, 0);
+ memcpy_from_sglist(hash_engine->ahash_src_addr, rctx->src_sg, rctx->offset, length);
aspeed_ahash_update_counter(rctx, length);
if (final)
length += aspeed_ahash_fill_padding(
--
2.53.0
^ permalink raw reply related
* [PATCH v1 0/3] arm64: dts: amlogic: meson-s4: enable RTC and IR for Khadas VIM1S
From: Nick Xie @ 2026-03-27 9:30 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel, Nick Xie
This series adds support for the Real Time Clock (RTC) on the Amlogic
Meson S4 (S905Y4) SoC and enables the hardware RTC and IR receiver on
the Khadas VIM1S board.
- Patch 1 adds the internal Virtual RTC (VRTC) controller node to the
Meson S4 SoC dtsi.
- Patch 2 enables the I2C-attached Haoyu Micro HYM8563 RTC on the
Khadas VIM1S board. It also sets up aliases to ensure the hardware
RTC is prioritized as rtc0 over the VRTC.
- Patch 3 configures the default keymap to "rc-khadas" to support the
official Khadas IR remote control.
Nick Xie (3):
arm64: dts: amlogic: meson-s4: add VRTC node
arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable HYM8563 RTC
arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: use rc-khadas
keymap
.../dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 5 +++++
2 files changed, 21 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v1 2/3] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable HYM8563 RTC
From: Nick Xie @ 2026-03-27 9:30 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260327093016.722095-1-nick@khadas.com>
The Khadas VIM1S board has an on-board Haoyu Micro HYM8563 Real Time
Clock (RTC) connected to the I2C1 bus.
Enable the I2C1 controller and add the RTC child node to support
hardware clock persistence.
Signed-off-by: Nick Xie <nick@khadas.com>
---
.../dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
index 792ab45c4c944..7314e0ab81da3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
@@ -20,6 +20,8 @@ aliases {
mmc0 = &emmc; /* eMMC */
mmc1 = &sd; /* SD card */
mmc2 = &sdio; /* SDIO */
+ rtc0 = &rtc;
+ rtc1 = &vrtc;
serial0 = &uart_b;
};
@@ -223,6 +225,19 @@ ðmac {
phy-mode = "rmii";
};
+&i2c1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins2>;
+ clock-frequency = <100000>;
+
+ rtc: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ };
+};
+
&ir {
status = "okay";
pinctrl-0 = <&remote_pins>;
--
2.34.1
^ permalink raw reply related
* [PATCH v1 3/3] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: use rc-khadas keymap
From: Nick Xie @ 2026-03-27 9:30 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260327093016.722095-1-nick@khadas.com>
The Khadas VIM1S board has an onboard IR receiver.
Configure the default keymap to "rc-khadas" to support the official
Khadas IR remote control.
Signed-off-by: Nick Xie <nick@khadas.com>
---
arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
index 7314e0ab81da3..99d5df71b9cd4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
@@ -242,6 +242,7 @@ &ir {
status = "okay";
pinctrl-0 = <&remote_pins>;
pinctrl-names = "default";
+ linux,rc-map-name = "rc-khadas";
};
&pwm_ef {
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/3] arm64: dts: amlogic: meson-s4: add VRTC node
From: Nick Xie @ 2026-03-27 9:30 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260327093016.722095-1-nick@khadas.com>
Add the Virtual RTC (VRTC) controller node to the Meson S4 SoC dtsi.
Signed-off-by: Nick Xie <nick@khadas.com>
---
arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
index 936a5c1353d15..2a6fbd5308362 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
@@ -59,6 +59,11 @@ psci {
method = "smc";
};
+ vrtc: rtc@fe010288 {
+ compatible = "amlogic,meson-vrtc";
+ reg = <0x0 0xfe010288 0x0 0x4>;
+ };
+
xtal: xtal-clk {
compatible = "fixed-clock";
clock-frequency = <24000000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v11 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Vijayanand Jitta @ 2026-03-27 9:35 UTC (permalink / raw)
To: Bjorn Helgaas, Richard Zhu, Lucas Stach
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Krzysztof Wilczyński, Manivannan Sadhasivam,
Bjorn Helgaas, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Dmitry Baryshkov, Konrad Dybcio,
Bjorn Andersson, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Prakash Gupta, Vikash Garodia, linux-kernel, iommu,
linux-arm-kernel, devicetree, linux-pci, imx, xen-devel,
linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260326161957.GA1324845@bhelgaas>
On 3/26/2026 9:49 PM, Bjorn Helgaas wrote:
> [cc->to: Richard, Lucas for pci-imx6.c question]
>
> On Wed, Mar 25, 2026 at 04:38:23PM +0530, Vijayanand Jitta wrote:
>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>
>> Change of_map_id() to take a pointer to struct of_phandle_args
>> instead of passing target device node and translated IDs separately.
>> Update all callers accordingly.
>>
>> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
>> to separate the filter input from the output. Previously, the target
>> parameter served dual purpose: as an input filter (if non-NULL, only
>> match entries targeting that node) and as an output (receiving the
>> matched node with a reference held). Now filter_np is the explicit
>> input filter and arg->np is the pure output.
>>
>> Previously, of_map_id() would call of_node_put() on the matched node
>> when a filter was provided, making reference ownership inconsistent.
>> Remove this internal of_node_put() call so that of_map_id() now always
>> transfers ownership of the matched node reference to the caller via
>> arg->np. Callers are now consistently responsible for releasing this
>> reference with of_node_put(arg->np) when done.
>> ...
>
> Not actually part of *this* patch, and AFAICS this patch is correct
> as-is, but is it necessary to have different logic around
> of_node_put() for imx_pcie_add_lut_by_rid() and
> apple_pcie_enable_device()?
>
Thanks for the review comments. Right, there is no need to have different
logic, I will update imx_pcie_add_lut_by_rid() in v12 so that of_node_put()
would be called unconditionally.
>> +++ b/drivers/pci/controller/dwc/pci-imx6.c
>> @@ -1137,6 +1137,8 @@ static void imx_pcie_remove_lut(struct imx_pcie *imx_pcie, u16 rid)
>>
>> static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
>> {
>> + struct of_phandle_args iommu_spec = {};
>> + struct of_phandle_args msi_spec = {};
>> struct device *dev = imx_pcie->pci->dev;
>> struct device_node *target;
>> u32 sid_i, sid_m;
>> @@ -1144,7 +1146,12 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
>> u32 sid = 0;
>>
>> target = NULL;
>> - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
>> + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec);
>> + if (!err_i) {
>> + target = iommu_spec.np;
>> + sid_i = iommu_spec.args[0];
>> + }
>> +
>> if (target) {
>> of_node_put(target);
>
> Here it's conditional on "target" even though of_node_put() checks
> internally for non-NULL, so it would be safe without the conditional
> here.
>
Agreed, here of_node_put can be called unconditionally , will fix it in v12.
>> } else {
>> @@ -1156,8 +1163,11 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
>> err_i = -EINVAL;
>> }
>>
>> - target = NULL;
>> - err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
>> + err_m = of_map_msi_id(dev->of_node, rid, NULL, &msi_spec);
>> + if (!err_m) {
>> + target = msi_spec.np;
>> + sid_m = msi_spec.args[0];
>> + }
>>
>> /*
>> * err_m target
>
> And here (outside the diff context) we also call of_node_put()
> conditionally:
>
> ...
> else if (target)
> of_node_put(target);
>
Agreed, same as above.
>> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
>> index a0937b7b3c4d..c2cffc0659f4 100644
>> --- a/drivers/pci/controller/pcie-apple.c
>> +++ b/drivers/pci/controller/pcie-apple.c
>> @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
>> {
>> u32 sid, rid = pci_dev_id(pdev);
>> struct apple_pcie_port *port;
>> + struct of_phandle_args iommu_spec = {};
>> int idx, err;
>>
>> port = apple_pcie_get_port(pdev);
>> @@ -764,10 +765,12 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
>> dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
>> pci_name(pdev->bus->self), port->idx);
>>
>> - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
>> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec);
>> if (err)
>> return err;
>>
>> + of_node_put(iommu_spec.np);
>
> Here we call of_node_put() unconditionally.
>
> I think it would be much nicer if imx_pcie_add_lut_by_rid() used the
> same style as apple_pcie_enable_device() and did the of_node_put()
> unconditionally. That would untangle the function a bit and make it
> easier to analyze.
>
Sure, as mentioned above will align imx_pcie_add_lut_by_rid() and
apple_pcie_enable_device().
Thanks,
Vijay
>> + sid = iommu_spec.args[0];
>> mutex_lock(&port->pcie->lock);
>>
>> idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0);
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
From: Konrad Dybcio @ 2026-03-27 9:37 UTC (permalink / raw)
To: Canfeng Zhuang, konradybcio, andersson
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-2-canfeng.zhuang@oss.qualcomm.com>
On 3/27/26 9:31 AM, Canfeng Zhuang wrote:
> The lemans-evk mezzanine connector supports a robot expansion board that
> requires UART0, which is currently disabled. This prevents the expansion
> board from exchanging data and control commands.
>
> Enable UART0 and assign the serial2 alias to provide stable device
> enumeration for the expansion board.
>
> Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
From: Konrad Dybcio @ 2026-03-27 9:37 UTC (permalink / raw)
To: Canfeng Zhuang, konradybcio, andersson
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-3-canfeng.zhuang@oss.qualcomm.com>
On 3/27/26 9:31 AM, Canfeng Zhuang wrote:
> The monaco-evk mezzanine connector supports a robot expansion board that
> requires UART6, which is currently disabled. This prevents the expansion
> board from exchanging data and control commands.
>
> Enable UART6 and assign the serial2 alias to provide stable device
> enumeration for the expansion board.
>
> Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/3] drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag
From: Chen-Yu Tsai @ 2026-03-27 9:38 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maarten Lankhorst, Maxime Ripard, David Airlie, Simona Vetter,
Rob Herring, dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <243dbc45-cb11-4dfe-b8d1-e08f1b5f73b6@suse.de>
On Fri, Mar 27, 2026 at 3:21 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 26.03.26 um 11:01 schrieb Chen-Yu Tsai:
> > From: Rob Herring <robh@kernel.org>
> >
> > Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> > drm_mode_create_dumb. This flag is for internal kernel use to indicate
> > if dumb buffer allocation needs a kernel mapping. This is needed only for
> > GEM DMA where creating a kernel mapping or not has to be decided at
> > allocation time because creating a mapping on demand (with vmap()) is not
> > guaranteed to work.
>
> I still don't understand what you're trying to achieve. As I pointed
> out, ever driver's memory manager potentially requires a vmap. Passing
> around flags will not solve that problem. If vmap is not possible, the
> driver should not provide the vmap callbacks in the first place.
I'm trying to convert the Rockchip and Exynos drivers to the GEM DMA
helpers. Both have their reasons for not using the helpers, one of them
being that the DRM device is not the DMA device. This is already fixed
by my other series. Both drivers also set DMA_ATTR_NO_KERNEL_MAPPING
for buffer allocations other than the one used by fb_helper.
Exynos's GEM implementation also sets extra DMA attributes at the
allocation phase for their custom GEM create ioctl. But otherwise
exynos is just reimplementing all the GEM DMA helpers in almost
identical fashion. And to your point, exynos does not provide the
vmap callback.
Rockchip's GEM implementation splits the code path between DMA and
IOMMU usage as it needs to attach and detach the DMA device from the
IOMMU domain on the fly. This predates the DMA IOMMU framework. This
GEM implementation provides the vmap callback, which will fail for
direct DMA allocations without the kernel mapping.
There's also something fishy about Rockchip's DRM driver. It's using
fbdev-dma, even though it's not based on the GEM DMA helpers or even
drm_gem_dma_object.
As you are against changing the existing *_dumb_create() interface,
I will look into reusing drm_gem_dma_object with driver-specific
functions. I believe I will need to keep patch 2 adding dma_attrs
though. Would that be acceptable?
Once again, thank you for your patience.
ChenYu
> Best regards
> Thomas
>
> >
> > Several drivers are using reimplementing the GEM DMA helpers because
> > they distinguish between kernel and userspace allocations to create a
> > kernel mapping or not. Adding a flag allows migrating these drivers
> > to the helpers while preserving their existing behavior. These include
> > exynos, rockchip, and previously mediatek.
> >
> > Update the callers of drm_mode_dumb_create() to set
> > drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> > be set to anything by userspace, but is unused within the kernel. Let's
> > force flags to zero (no kernel mapping) for userspace callers by default.
> > For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> > can override this as needed.
> >
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > [wenst@chromium.org: Emit warning (once) if args->flags is not zero]
> > [wenst@chromium.org: Moved flag def. to include/drm/drm_dumb_buffers.h]
> > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> > ---
> > Changes since v2:
> > - Switched to drm_warn_once()
> > - Moved flag definition from include/uapi/ to include/drm/drm_dumb_buffers.h
> > - Reworded commit message
> >
> > Changes since v1:
> > - Emit warning if args->flags is not zero
> > ---
> > drivers/gpu/drm/drm_client.c | 2 ++
> > drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
> > include/drm/drm_dumb_buffers.h | 3 +++
> > 3 files changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > index 46c465bce98c..3d3e61823cc1 100644
> > --- a/drivers/gpu/drm/drm_client.c
> > +++ b/drivers/gpu/drm/drm_client.c
> > @@ -14,6 +14,7 @@
> > #include <drm/drm_client_event.h>
> > #include <drm/drm_device.h>
> > #include <drm/drm_drv.h>
> > +#include <drm/drm_dumb_buffers.h>
> > #include <drm/drm_file.h>
> > #include <drm/drm_fourcc.h>
> > #include <drm/drm_framebuffer.h>
> > @@ -404,6 +405,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
> > dumb_args.width = width;
> > dumb_args.height = height;
> > dumb_args.bpp = drm_format_info_bpp(info, 0);
> > + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> > ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> > if (ret)
> > return ERR_PTR(ret);
> > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> > index e2b62e5fb891..60f4c2d08641 100644
> > --- a/drivers/gpu/drm/drm_dumb_buffers.c
> > +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> > @@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> > struct drm_mode_create_dumb *args = data;
> > int err;
> >
> > + if (args->flags)
> > + drm_warn_once(dev, "drm_mode_create_dumb.flags is not zero.\n");
> > + args->flags = 0;
> > +
> > err = drm_mode_create_dumb(dev, args, file_priv);
> > if (err) {
> > args->handle = 0;
> > diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
> > index 1f3a8236fb3d..4657e44533f4 100644
> > --- a/include/drm/drm_dumb_buffers.h
> > +++ b/include/drm/drm_dumb_buffers.h
> > @@ -6,6 +6,9 @@
> > struct drm_device;
> > struct drm_mode_create_dumb;
> >
> > +/* drm_mode_create_dumb flags for internal use */
> > +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0)
> > +
> > int drm_mode_size_dumb(struct drm_device *dev,
> > struct drm_mode_create_dumb *args,
> > unsigned long hw_pitch_align,
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Grab flow_offload_mutex running airoha_register_gdm_devices()
From: Lorenzo Bianconi @ 2026-03-27 8:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260326200605.39222917@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Mar 26, Jakub Kicinski wrote:
> On Tue, 24 Mar 2026 17:54:45 +0100 Lorenzo Bianconi wrote:
> > Netfilter flowtable can theoretically try offload flower rules as soon
> > as a net-device is registered while not all the other ones are
> > registered/initialized, triggering a possible NULL pointer dereferencing
> > of qdma pointer in airoha_ppe_set_cpu_port routine. In order to avoid any
> > possible race, grab the flow_offload_mutex running
> > airoha_register_gdm_devices().
>
> Sashiko says this causes a lock ordering issue:
> https://sashiko.dev/#/patchset/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
Ack, right. Thx for pointing this issue out. I will work on a different
solution.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next 0/2] net: stmmac: fix and clean up TSO/GSO support
From: Russell King (Oracle) @ 2026-03-27 9:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni
This series:
1. moves setting priv->tso from stmmac_fix_features() to
stmmac_set_features() as fix_features is not supposed to change
driver state.
2. simplifies the TSO/GSP test in stmmac_xmit() to simply check if the
skbuff is a GSO buffer, and whether the gso_type is one that we
should handle.
A previous version of patch 1 was posted in February:
https://lore.kernel.org/r/E1vuU3X-0000000Ae9G-1Er8@rmk-PC.armlinux.org.uk/
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 38 +++++++++++------------
2 files changed, 21 insertions(+), 20 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH net-next 1/2] net: stmmac: fix .ndo_fix_features()
From: Russell King (Oracle) @ 2026-03-27 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni
In-Reply-To: <acZQaDeCoib5S5UA@shell.armlinux.org.uk>
netdev features documentation requires that .ndo_fix_features() is
stateless: it shouldn't modify driver state. Yet, stmmac_fix_features()
does exactly that, changing whether GSO frames are processed by the
driver.
Move this code to stmmac_set_features() instead, which is the correct
place for it. We don't need to check whether TSO is supported; this
is already handled via the setup of netdev->hw_features, and we are
guaranteed that if netdev->hw_features indicates that a feature is
not supported, .ndo_set_features() won't be called with it set.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9b6b49331639..8203d6845b00 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6068,14 +6068,6 @@ static netdev_features_t stmmac_fix_features(struct net_device *dev,
if (priv->plat->bugged_jumbo && (dev->mtu > ETH_DATA_LEN))
features &= ~NETIF_F_CSUM_MASK;
- /* Disable tso if asked by ethtool */
- if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
- if (features & NETIF_F_TSO)
- priv->tso = true;
- else
- priv->tso = false;
- }
-
return features;
}
@@ -6102,6 +6094,8 @@ static int stmmac_set_features(struct net_device *netdev,
stmmac_enable_sph(priv, priv->ioaddr, sph_en, chan);
}
+ priv->tso = !!(features & NETIF_F_TSO);
+
if (features & NETIF_F_HW_VLAN_CTAG_RX)
priv->hw->hw_vlan_en = true;
else
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 2/2] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
From: Russell King (Oracle) @ 2026-03-27 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni
In-Reply-To: <acZQaDeCoib5S5UA@shell.armlinux.org.uk>
The test in stmmac_xmit() to see whether we should pass the skbuff to
stmmac_tso_xmit() is more complex than it needs to be. This test can
be simplified by storing the mask of GSO types that we will pass, and
setting it according to the enabled features.
Note that "tso" is a mis-nomer since commit b776620651a1 ("net:
stmmac: Implement UDP Segmentation Offload"). Also note that this
commit controls both via the TSO feature. We preserve this behaviour
in this commit.
Also, this commit unconditionally accessed skb_shinfo(skb)->gso_type
for all frames, even when skb_is_gso() was false. This access is
eliminated.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 30 +++++++++++--------
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 919a93a52390..8ba8f03e1ce0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -265,8 +265,9 @@ struct stmmac_priv {
u32 rx_coal_frames[MTL_MAX_RX_QUEUES];
int hwts_tx_en;
+ /* skb_shinfo(skb)->gso_type types that we handle */
+ unsigned int gso_enabled_types;
bool tx_path_in_lpi_mode;
- bool tso;
bool sph_active;
bool sph_capable;
u32 sarc_type;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8203d6845b00..d3e8d793af52 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3700,7 +3700,7 @@ static int stmmac_hw_setup(struct net_device *dev)
stmmac_set_rings_length(priv);
/* Enable TSO */
- if (priv->tso) {
+ if (priv->gso_enabled_types) {
for (chan = 0; chan < tx_cnt; chan++) {
struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[chan];
@@ -4675,7 +4675,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
u32 queue = skb_get_queue_mapping(skb);
int nfrags = skb_shinfo(skb)->nr_frags;
unsigned int first_entry, tx_packets;
- int gso = skb_shinfo(skb)->gso_type;
struct stmmac_txq_stats *txq_stats;
struct dma_desc *desc, *first_desc;
struct stmmac_tx_queue *tx_q;
@@ -4687,14 +4686,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
if (priv->tx_path_in_lpi_mode && priv->eee_sw_timer_en)
stmmac_stop_sw_lpi(priv);
- /* Manage oversized TCP frames for GMAC4 device */
- if (skb_is_gso(skb) && priv->tso) {
- if (gso & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
- return stmmac_tso_xmit(skb, dev);
- if (priv->plat->core_type == DWMAC_CORE_GMAC4 &&
- (gso & SKB_GSO_UDP_L4))
- return stmmac_tso_xmit(skb, dev);
- }
+ if (skb_is_gso(skb) &&
+ skb_shinfo(skb)->gso_type & priv->gso_enabled_types)
+ return stmmac_tso_xmit(skb, dev);
if (priv->est && priv->est->enable &&
priv->est->max_sdu[queue]) {
@@ -6049,6 +6043,18 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+static void stmmac_set_gso_types(struct stmmac_priv *priv, bool tso)
+{
+ if (!tso) {
+ priv->gso_enabled_types = 0;
+ } else {
+ /* Manage oversized TCP frames for GMAC4 device */
+ priv->gso_enabled_types = SKB_GSO_TCPV4 | SKB_GSO_TCPV6;
+ if (priv->plat->core_type == DWMAC_CORE_GMAC4)
+ priv->gso_enabled_types |= SKB_GSO_UDP_L4;
+ }
+}
+
static netdev_features_t stmmac_fix_features(struct net_device *dev,
netdev_features_t features)
{
@@ -6094,7 +6100,7 @@ static int stmmac_set_features(struct net_device *netdev,
stmmac_enable_sph(priv, priv->ioaddr, sph_en, chan);
}
- priv->tso = !!(features & NETIF_F_TSO);
+ stmmac_set_gso_types(priv, features & NETIF_F_TSO);
if (features & NETIF_F_HW_VLAN_CTAG_RX)
priv->hw->hw_vlan_en = true;
@@ -7828,7 +7834,7 @@ static int __stmmac_dvr_probe(struct device *device,
ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
if (priv->plat->core_type == DWMAC_CORE_GMAC4)
ndev->hw_features |= NETIF_F_GSO_UDP_L4;
- priv->tso = true;
+ stmmac_set_gso_types(priv, true);
dev_info(priv->device, "TSO feature enabled\n");
}
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Daniel Baluta @ 2026-03-27 9:45 UTC (permalink / raw)
To: Peng Fan (OSS), Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-2-a547a3588730@nxp.com>
On 3/27/26 04:42, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Cortex-M[7,33] processors use a fixed reset vector table format:
>
> 0x00 Initial SP value
> 0x04 Reset vector
> 0x08 NMI
> 0x0C ...
> ...
> IRQ[n]
>
> In ELF images, the corresponding layout is:
>
> reset_vectors: --> hardware reset address
> .word __stack_end__
> .word Reset_Handler
> .word NMI_Handler
> .word HardFault_Handler
> ...
> .word UART_IRQHandler
> .word SPI_IRQHandler
> ...
>
> Reset_Handler: --> ELF entry point address
> ...
>
> The hardware fetches the first two words from reset_vectors and populates
> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> Reset_Handler.
>
> However, the ELF entry point does not always match the hardware reset
> address. For example, on i.MX94 CM33S:
>
> ELF entry point: 0x0ffc211d
> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>
> To derive the correct hardware reset address, the unused lower bits must
> be masked off. The boot code should apply a SoC-specific mask before
> programming the reset address registers, e.g.:
>
> reset_address = entry & reset_vector_mask
>
> Current driver always programs the reset vector as 0. But i.MX94 CM33S's
> default reset base is 0x0ffc0000, so the correct reset vector must be
> passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
>
> rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
> hardware reset vector address. To derive the proper reset vector, this
> patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
> point using the SoC‑specific 'reset_vector_mask'. The resulting reset
> vector address is then passed to the SM CPU/LMM reset vector API calls.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox