* [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Stefano Radaelli @ 2026-04-08 17:39 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, Markus Niebel,
Maud Spierings, Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <cover.1775669847.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite VAR-SOM-MX91 system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX91 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-91/var-som-mx91/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
.../boot/dts/freescale/imx91-var-som.dtsi | 456 ++++++++++++++++++
1 file changed, 456 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-som.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx91-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx91-var-som.dtsi
new file mode 100644
index 000000000000..b30a0d8a81ba
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-var-som.dtsi
@@ -0,0 +1,456 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite VAR-SOM-MX91
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-91/var-som-mx91/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include "imx91.dtsi"
+
+/{
+ model = "Variscite VAR-SOM-MX91 module";
+ compatible = "variscite,var-som-mx91", "fsl,imx91";
+
+ usdhc3_pwrseq: mmc-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 */
+ };
+
+ sound {
+ 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,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";
+ simple-audio-card,mclk-fs = <256>;
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+ };
+};
+
+&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>;
+ eee-broken-1000t;
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <15000>;
+ 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>;
+ sda-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ 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;
+ };
+ };
+ };
+
+ 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>;
+ };
+};
+
+&lpspi8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi8>;
+ cs-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+/* BT module */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart5>, <&pinctrl_bluetooth>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&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>;
+ 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>;
+ bus-width = <4>;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ wakeup-source;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bluetooth: bluetoothgrp {
+ fsl,pins = <
+ MX91_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
+ >;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDC__ENET1_MDC 0x57e
+ MX91_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX91_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX91_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX91_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX91_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX91_PAD_ENET1_RXC__ENET_QOS_RGMII_RXC 0x5fe
+ MX91_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX91_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX91_PAD_ENET1_TD1__ENET1_RGMII_TD1 0x57e
+ MX91_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX91_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX91_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x5fe
+ MX91_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ MX91_PAD_UART2_TXD__GPIO1_IO7 0x51e
+ >;
+ };
+
+ pinctrl_eqos_sleep: eqos-sleepgrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDC__GPIO4_IO0 0x31e
+ MX91_PAD_ENET1_MDIO__GPIO4_IO1 0x31e
+ MX91_PAD_ENET1_RD0__GPIO4_IO10 0x31e
+ MX91_PAD_ENET1_RD1__GPIO4_IO11 0x31e
+ MX91_PAD_ENET1_RD2__GPIO4_IO12 0x31e
+ MX91_PAD_ENET1_RD3__GPIO4_IO13 0x31e
+ MX91_PAD_ENET1_RXC__GPIO4_IO9 0x31e
+ MX91_PAD_ENET1_RX_CTL__GPIO4_IO8 0x31e
+ MX91_PAD_ENET1_TD0__GPIO4_IO5 0x31e
+ MX91_PAD_ENET1_TD1__GPIO4_IO4 0x31e
+ MX91_PAD_ENET1_TD2__GPIO4_IO3 0x31e
+ MX91_PAD_ENET1_TD3__GPIO4_IO2 0x31e
+ MX91_PAD_ENET1_TXC__GPIO4_IO7 0x31e
+ MX91_PAD_ENET1_TX_CTL__GPIO4_IO6 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX91_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c3_gpio: lpi2c3-gpiogrp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO28__GPIO2_IO28 0x40000b9e
+ MX91_PAD_GPIO_IO29__GPIO2_IO29 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpspi8: lpspi8grp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO12__GPIO2_IO12 0x31e
+ MX91_PAD_GPIO_IO13__LPSPI8_SIN 0x31e
+ MX91_PAD_GPIO_IO14__LPSPI8_SOUT 0x31e
+ MX91_PAD_GPIO_IO15__LPSPI8_SCK 0x31e
+ >;
+ };
+
+ pinctrl_lpuart5: lpuart5grp {
+ fsl,pins = <
+ MX91_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ MX91_PAD_DAP_TDI__LPUART5_RX 0x31e
+ MX91_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ MX91_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ MX91_PAD_SAI1_TXC__SAI1_TX_BCLK 0x31e
+ MX91_PAD_SAI1_TXFS__SAI1_TX_SYNC 0x31e
+ MX91_PAD_SAI1_TXD0__SAI1_TX_DATA0 0x31e
+ MX91_PAD_SAI1_RXD0__SAI1_RX_DATA0 0x31e
+ MX91_PAD_I2C2_SDA__SAI1_RX_BCLK 0x31e
+ MX91_PAD_I2C2_SCL__SAI1_RX_SYNC 0x31e
+ MX91_PAD_UART2_RXD__SAI1_MCLK 0x31e
+ >;
+ };
+
+ pinctrl_sai1_sleep: sai1-sleepgrp {
+ fsl,pins = <
+ MX91_PAD_SAI1_TXC__GPIO1_IO12 0x31e
+ MX91_PAD_SAI1_TXFS__GPIO1_IO11 0x31e
+ MX91_PAD_SAI1_TXD0__GPIO1_IO13 0x31e
+ MX91_PAD_SAI1_RXD0__GPIO1_IO14 0x31e
+ MX91_PAD_UART2_RXD__GPIO1_IO6 0x31e
+ MX91_PAD_I2C2_SDA__GPIO1_IO3 0x31e
+ MX91_PAD_I2C2_SCL__GPIO1_IO2 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX91_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX91_PAD_SD1_CMD__USDHC1_CMD 0x1382
+ MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x1382
+ MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x1382
+ MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x1382
+ MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x1382
+ MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x1382
+ MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x1382
+ MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x1382
+ MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x1382
+ MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX91_PAD_SD1_CMD__USDHC1_CMD 0x138e
+ MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x138e
+ MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x138e
+ MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x138e
+ MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x138e
+ MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x138e
+ MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x138e
+ MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x138e
+ MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x138e
+ MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX91_PAD_SD1_CMD__USDHC1_CMD 0x13fe
+ MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe
+ MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe
+ MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe
+ MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe
+ MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe
+ MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe
+ MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe
+ MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe
+ MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX91_PAD_SD3_CLK__USDHC3_CLK 0x1582
+ MX91_PAD_SD3_CMD__USDHC3_CMD 0x1382
+ MX91_PAD_SD3_DATA0__USDHC3_DATA0 0x1382
+ MX91_PAD_SD3_DATA1__USDHC3_DATA1 0x1382
+ MX91_PAD_SD3_DATA2__USDHC3_DATA2 0x1382
+ MX91_PAD_SD3_DATA3__USDHC3_DATA3 0x1382
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ MX91_PAD_SD3_CMD__USDHC3_CMD 0x138e
+ MX91_PAD_SD3_DATA0__USDHC3_DATA0 0x138e
+ MX91_PAD_SD3_DATA1__USDHC3_DATA1 0x138e
+ MX91_PAD_SD3_DATA2__USDHC3_DATA2 0x138e
+ MX91_PAD_SD3_DATA3__USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ MX91_PAD_SD3_CMD__USDHC3_CMD 0x13fe
+ MX91_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe
+ MX91_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe
+ MX91_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe
+ MX91_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe
+ >;
+ };
+
+ pinctrl_usdhc3_sleep: usdhc3-sleepgrp {
+ fsl,pins = <
+ MX91_PAD_SD3_CLK__GPIO3_IO20 0x31e
+ MX91_PAD_SD3_CMD__GPIO3_IO21 0x31e
+ MX91_PAD_SD3_DATA0__GPIO3_IO22 0x31e
+ MX91_PAD_SD3_DATA1__GPIO3_IO23 0x31e
+ MX91_PAD_SD3_DATA2__GPIO3_IO24 0x31e
+ MX91_PAD_SD3_DATA3__GPIO3_IO25 0x31e
+ >;
+ };
+
+ pinctrl_usdhc3_wlan: usdhc3-wlangrp {
+ fsl,pins = <
+ MX91_PAD_ENET2_MDC__GPIO4_IO14 0x51e
+ MX91_PAD_SD2_RESET_B__GPIO3_IO7 0x51e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX91 Boards
From: Stefano Radaelli @ 2026-04-08 17:39 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, Markus Niebel,
Maud Spierings, Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <cover.1775669847.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite VAR-SOM-MX91 SoM and Symphony
development carrier Board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
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 b29362cb650f..3c31e5167348 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1614,6 +1614,12 @@ properties:
- const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM
- const: fsl,imx91
+ - description: Variscite VAR-SOM-MX91 based boards
+ items:
+ - const: variscite,var-som-mx91-symphony # Variscite VAR-SOM-MX91 on Symphony
+ - const: variscite,var-som-mx91 # Variscite VAR-SOM-MX91
+ - const: fsl,imx91
+
- description: Variscite DART-MX93 based boards
items:
- const: variscite,var-dart-mx93-sonata # Variscite DART-MX93 on Sonata Development Board
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/3] Add support for Variscite VAR-SOM-MX91 and Symphony board
From: Stefano Radaelli @ 2026-04-08 17:39 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, Markus Niebel,
Maud Spierings, Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
This patch series adds support for the Variscite VAR-SOM-MX91 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.
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite VAR-SOM-MX91 Boards
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
arm64: dts: imx91-var-som: Add support for Variscite Symphony board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx91-var-som-symphony.dts | 527 ++++++++++++++++++
.../boot/dts/freescale/imx91-var-som.dtsi | 456 +++++++++++++++
4 files changed, 990 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-som-symphony.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-som.dtsi
base-commit: 52bd553667e68b91ae6bb686ebddb66e539c7798
prerequisite-patch-id: 6aed59e9105465c7ff1c01475972351600be1526
--
2.47.3
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg via B4 Relay @ 2026-04-08 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
In-Reply-To: <20260408-synaptics-rmi4-dt-v1-0-2d32bacce673@ixit.cz>
From: David Heidelberg <david@ixit.cz>
We know the driver is reporting s3706b, introduce the compatible so we
can more easily introduce quirks for weird touchscreen replacements in
followup series.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 6b7378cf4d493..148164d456a5a 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -480,7 +480,7 @@ &i2c12 {
clock-frequency = <400000>;
synaptics-rmi4-i2c@20 {
- compatible = "syna,rmi4-i2c";
+ compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
reg = <0x20>;
#address-cells = <1>;
#size-cells = <0>;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg via B4 Relay @ 2026-04-08 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
In-Reply-To: <20260408-synaptics-rmi4-dt-v1-0-2d32bacce673@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Mostly irrelevant for authentic Synaptics touchscreens, but very important
for applying workarounds to cheap TS knockoffs.
These knockoffs work well with the downstream driver, and since the user
has no way to distinguish them, later in this patch set, we introduce
workarounds to ensure they function as well as possible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index 8685ef4481f4a..fb4804ac3544d 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -18,9 +18,14 @@ description: |
properties:
compatible:
- enum:
- - syna,rmi4-i2c
- - syna,rmi4-spi
+ oneOf:
+ - enum:
+ - syna,rmi4-i2c
+ - syna,rmi4-spi
+ - items:
+ - enum:
+ - syna,rmi4-s3706b # OnePlus 6/6T
+ - const: syna,rmi4-i2c
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] Introduce OnePlus 6/6T touchscreen compatible
From: David Heidelberg via B4 Relay @ 2026-04-08 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
Mostly related to the
https://codeberg.org/sdm845/linux/commits/branch/b4/synaptics-rmi4
series, but independent on other changes which I trying to upstream for
more than one year.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
David Heidelberg (2):
dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-synaptics-rmi4-dt-8aebf31790dc
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH 04/13] clk: amlogic: Add basic clock driver
From: Jerome Brunet @ 2026-04-08 17:34 UTC (permalink / raw)
To: Chuan Liu
Cc: Krzysztof Kozlowski, Neil Armstrong, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-amlogic, linux-clk, devicetree, linux-kernel,
Martin Blumenstingl
In-Reply-To: <76ef272c-e09a-400e-b381-82d7f29760ca@amlogic.com>
On mer. 08 avril 2026 at 22:32, Chuan Liu <chuan.liu@amlogic.com> wrote:
> Hi Krzysztof (& ALL),
> Thanks for review.
>
> On 2/9/2026 9:17 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>> On 09/02/2026 06:48, Chuan Liu via B4 Relay wrote:
>>> From: Chuan Liu <chuan.liu@amlogic.com>
>>>
>>> Implement core clock driver for Amlogic SoC platforms, supporting
>> So how did all existing Amlogic SoC platforms work so far without basic
>> clock driver? Really, how?
>> You are suppose to grow existing code, not add your completely new
>> "basic" driver just because you have it that way in downstream.
>>
>
> Firstly, apologies for the delayed response. I had intended to consolidate
> the V1 review feedback and come back with a clearer plan for V2 changes. In
> the meantime, Martin has provided many detailed and valuable suggestions -
> much appreciated.
>
> The original goal of optimizing the HW based on A9 and introducing a new
> clock driver is to reduce unnecessary complexity in the driver. On A9, we
> optimized the Clock/PLL controller HW to simplify driver performance,
> complexity, memory footprint, and reusability. Improvements on the HW side
> can also help drive corresponding enhancements in the driver:
> - Performance: Encapsulates sub-clock functions, reducing call paths
> - Complexity: Standardized register bits eliminate a large number of
> bit definitions (~1/3 of original code is defined register bit [1])
> - Memory: Object-oriented design avoids copy/paste for repeated clocks
> - Reusability: Same controller works across SoCs without driver
> changes (or with minimal changes)
>
> The old meson driver required compromises to unify legacy controller
> characteristics and driver styles. On A9, we want a fresh start.
I thought I was clear on the cover letter, apparently not.
*This is not going to happen*
You've provided no technical justification for such "a fresh start".
There no reason for A9 HW to be supported by different drivers than the
rest of the Amlogic SoC when it is quite clear it can fit with the
current drivers.
At lot of work by a lot of different people has gone into stabilizing
and maintaing the current driver. That's valuable too. If you are not
happy with current level of "performance" then make your case with
actual numbers and submit changes against the current drivers, making
improvement available to all supported SoCs. That's how upstream works.
>
>> Best regards,
>> Krzysztof
--
Jerome
^ permalink raw reply
* Re: [PATCH v4 0/3] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
From: Jeff Johnson @ 2026-04-08 17:27 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
David Heidelberg
Cc: Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <177566850912.1322920.17816533595535960130.b4-ty@oss.qualcomm.com>
On 4/8/2026 10:15 AM, Jeff Johnson wrote:
>
> On Wed, 25 Mar 2026 18:57:14 +0100, David Heidelberg wrote:
>> This quirk is used so far used on:
>> - LG G7 ThinQ
>> - Xiaomi Poco F1
>>
>> I'm resending it after ~ 4 years since initial send due to Snapdragon
>> 845 being one of best supported platform for mobile phones running
>> Linux, so it would be shame to not have shiny support.
>>
>> [...]
>
> Applied, thanks!
>
> [1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
> commit: 3d7640b6c371a1795e6d9580695d20caf16be9a4
> [2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
> (no commit info)
> [3/3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Enable ath10k host-cap skip quirk
> (no commit info)
>
> Best regards,
Sigh, I did NOT take v4 of this series.
I did take the 1-2/3 subset of v5.
Note the self: actually look at the output from 'b4 ty --dry-run' before
removing the --dry-run
/jeff
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: Conor Dooley @ 2026-04-08 17:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: caohang, gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <20260408-ginger-grouse-of-virtuosity-b3ee92@quoll>
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
On Wed, Apr 08, 2026 at 09:48:43AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 02:17:02PM +0800, caohang@eswincomputing.com wrote:
> > From: Hang Cao <caohang@eswincomputing.com>
> >
> > The EIC7700 USB controller requires a USB PHY RESET operation.PHY RESET
>
> Missing space after full stop.
>
> > operation was missed in the verification version, as it was performed in
> > ESWIN's U-Boot.
> >
> > If a non-ESWIN provided loader is used, this issue will occur, resulting
> > in USB not work.This patch does not introduce any backward incompatibility
> > since the dts is not upstream yet.
>
> So U-Boot will be affected, no?
Is it even really affected? I don't think there's any bootloader for this
other than what ESWIN is shipping downstream, outside of people's development
trees. And any software that expected two resets will work just as badly as
it always did when a third one is added.
> And even if DTS is not upstreamed, what about all out of tree DTS?
> This is an already released ABI, so at least explain that driver does
> not care about resets here and grabs them all.
>
> >
> > Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
>
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v5 5/5] watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
From: Thomas Perrot (Schneider Electric) @ 2026-04-08 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric)
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668@bootlin.com>
Add watchdog driver for the Aaeon SRG-IMX8P embedded controller.
This driver provides system monitoring and recovery capabilities
through the MCU's watchdog timer.
The watchdog supports start, stop, and ping operations with a maximum
hardware heartbeat of 25 seconds and a default timeout of 240 seconds.
Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
MAINTAINERS | 1 +
drivers/watchdog/Kconfig | 10 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/aaeon_mcu_wdt.c | 132 +++++++++++++++++++++++++++++++++++++++
4 files changed, 144 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2538f8c4bc14..7b92af42c9fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,6 +193,7 @@ S: Maintained
F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
F: drivers/gpio/gpio-aaeon-mcu.c
F: drivers/mfd/aaeon-mcu.c
+F: drivers/watchdog/aaeon_mcu_wdt.c
F: include/linux/mfd/aaeon-mcu.h
AAEON UPBOARD FPGA MFD DRIVER
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d3b9df7d466b..f67a0b453316 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -420,6 +420,16 @@ config SL28CPLD_WATCHDOG
# ARM Architecture
+config AAEON_MCU_WATCHDOG
+ tristate "Aaeon MCU Watchdog"
+ depends on MFD_AAEON_MCU
+ select WATCHDOG_CORE
+ help
+ Select this option to enable watchdog timer support for the Aaeon
+ SRG-IMX8P onboard microcontroller (MCU). This driver provides
+ watchdog functionality through the MCU, allowing system monitoring
+ and automatic recovery from system hangs.
+
config AIROHA_WATCHDOG
tristate "Airoha EN7581 Watchdog"
depends on ARCH_AIROHA || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index ba52099b1253..2deec425d3ea 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
# ALPHA Architecture
# ARM Architecture
+obj-$(CONFIG_AAEON_MCU_WATCHDOG) += aaeon_mcu_wdt.o
obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
obj-$(CONFIG_ARMADA_37XX_WATCHDOG) += armada_37xx_wdt.o
diff --git a/drivers/watchdog/aaeon_mcu_wdt.c b/drivers/watchdog/aaeon_mcu_wdt.c
new file mode 100644
index 000000000000..949b506d8194
--- /dev/null
+++ b/drivers/watchdog/aaeon_mcu_wdt.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Aaeon MCU Watchdog driver
+ *
+ * Copyright (C) 2026 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#include <linux/mfd/aaeon-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/watchdog.h>
+
+#define AAEON_MCU_PING_WDT 0x73
+
+#define AAEON_MCU_WDT_TIMEOUT 240
+#define AAEON_MCU_WDT_HEARTBEAT_MS 25000
+
+struct aaeon_mcu_wdt {
+ struct watchdog_device wdt;
+ struct regmap *regmap;
+};
+
+static int aaeon_mcu_wdt_cmd(struct aaeon_mcu_wdt *data, u8 opcode, u8 arg)
+{
+ return regmap_write(data->regmap, AAEON_MCU_REG(opcode, arg), 0);
+}
+
+static int aaeon_mcu_wdt_start(struct watchdog_device *wdt)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+
+ return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT_OPCODE, 0x01);
+}
+
+static int aaeon_mcu_wdt_status(struct watchdog_device *wdt, bool *enabled)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+ unsigned int rsp;
+ int ret;
+
+ ret = regmap_read(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02),
+ &rsp);
+ if (ret)
+ return ret;
+
+ *enabled = rsp == 0x01;
+ return 0;
+}
+
+static int aaeon_mcu_wdt_stop(struct watchdog_device *wdt)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+
+ return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT_OPCODE, 0x00);
+}
+
+static int aaeon_mcu_wdt_ping(struct watchdog_device *wdt)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+
+ return aaeon_mcu_wdt_cmd(data, AAEON_MCU_PING_WDT, 0x00);
+}
+
+static const struct watchdog_info aaeon_mcu_wdt_info = {
+ .identity = "Aaeon MCU Watchdog",
+ .options = WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE
+};
+
+static const struct watchdog_ops aaeon_mcu_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = aaeon_mcu_wdt_start,
+ .stop = aaeon_mcu_wdt_stop,
+ .ping = aaeon_mcu_wdt_ping,
+};
+
+static int aaeon_mcu_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct watchdog_device *wdt;
+ struct aaeon_mcu_wdt *data;
+ bool enabled;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->regmap = dev_get_regmap(dev->parent, NULL);
+ if (!data->regmap)
+ return -ENODEV;
+
+ wdt = &data->wdt;
+ wdt->parent = dev;
+ wdt->info = &aaeon_mcu_wdt_info;
+ wdt->ops = &aaeon_mcu_wdt_ops;
+ /*
+ * The MCU firmware has a fixed hardware timeout of 25 seconds that
+ * cannot be changed. The watchdog core will handle automatic pinging
+ * to support longer timeouts. The software timeout of 240 seconds is
+ * chosen arbitrarily as a reasonable value and is not user-configurable.
+ */
+ wdt->timeout = AAEON_MCU_WDT_TIMEOUT;
+ wdt->max_hw_heartbeat_ms = AAEON_MCU_WDT_HEARTBEAT_MS;
+
+ watchdog_set_drvdata(wdt, data);
+
+ ret = aaeon_mcu_wdt_status(wdt, &enabled);
+ if (ret)
+ return ret;
+
+ if (enabled)
+ set_bit(WDOG_HW_RUNNING, &wdt->status);
+
+ return devm_watchdog_register_device(dev, wdt);
+}
+
+static struct platform_driver aaeon_mcu_wdt_driver = {
+ .driver = {
+ .name = "aaeon-mcu-wdt",
+ },
+ .probe = aaeon_mcu_wdt_probe,
+};
+
+module_platform_driver(aaeon_mcu_wdt_driver);
+
+MODULE_DESCRIPTION("Aaeon MCU Watchdog Driver");
+MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v5 4/5] gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU
From: Thomas Perrot (Schneider Electric) @ 2026-04-08 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Bartosz Golaszewski
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668@bootlin.com>
Add GPIO driver for the Aaeon SRG-IMX8P embedded controller. This
driver supports 7 GPO (General Purpose Output) pins and 12 GPIO pins
that can be configured as inputs or outputs.
The driver implements proper state management for GPO pins (which are
output-only) and full direction control for GPIO pins. During probe,
all pins are reset to a known state (GPOs low, GPIOs as inputs) to
prevent undefined behavior across system reboots, as the MCU does not
reset GPIO states on soft reboot.
Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
MAINTAINERS | 1 +
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-aaeon-mcu.c | 229 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 240 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f91b6a1826d0..2538f8c4bc14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -191,6 +191,7 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
S: Maintained
F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
+F: drivers/gpio/gpio-aaeon-mcu.c
F: drivers/mfd/aaeon-mcu.c
F: include/linux/mfd/aaeon-mcu.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c74da29253e8..4b37b5a15958 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -157,6 +157,15 @@ config GPIO_74XX_MMIO
8 bits: 74244 (Input), 74273 (Output)
16 bits: 741624 (Input), 7416374 (Output)
+config GPIO_AAEON_MCU
+ tristate "Aaeon MCU GPIO support"
+ depends on MFD_AAEON_MCU
+ help
+ Select this option to enable GPIO support for the Aaeon SRG-IMX8P
+ onboard MCU. This driver provides access to GPIO pins and GPO
+ (General Purpose Output) pins controlled by the microcontroller.
+ The driver handles both input and output configuration.
+
config GPIO_ALTERA
tristate "Altera GPIO"
select GPIOLIB_IRQCHIP
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 2421a8fd3733..1ba6318bc558 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_GPIO_104_IDI_48) += gpio-104-idi-48.o
obj-$(CONFIG_GPIO_104_IDIO_16) += gpio-104-idio-16.o
obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
obj-$(CONFIG_GPIO_74XX_MMIO) += gpio-74xx-mmio.o
+obj-$(CONFIG_GPIO_AAEON_MCU) += gpio-aaeon-mcu.o
obj-$(CONFIG_GPIO_ADNP) += gpio-adnp.o
obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
obj-$(CONFIG_GPIO_ADP5585) += gpio-adp5585.o
diff --git a/drivers/gpio/gpio-aaeon-mcu.c b/drivers/gpio/gpio-aaeon-mcu.c
new file mode 100644
index 000000000000..a37d3dc83795
--- /dev/null
+++ b/drivers/gpio/gpio-aaeon-mcu.c
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Aaeon MCU GPIO driver
+ *
+ * Copyright (C) 2026 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/gpio/driver.h>
+#include <linux/mfd/aaeon-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define AAEON_MCU_CONFIG_GPIO_INPUT 0x69
+#define AAEON_MCU_CONFIG_GPIO_OUTPUT 0x6F
+#define AAEON_MCU_READ_GPIO 0x72
+#define AAEON_MCU_WRITE_GPIO 0x77
+
+#define AAEON_MCU_CONTROL_GPO 0x6C
+
+#define MAX_GPIOS 12
+#define MAX_GPOS 7
+
+struct aaeon_mcu_gpio {
+ struct gpio_chip gc;
+ struct regmap *regmap;
+ DECLARE_BITMAP(dir_in, MAX_GPOS + MAX_GPIOS);
+ DECLARE_BITMAP(gpo_state, MAX_GPOS);
+};
+
+static int aaeon_mcu_gpio_config_input_cmd(struct aaeon_mcu_gpio *data,
+ unsigned int offset)
+{
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONFIG_GPIO_INPUT, offset - 7),
+ 0);
+}
+
+static int aaeon_mcu_gpo_set_cmd(struct aaeon_mcu_gpio *data, unsigned int offset, int value)
+{
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONTROL_GPO, offset + 1),
+ !!value);
+}
+
+static int aaeon_mcu_gpio_direction_input(struct gpio_chip *gc, unsigned int offset)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ int ret;
+
+ if (offset < MAX_GPOS) {
+ dev_err(gc->parent,
+ "offset %d is a GPO (output-only) pin, cannot be configured as input\n",
+ offset);
+ return -EOPNOTSUPP;
+ }
+
+ ret = aaeon_mcu_gpio_config_input_cmd(data, offset);
+ if (ret < 0)
+ return ret;
+
+ __set_bit(offset, data->dir_in);
+
+ return 0;
+}
+
+static int aaeon_mcu_gpio_config_output_cmd(struct aaeon_mcu_gpio *data,
+ unsigned int offset,
+ int value)
+{
+ int ret;
+
+ ret = regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONFIG_GPIO_OUTPUT, offset - 7),
+ 0);
+ if (ret < 0)
+ return ret;
+
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_WRITE_GPIO, offset - 7),
+ !!value);
+}
+
+static int aaeon_mcu_gpio_direction_output(struct gpio_chip *gc, unsigned int offset, int value)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ int ret;
+
+ if (offset < MAX_GPOS) {
+ ret = aaeon_mcu_gpo_set_cmd(data, offset, value);
+ if (ret)
+ return ret;
+ __assign_bit(offset, data->gpo_state, value);
+ return 0;
+ }
+
+ ret = aaeon_mcu_gpio_config_output_cmd(data, offset, value);
+ if (ret < 0)
+ return ret;
+
+ __clear_bit(offset, data->dir_in);
+
+ return 0;
+}
+
+static int aaeon_mcu_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+
+ return test_bit(offset, data->dir_in) ?
+ GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
+}
+
+static int aaeon_mcu_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ unsigned int rsp;
+ int ret;
+
+ if (offset < MAX_GPOS)
+ return test_bit(offset, data->gpo_state);
+
+ ret = regmap_read(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_READ_GPIO, offset - 7),
+ &rsp);
+ if (ret < 0)
+ return ret;
+
+ return rsp;
+}
+
+static int aaeon_mcu_gpio_set_cmd(struct aaeon_mcu_gpio *data, unsigned int offset, int value)
+{
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_WRITE_GPIO, offset - 7),
+ !!value);
+}
+
+static int aaeon_mcu_gpio_set(struct gpio_chip *gc, unsigned int offset,
+ int value)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ int ret;
+
+ if (offset >= MAX_GPOS)
+ return aaeon_mcu_gpio_set_cmd(data, offset, value);
+
+ ret = aaeon_mcu_gpo_set_cmd(data, offset, value);
+ if (ret)
+ return ret;
+ __assign_bit(offset, data->gpo_state, value);
+ return 0;
+}
+
+static const struct gpio_chip aaeon_mcu_chip = {
+ .label = "gpio-aaeon-mcu",
+ .owner = THIS_MODULE,
+ .get_direction = aaeon_mcu_gpio_get_direction,
+ .direction_input = aaeon_mcu_gpio_direction_input,
+ .direction_output = aaeon_mcu_gpio_direction_output,
+ .get = aaeon_mcu_gpio_get,
+ .set = aaeon_mcu_gpio_set,
+ .base = -1,
+ .ngpio = MAX_GPOS + MAX_GPIOS,
+ .can_sleep = true,
+};
+
+static void aaeon_mcu_gpio_reset(struct aaeon_mcu_gpio *data, struct device *dev)
+{
+ unsigned int i;
+ int ret;
+
+ /* Reset all GPOs */
+ for (i = 0; i < MAX_GPOS; i++) {
+ ret = aaeon_mcu_gpo_set_cmd(data, i, 0);
+ if (ret < 0)
+ dev_warn(dev, "Failed to reset GPO %u state: %d\n", i, ret);
+ __clear_bit(i, data->dir_in);
+ }
+
+ /* Reset all GPIOs */
+ for (i = MAX_GPOS; i < MAX_GPOS + MAX_GPIOS; i++) {
+ ret = aaeon_mcu_gpio_config_input_cmd(data, i);
+ if (ret < 0)
+ dev_warn(dev, "Failed to reset GPIO %u state: %d\n", i, ret);
+ __set_bit(i, data->dir_in);
+ }
+}
+
+static int aaeon_mcu_gpio_probe(struct platform_device *pdev)
+{
+ struct aaeon_mcu_gpio *data;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!data->regmap)
+ return -ENODEV;
+
+ data->gc = aaeon_mcu_chip;
+ data->gc.parent = pdev->dev.parent;
+
+ /*
+ * Reset all GPIO states to a known configuration. The MCU does not
+ * reset GPIO state on soft reboot, only on power cycle (hard reboot).
+ * Without this reset, GPIOs would retain their previous state across
+ * reboots, which could lead to unexpected behavior.
+ */
+ aaeon_mcu_gpio_reset(data, &pdev->dev);
+
+ return devm_gpiochip_add_data(&pdev->dev, &data->gc, data);
+}
+
+static struct platform_driver aaeon_mcu_gpio_driver = {
+ .driver = {
+ .name = "aaeon-mcu-gpio",
+ },
+ .probe = aaeon_mcu_gpio_probe,
+};
+module_platform_driver(aaeon_mcu_gpio_driver);
+
+MODULE_DESCRIPTION("GPIO interface for Aaeon MCU");
+MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v5 3/5] mfd: aaeon: Add SRG-IMX8P MCU driver
From: Thomas Perrot (Schneider Electric) @ 2026-04-08 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric)
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668@bootlin.com>
Add Multi-Function Device (MFD) driver for the Aaeon SRG-IMX8P
embedded controller. This driver provides the core I2C communication
interface and registers child devices (GPIO and watchdog controllers).
The driver implements a custom regmap bus over I2C to match the MCU's
fixed 3-byte command format [opcode, arg, value]. Register addresses
are encoded as 16-bit values (opcode << 8 | arg) using the
AAEON_MCU_REG() macro defined in the shared header. The regmap
instance is shared with child drivers via dev_get_regmap(). Concurrent
I2C accesses from child drivers are serialized by regmap's built-in
locking.
I2C transfers use heap-allocated DMA-safe buffers rather than
stack-allocated ones, as required by I2C controllers that perform DMA.
Regmap caching is enabled (REGCACHE_MAPLE) with a volatile_reg
callback that marks GPIO input read registers (opcode 0x72) and the
watchdog status register (opcode 0x63, arg 0x02) as volatile. All
other registers written by the driver (GPIO direction,
GPO state, watchdog control) are stable and can be safely cached.
Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
MAINTAINERS | 2 +
drivers/mfd/Kconfig | 10 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/aaeon-mcu.c | 204 ++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/aaeon-mcu.h | 40 +++++++++
5 files changed, 257 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea9d55f76f35..f91b6a1826d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -191,6 +191,8 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
S: Maintained
F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
+F: drivers/mfd/aaeon-mcu.c
+F: include/linux/mfd/aaeon-mcu.h
AAEON UPBOARD FPGA MFD DRIVER
M: Thomas Richard <thomas.richard@bootlin.com>
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index aace5766b38a..82ec1d8e7224 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1561,6 +1561,16 @@ config ABX500_CORE
remain unchanged when IC changes. Binding of the functions to
actual register access is done by the IC core driver.
+config MFD_AAEON_MCU
+ tristate "Aaeon SRG-IMX8P MCU Driver"
+ depends on I2C || COMPILE_TEST
+ select MFD_CORE
+ help
+ Select this option to enable support for the Aaeon SRG-IMX8P
+ onboard microcontroller (MCU). This driver provides the core
+ functionality to communicate with the MCU over I2C. The MCU
+ provides GPIO and watchdog functionality.
+
config AB8500_CORE
bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
depends on ABX500_CORE && MFD_DB8500_PRCMU
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e75e8045c28a..34db5b033584 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
+obj-$(CONFIG_MFD_AAEON_MCU) += aaeon-mcu.o
obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
obj-$(CONFIG_MFD_SM501) += sm501.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
diff --git a/drivers/mfd/aaeon-mcu.c b/drivers/mfd/aaeon-mcu.c
new file mode 100644
index 000000000000..3b4e2d891534
--- /dev/null
+++ b/drivers/mfd/aaeon-mcu.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Aaeon MCU driver
+ *
+ * Copyright (C) 2026 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/mfd/aaeon-mcu.h>
+#include <linux/mfd/core.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+struct aaeon_mcu {
+ struct i2c_client *client;
+ u8 *cmd; /* DMA-safe 3-byte write buffer [opcode, arg, value] */
+ u8 *response; /* DMA-safe 1-byte read buffer for MCU acknowledgment */
+};
+
+static const struct mfd_cell aaeon_mcu_devs[] = {
+ MFD_CELL_BASIC("aaeon-mcu-wdt", NULL, NULL, 0, 0),
+ MFD_CELL_BASIC("aaeon-mcu-gpio", NULL, NULL, 0, 0),
+};
+
+/* Number of bytes in a MCU command: [opcode, arg, value] */
+#define AAEON_MCU_CMD_LEN 3
+
+/*
+ * Custom regmap bus for the Aaeon MCU I2C protocol.
+ *
+ * The MCU uses a fixed 3-byte command format [opcode, arg, value] followed
+ * by a 1-byte response. It requires a STOP condition between the command
+ * write and the response read, so two separate i2c_transfer() calls are
+ * issued. The regmap lock serialises concurrent accesses from the GPIO
+ * and watchdog child drivers.
+ *
+ * Register addresses are encoded as a 16-bit big-endian value where the
+ * high byte is the opcode and the low byte is the argument, matching the
+ * wire layout produced by regmap for reg_bits=16.
+ */
+
+static int aaeon_mcu_regmap_write(void *context, const void *data, size_t count)
+{
+ struct aaeon_mcu *mcu = context;
+ struct i2c_client *client = mcu->client;
+ struct i2c_msg write_msg;
+ /* The MCU always sends a response byte after each command; discard it. */
+ struct i2c_msg response_msg;
+ int ret;
+
+ memcpy(mcu->cmd, data, count);
+
+ write_msg.addr = client->addr;
+ write_msg.flags = 0;
+ write_msg.buf = mcu->cmd;
+ write_msg.len = count;
+
+ response_msg.addr = client->addr;
+ response_msg.flags = I2C_M_RD;
+ response_msg.buf = mcu->response;
+ response_msg.len = 1;
+
+ ret = i2c_transfer(client->adapter, &write_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ ret = i2c_transfer(client->adapter, &response_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return 0;
+}
+
+static int aaeon_mcu_regmap_read(void *context, const void *reg_buf,
+ size_t reg_size, void *val_buf, size_t val_size)
+{
+ struct aaeon_mcu *mcu = context;
+ struct i2c_client *client = mcu->client;
+ struct i2c_msg write_msg;
+ struct i2c_msg read_msg;
+ int ret;
+
+ /*
+ * reg_buf holds the 2-byte big-endian register address [opcode, arg].
+ * Append a trailing 0x00 to form the full 3-byte MCU command.
+ */
+ mcu->cmd[0] = ((u8 *)reg_buf)[0];
+ mcu->cmd[1] = ((u8 *)reg_buf)[1];
+ mcu->cmd[2] = 0x00;
+
+ write_msg.addr = client->addr;
+ write_msg.flags = 0;
+ write_msg.buf = mcu->cmd;
+ write_msg.len = AAEON_MCU_CMD_LEN;
+
+ read_msg.addr = client->addr;
+ read_msg.flags = I2C_M_RD;
+ read_msg.buf = val_buf;
+ read_msg.len = val_size;
+
+ ret = i2c_transfer(client->adapter, &write_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ ret = i2c_transfer(client->adapter, &read_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return 0;
+}
+
+static const struct regmap_bus aaeon_mcu_regmap_bus = {
+ .write = aaeon_mcu_regmap_write,
+ .read = aaeon_mcu_regmap_read,
+};
+
+static bool aaeon_mcu_volatile_reg(struct device *dev, unsigned int reg)
+{
+ /*
+ * GPIO input registers are driven by external signals and can change
+ * at any time without CPU involvement, always read from hardware.
+ *
+ * The watchdog status register reflects hardware state and can change
+ * autonomously.
+ *
+ * All other registers are written by the driver and their values are
+ * stable, so they can be safely cached.
+ */
+ if ((reg >> 8) == AAEON_MCU_READ_GPIO_OPCODE)
+ return true;
+ if (reg == AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02))
+ return true;
+ return false;
+}
+
+static const struct regmap_config aaeon_mcu_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .max_register = AAEON_MCU_MAX_REGISTER,
+ .volatile_reg = aaeon_mcu_volatile_reg,
+ .cache_type = REGCACHE_MAPLE,
+};
+
+static int aaeon_mcu_probe(struct i2c_client *client)
+{
+ struct aaeon_mcu *mcu;
+ struct regmap *regmap;
+
+ mcu = devm_kzalloc(&client->dev, sizeof(*mcu), GFP_KERNEL);
+ if (!mcu)
+ return -ENOMEM;
+
+ mcu->client = client;
+
+ mcu->cmd = devm_kzalloc(&client->dev, AAEON_MCU_CMD_LEN * sizeof(*mcu->cmd), GFP_KERNEL);
+ if (!mcu->cmd)
+ return -ENOMEM;
+
+ mcu->response = devm_kzalloc(&client->dev, sizeof(*mcu->response), GFP_KERNEL);
+ if (!mcu->response)
+ return -ENOMEM;
+
+ regmap = devm_regmap_init(&client->dev, &aaeon_mcu_regmap_bus,
+ mcu, &aaeon_mcu_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(&client->dev, PTR_ERR(regmap),
+ "failed to initialize regmap\n");
+
+ return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
+ aaeon_mcu_devs, ARRAY_SIZE(aaeon_mcu_devs),
+ NULL, 0, NULL);
+}
+
+static const struct of_device_id aaeon_mcu_of_match[] = {
+ { .compatible = "aaeon,srg-imx8p-mcu" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, aaeon_mcu_of_match);
+
+static struct i2c_driver aaeon_mcu_driver = {
+ .driver = {
+ .name = "aaeon_mcu",
+ .of_match_table = aaeon_mcu_of_match,
+ },
+ .probe = aaeon_mcu_probe,
+};
+module_i2c_driver(aaeon_mcu_driver);
+
+MODULE_DESCRIPTION("Aaeon MCU Driver");
+MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/aaeon-mcu.h b/include/linux/mfd/aaeon-mcu.h
new file mode 100644
index 000000000000..3a1aeec85d60
--- /dev/null
+++ b/include/linux/mfd/aaeon-mcu.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Aaeon MCU driver definitions
+ *
+ * Copyright (C) 2026 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#ifndef __LINUX_MFD_AAEON_MCU_H
+#define __LINUX_MFD_AAEON_MCU_H
+
+/*
+ * MCU register address: the high byte is the command opcode, the low
+ * byte is the argument. This matches the 3-byte wire format
+ * [opcode, arg, value] used by the MCU I2C protocol.
+ */
+#define AAEON_MCU_REG(op, arg) (((op) << 8) | (arg))
+
+/*
+ * Opcode for GPIO input reads. These registers are volatile, their values
+ * are driven by external signals and can change without CPU involvement.
+ * Used by the MFD driver's volatile_reg callback to bypass the regmap cache.
+ */
+#define AAEON_MCU_READ_GPIO_OPCODE 0x72
+
+/*
+ * Opcode for watchdog control and status commands.
+ * The status register (arg=0x02) reflects hardware state and is volatile.
+ */
+#define AAEON_MCU_CONTROL_WDT_OPCODE 0x63
+
+/*
+ * Highest register address in the MCU register map.
+ * The WRITE_GPIO opcode (0x77) with the highest GPIO argument (0x0B = 11,
+ * i.e. MAX_GPIOS - 1) produces the largest encoded address.
+ */
+#define AAEON_MCU_MAX_REGISTER AAEON_MCU_REG(0x77, 0x0B)
+
+#endif /* __LINUX_MFD_AAEON_MCU_H */
--
2.53.0
^ permalink raw reply related
* [PATCH v5 2/5] dt-bindings: mfd: Add AAEON embedded controller
From: Thomas Perrot (Schneider Electric) @ 2026-04-08 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Conor Dooley
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668@bootlin.com>
Add device tree binding documentation for the AAEON embedded controller
(MCU). This microcontroller is found on AAEON embedded boards, it is
connected via I2C and provides GPIO control and a watchdog timer.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
.../bindings/mfd/aaeon,srg-imx8p-mcu.yaml | 67 ++++++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 73 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml b/Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
new file mode 100644
index 000000000000..034fb7b42551
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/aaeon,srg-imx8p-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AAEON Embedded Controller
+
+maintainers:
+ - Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ - Thomas Perrot <thomas.perrot@bootlin.com>
+
+description:
+ AAEON embeds a microcontroller on Standard RISC Gateway with ARM i.MX8M Plus
+ Quad-Core boards providing GPIO control and watchdog timer.
+
+ This MCU is connected via I2C bus.
+
+ Its GPIO controller provides 7 GPOs and 12 GPIOs.
+
+ Its watchdog has a fixed maximum hardware heartbeat of 25 seconds and supports
+ a timeout of 240 seconds through automatic pinging.
+ The timeout is not programmable and cannot be changed via device tree properties.
+
+properties:
+ compatible:
+ const: aaeon,srg-imx8p-mcu
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 19
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@62 {
+ compatible = "aaeon,srg-imx8p-mcu";
+ reg = <0x62>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "gpo-1", "gpo-2", "gpo-3", "gpo-4",
+ "gpo-5", "gpo-6", "gpo-7",
+ "gpio-1", "gpio-2", "gpio-3", "gpio-4",
+ "gpio-5", "gpio-6", "gpio-7", "gpio-8",
+ "gpio-9", "gpio-10", "gpio-11", "gpio-12";
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c9e416ba74c6..ea9d55f76f35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -186,6 +186,12 @@ W: http://www.adaptec.com/
F: Documentation/scsi/aacraid.rst
F: drivers/scsi/aacraid/
+AAEON SRG-IMX8P CONTROLLER MFD DRIVER
+M: Thomas Perrot <thomas.perrot@bootlin.com>
+R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
+
AAEON UPBOARD FPGA MFD DRIVER
M: Thomas Richard <thomas.richard@bootlin.com>
S: Maintained
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/5] dt-bindings: vendor-prefixes: Add AAEON vendor prefix
From: Thomas Perrot (Schneider Electric) @ 2026-04-08 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Krzysztof Kozlowski
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668@bootlin.com>
Add the AAEON vendor prefix to support the AAEON SRG-IMX8P MCU driver
devicetree bindings.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index c7591b2aec2a..0f84ee93b3a8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -32,6 +32,8 @@ patternProperties:
description: 8devices, UAB
"^9tripod,.*":
description: Shenzhen 9Tripod Innovation and Development CO., LTD.
+ "^aaeon,.*":
+ description: AAEON
"^abb,.*":
description: ABB
"^abilis,.*":
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/5] Add support for AAEON SRG-IMX8P MCU
From: Thomas Perrot (Schneider Electric) @ 2026-04-08 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski
This patch series introduces support for the AAEON SRG-IMX8P embedded
controller (MCU). The MCU is connected via I2C and provides GPIO and
watchdog functionality for the SRG-IMX8P board.
The series includes:
- Device tree binding for the MFD driver
- MFD driver that serves as the core driver for the MCU
- GPIO driver implementing the GPIO functionality
- Watchdog driver for system monitoring
- MAINTAINERS entry for the new drivers
The drivers follow the standard Linux kernel subsystem patterns, with
the MFD driver registering the sub-devices (GPIO and watchdog) which
are then handled by their respective subsystem drivers.
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
Changes in v5:
- mfd: use heap-allocated DMA-safe buffers for I2C transfers, replacing
stack-allocated buffers in the regmap bus callbacks
- mfd: switch from REGCACHE_NONE to REGCACHE_MAPLE; add volatile_reg
callback marking GPIO input read registers (opcode 0x72) as volatile;
add max_register
- mfd: use PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE
- mfd: use MFD_CELL_BASIC() macro for cell definitions
- mfd: use dev_err_probe() for regmap initialization error
- Link to v4: https://lore.kernel.org/r/20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com
Changes in v4:
- mfd: switch to a custom regmap bus; remove aaeon_mcu_i2c_xfer() and the aaeon_mcu_dev struct
- mfd: locking delegated to regmap's built-in mutex; drop explicit mutex
- mfd: remove firmware version reading at probe time
- gpio, watchdog: use regmap_read()/regmap_write() via dev_get_regmap()
- include: replace aaeon_mcu_i2c_xfer() declaration with AAEON_MCU_REG() macro
- dt-bindings: remove unused label from example node
- Link to v3: https://lore.kernel.org/r/20260203-dev-b4-aaeon-mcu-driver-v3-0-0a19432076ac@bootlin.com
Changes in v3:
- Renamed SRG-IMX8PL to SRG-IMX8P
- dt-bindings: add gpio-controller properties as required
- mfd: move struct aaeon_mcu_dev from header to .c file (private)
- mfd: use guard(mutex) and devm_mutex_init() for cleanup
- mfd: firmware version log changed to dev_dbg()
- mfd: add select MFD_CORE to Kconfig
- Kconfig: add || COMPILE_TEST to all three drivers
- watchdog: add comments explaining hardware timeout and WDOG_HW_RUNNING
- watchdog: remove unused platform_set_drvdata()
- watchdog: add a function to query the status
- Link to v2: https://lore.kernel.org/r/20260123-dev-b4-aaeon-mcu-driver-v2-0-9f4c00bfb5cb@bootlin.com
Changes in v2:
- Fold GPIO and watchdog bindings into MFD binding
- Drop OF_GPIO dependency in GPIO Kconfig
- Use __set_bit/__clear_bit/__assign_bit instead of atomic variants
- Various driver cleanups and improvements
- Link to v1: https://lore.kernel.org/r/20251212-dev-b4-aaeon-mcu-driver-v1-0-6bd65bc8ef12@bootlin.com
---
Thomas Perrot (Schneider Electric) (5):
dt-bindings: vendor-prefixes: Add AAEON vendor prefix
dt-bindings: mfd: Add AAEON embedded controller
mfd: aaeon: Add SRG-IMX8P MCU driver
gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU
watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
.../bindings/mfd/aaeon,srg-imx8p-mcu.yaml | 67 ++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 10 +
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-aaeon-mcu.c | 229 +++++++++++++++++++++
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/aaeon-mcu.c | 204 ++++++++++++++++++
drivers/watchdog/Kconfig | 10 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/aaeon_mcu_wdt.c | 132 ++++++++++++
include/linux/mfd/aaeon-mcu.h | 40 ++++
13 files changed, 716 insertions(+)
---
base-commit: d358e5254674b70f34c847715ca509e46eb81e6f
change-id: 20251211-dev-b4-aaeon-mcu-driver-e0e89ebf4afb
Best regards,
--
Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/3] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
From: Jeff Johnson @ 2026-04-08 17:15 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
David Heidelberg
Cc: Baochen Qiang, Vasanthakumar Thiagarajan, Dmitry Baryshkov,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260407-skip-host-cam-qmi-req-v5-0-dfa8a05c6538@ixit.cz>
On Tue, 07 Apr 2026 08:43:53 +0200, David Heidelberg wrote:
> This quirk is used so far used on:
> - LG G7 ThinQ
> - Xiaomi Poco F1
>
> I'm resending it after ~ 4 years since initial send due to Snapdragon
> 845 being one of best supported platform for mobile phones running
> Linux, so it would be shame to not have shiny support.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
commit: 3d7640b6c371a1795e6d9580695d20caf16be9a4
[2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
commit: 6a7693873b20680a3c33bae0c9f9cb3185f64ade
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 0/3] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
From: Jeff Johnson @ 2026-04-08 17:15 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
David Heidelberg
Cc: Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260325-skip-host-cam-qmi-req-v4-0-bc08538487aa@ixit.cz>
On Wed, 25 Mar 2026 18:57:14 +0100, David Heidelberg wrote:
> This quirk is used so far used on:
> - LG G7 ThinQ
> - Xiaomi Poco F1
>
> I'm resending it after ~ 4 years since initial send due to Snapdragon
> 845 being one of best supported platform for mobile phones running
> Linux, so it would be shame to not have shiny support.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
commit: 3d7640b6c371a1795e6d9580695d20caf16be9a4
[2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
(no commit info)
[3/3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Enable ath10k host-cap skip quirk
(no commit info)
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Nicolas Frattaroli @ 2026-04-08 17:11 UTC (permalink / raw)
To: Rob Herring, Dmitry Torokhov
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner, kernel, linux-input,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <adaJOEZHHmvZM_cB@google.com>
On Wednesday, 8 April 2026 18:59:08 Central European Summer Time Dmitry Torokhov wrote:
> On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> > On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > > On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > > > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > > > property. This makes it impossible to model devices that have ADC inputs
> > > > > that should generate switch events.
> > > >
> > > > The solution is to use unevaluatedProps instead, which also allows
> > > > dropping other properties.
> > > >
> > > > Best regards,
> > > > Krzysztof
> > > >
> > > >
> > >
> > > Hi Krzysztof,
> > >
> > > to understand the motivation behind this suggestion correctly:
> > > are the "linux," vendor prefixed properties, especially with regards
> > > to key codes, generally a bit of a thorn in the side of DT bindings
> > > maintainers?
> >
> > Not really. Most have existed for decades. New ones get extra scrutiny
> > and often end up dropping the linux prefix.
> >
> > > I'd imagine so since they technically tie the DT to a specific OS
> > > kernel (though of course, others are free to translate those key
> > > codes). And the whole idea of configuring which code is emitted
> > > from something is basically abusing DT for configuring software
> > > rather than describing hardware.
> > >
> > > I'm mainly interested because this is a thought that has been in
> > > the back of my mind for a while now, and I'm curious if the DT
> > > binding maintainers happen to have arrived at the same impassé,
> > > where linux,input-type et al abuse the DT model for something we
> > > would tell any other vendor not to abuse it for, but no better
> > > solution exists right now to achieve the same thing.
> >
> > Not sure what the BSDs do here. It's never come up that I remember. Best
> > I can tell is they just make it a userspace problem. So every possible
> > keyboard needs a keymap file. Though I'm not sure how that would work
> > with GPIO keys as you don't really have a scan code.
>
> Is there an update for this binding or should I apply the current
> version? I am OK with the driver changes...
>
> Thanks.
>
>
I will send a new version that doesn't add the property but allows
unevaluatedProps instead. Thanks for reminding me.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v2 1/4] riscv: add UltraRISC SoC family Kconfig support
From: Conor Dooley @ 2026-04-08 17:10 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <177561282495.2731393.9548650582911498336.b4-reply@b4>
[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]
On Wed, Apr 08, 2026 at 09:47:04AM +0800, Jia Wang wrote:
> On 2026-04-07 17:29 +0100, Conor Dooley wrote:
> > On Tue, Apr 07, 2026 at 10:40:52AM +0800, Jia Wang wrote:
> > > The first SoC in the UltraRISC series is UR-DP1000, containing octa
> > > UltraRISC C100 cores.
> >
> > Not gonna lie, I find it odd that pcie is where this platform starts
> > off, but sure. What's the plan for adding the rest of the platform?
> >
>
> Hi Conor,
>
> Thanks for the question.
>
> Our next step is to upstream the pinctrl driver together with the related
> DTS updates. The pinctrl series only affects the SoC’s low-speed peripheral
> interfaces. For GMAC, SPI, I2C, and GPIO, we plan to use the existing
> kernel drivers, so no new controller drivers are needed
And clocks? pinctrl and clocks would be the bare minimum level of
support required before a platform should be merged. Obviously, you can
get device drivers for PCI etc etc merged without clock drivers, but the
initial dts should contain the clocks too.
> > >
> > > Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> > > ---
> > > arch/riscv/Kconfig.socs | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > > index d621b85dd63b..98708569ec6a 100644
> > > --- a/arch/riscv/Kconfig.socs
> > > +++ b/arch/riscv/Kconfig.socs
> > > @@ -84,6 +84,15 @@ config ARCH_THEAD
> > > help
> > > This enables support for the RISC-V based T-HEAD SoCs.
> > >
> > > +config ARCH_ULTRARISC
> > > + bool "UltraRISC RISC-V SoCs"
> > > + help
> > > + This enables support for UltraRISC SoC platform hardware,
> > > + including boards based on the UR-DP1000.
> >
> > > + UR-DP1000 is an 8-core 64-bit RISC-V SoC that supports
> > > + the RV64GCBHX ISA. It supports Hardware Virtualization
> > > + and RISC-V RV64 ISA H(v1.0) Extension.
> >
> > Delete this section IMO, doesn't provide any real value. Don't need nor
> > want the marketing brochure in the help text. The first sentence is
> > sufficient.
> >
>
> I’ll drop the SoC description part from the Kconfig help text as you
> suggested.
>
> > > +
> > > config ARCH_VIRT
> > > bool "QEMU Virt Machine"
> > > select POWER_RESET
> > >
> > > --
> > > 2.34.1
> > >
>
> Best regards,
> Jia Wang
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Herve Codina @ 2026-04-08 17:09 UTC (permalink / raw)
To: Rob Herring
Cc: Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260408122901.GA42727-robh@kernel.org>
Hi Rob, Mark,
On Wed, 8 Apr 2026 07:29:01 -0500
Rob Herring <robh@kernel.org> wrote:
...
> > +properties:
> > + compatible:
> > + const: audio-gpio-amp
>
> To be consistent with other GPIO controlled devices: gpio-audio-amp
Ok.
Mark suggested to merge this gpio-audio-amp with simple-amplifier.
This leads to the following question:
Should I keep the 'gpio-audio-amp' compatible string ?
Should I keep two bindings (this one and the simple-audio-amplifier.yaml) or
should I merge bindings?
...
> > + gain-gpios:
> > + description: |
> > + GPIOs to control the amplifier gain
> > +
> > + The gain value is computed from GPIOs value from 0 to 2^N-1 with N the
> > + number of GPIO described. The first GPIO described is the lsb of the gain
> > + value.
> > +
> > + For instance assuming 2 gpios
> > + gain-gpios = <&gpio1 GPIO_ACTIVE_HIGH> <&gpio2 GPIO_ACTIVE_HIGH>;
> > + The gain value will be the following:
> > +
> > + gpio1 | gpio2 | gain
> > + ------+-------+-----
> > + 0 | 0 | 0b00 -> 0
> > + 1 | 0 | 0b01 -> 1
> > + 0 | 1 | 0b10 -> 2
> > + 1 | 1 | 0b11 -> 3
> > + ------+-------+-----
> > +
> > + Note: The gain value, bits set to 1 or 0, indicate the state active (bit
> > + set) or the state inactive (bit unset) of the related GPIO. The
> > + physical voltage corresponding to this active/inactive state is
> > + given by the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags.
> > +
> > + minItems: 1
> > + maxItems: 32
>
> 2^32 levels? Seems like a bit much. Also, unless you can change the
> values of all the GPIOs atomically, aren't you going to get some
> artifacts while the gain is being changed? Unless you mute I guess.
I didn't want to set a particular limit related to the number of GPIOs
used for thje gain value. Of course 2^32 is obviously a lot.
What do you think about 16 for maxItems?
Related to Artifacts, yes they can probably be there. Also the mute feature
is not required. Some hardware use only one GPIO and doesn't implement mute
feature. In that case no artifacts can be present.
If mute is implemented, it is the application responsibility to handle
mute / unmute while changing the gain value. I don't think we can do anything
at driver level to avoid those artifacts if any.
>
> > +
> > + gain-points:
> > + $ref: /schemas/types.yaml#/definitions/int32-matrix
> > + items:
> > + items:
> > + - description: The GPIOs value
>
> Can't this just be the index?
Some GPIOs value can be skipped if they don't make any sense in the hardware
design. With the index, this is not possible.
gpios:
0b00 -3dB
0b01 0dB
0b10 Reserved, should not be used
0b11 +3dB
With just the index, the reserved 0b10 value cannot be skipped. I would like
to handle this kind of cases.
>
> If not, then gain-range could be expressed using gain-points instead.
Do you have in mind something like the following?
gain-range = <0 (-300)>, <3 600>;
defining the range from -3dB to +6dB with GPIOs value 0 for -3dB and 3 for +6dB.
>
> > + - description: The related amplifier gain in 0.01 dB unit
> > + minItems: 2
> > + description: |
> > + List of the GPIOs value / Gain value in dB pair defining the gain
> > + set on each GPIOs value.
> > +
> > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > + Assuming that GPIOs values set the hardware gains according to the
> > + following table:
> > +
> > + GPIOs | Hardware
> > + value | amplification
> > + ------+--------------
> > + 0 | -10.0 dB
> > + 1 | +3.0 dB
> > + 2 | 0 dB
> > + 3 | +6.0 dB
> > + ------+--------------
> > +
> > + The description using gain points can be:
> > + gain-points = <0 (-1000)>, <1 300>, <2 0>, <3 600>;
> > +
> > + gain-range:
> > + $ref: /schemas/types.yaml#/definitions/int32-array
> > + items:
> > + - description: Gain in 0.01 dB unit when all GPIOs are inactive
> > + - description: Gain in 0.01 dB unit when all GPIOs are active
> > + description: |
> > + Gains (in 0.01 dB unit) set by the extremum (minimal and maximum) value
> > + of GPIOs. The following formula must be satisfied.
> > +
> > + gain-range[1] - gain-range[0]
> > + Gain = ------------------------------- x GPIO_value + gain-range[0]
> > + 2^N - 1
> > +
> > + With N, the number of GPIOs used to control the gain and Gain computed in
> > + 0.01 dB unit.
> > +
> > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > + Assuming that gain value set the hardware according to the following
> > + table:
> > +
> > + GPIOs | Hardware 1 | Hardware 2
> > + value | amplification | amplification
> > + ------+---------------+---------------
> > + 0 | -3.0 dB | +10.0 dB
> > + 1 | 0 dB | +5.0 dB
> > + 2 | +3.0 dB | 0 dB
> > + 3 | +6.0 dB | -5.0 dB
> > + ------+---------------+---------------
> > +
> > + The description for hardware 1 using a gain range can be:
> > + gain-range = <(-300) 600>;
> > +
> > + The description for hardware 2 using a gain range can be:
> > + gain-range = <1000 (-500)>;
> > +
> > + gain-labels:
> > + $ref: /schemas/types.yaml#/definitions/string-array
>
> minItems: 2
> maxItems: 0x100000000
Ok, I will adjust maxItems according to the max number of GPIO supported.
For my curiosity, is there a way to express maxItems with a computation
based on some other properties value ?
What could be relevant here is
maxitems: 2^(number of items available in the gpio-gain properties)
>
> > + description: |
> > + List of the gain labels attached to the combination of GPIOs controlling
> > + the gain. The first label is related to the gain value 0, the second label
> > + is related to the gain value 1 and so on.
> > +
> > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > + Assuming that gain value set the hardware according to the following
> > + table:
> > +
> > + GPIOs | Hardware
> > + value | amplification
> > + ------+--------------
> > + 0 | Low
> > + 1 | Middle
> > + 2 | High
> > + 3 | Max
> > + ------+--------------
> > +
> > + The description using gain labels can be:
> > + gain-labels = "Low", "Middle", "High", "Max";
>
> Do we need to allow these to be anything? It's going to get hard to come
> up with 2^32 names.
Well, "Normal" / "Boost" can make sense on some hardware.
I don't think we need to restrict labels to a list of known label here.
Of course 2^32 names is obviously a lot. What could be the limit?
>
> > +
> > +dependencies:
> > + gain-points: [ gain-gpios ]
> > + gain-range: [ gain-gpios ]
> > + gain-labels: [ gain-gpios ]
>
> gain-gpios is really optional?
Yes, we can have an amplifier without any possibility to change the gain
value but with a gpio allowing to mute or bypass the amplifier.
...
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + /* Gain controlled by gpios */
> > + amplifier0 {
>
> amplifier-0
Ok, it will be update in the next iteration as well as other node
names available in this example part.
...
> > +
> > + /* A mutable amplifier without any gain control */
> > + amplifier4 {
> > + compatible = "audio-gpio-amp";
> > + vdd-supply = <®ulator>;
> > + mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
>
> This case is just simple-amplifier...
No, simple-amplifier uses 'enable' and not 'mute'.
We can have the amplifier enabled ('enable' GPIO active) as it is
used and a switch driven by an other GPIO to mute / un-mute the
amplifier output.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 0/3] pic64gx semantic conflict "fixes"
From: Conor Dooley @ 2026-04-08 17:04 UTC (permalink / raw)
To: linux-riscv, Conor Dooley
Cc: Conor Dooley, Daire McNamara, Rob Herring, Krzysztof Kozlowski,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
devicetree, linux-kernel
In-Reply-To: <20260407-rely-speculate-dae3a81ea1fc@spud>
From: Conor Dooley <conor.dooley@microchip.com>
On Tue, 07 Apr 2026 16:36:22 +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> CC: Conor Dooley <conor.dooley@microchip.com>
> CC: Daire McNamara <daire.mcnamara@microchip.com>
> CC: Rob Herring <robh@kernel.org>
> CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
> CC: Paul Walmsley <pjw@kernel.org>
> CC: Palmer Dabbelt <palmer@dabbelt.com>
> CC: Albert Ou <aou@eecs.berkeley.edu>
> CC: Alexandre Ghiti <alex@ghiti.fr>
> CC: linux-riscv@lists.infradead.org
> CC: devicetree@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
>
> [...]
Applied to riscv-dt-for-next, thanks!
[1/3] riscv: dts: microchip: add tsu clock to macb on pic64gx
https://git.kernel.org/conor/c/89991efc78d7
[2/3] riscv: dts: microchip: update pic64gx gpio interrupts to better match the SoC
https://git.kernel.org/conor/c/53c013c3b27b
[3/3] riscv: dts: microchip: sort pic64gx i2c nodes alphanumerically
https://git.kernel.org/conor/c/ae488e2669f3
Thanks,
Conor.
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Dmitry Torokhov @ 2026-04-08 16:59 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Frattaroli, Krzysztof Kozlowski, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Heiko Stuebner, kernel,
linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20251217133440.GA724723-robh@kernel.org>
On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > > property. This makes it impossible to model devices that have ADC inputs
> > > > that should generate switch events.
> > >
> > > The solution is to use unevaluatedProps instead, which also allows
> > > dropping other properties.
> > >
> > > Best regards,
> > > Krzysztof
> > >
> > >
> >
> > Hi Krzysztof,
> >
> > to understand the motivation behind this suggestion correctly:
> > are the "linux," vendor prefixed properties, especially with regards
> > to key codes, generally a bit of a thorn in the side of DT bindings
> > maintainers?
>
> Not really. Most have existed for decades. New ones get extra scrutiny
> and often end up dropping the linux prefix.
>
> > I'd imagine so since they technically tie the DT to a specific OS
> > kernel (though of course, others are free to translate those key
> > codes). And the whole idea of configuring which code is emitted
> > from something is basically abusing DT for configuring software
> > rather than describing hardware.
> >
> > I'm mainly interested because this is a thought that has been in
> > the back of my mind for a while now, and I'm curious if the DT
> > binding maintainers happen to have arrived at the same impassé,
> > where linux,input-type et al abuse the DT model for something we
> > would tell any other vendor not to abuse it for, but no better
> > solution exists right now to achieve the same thing.
>
> Not sure what the BSDs do here. It's never come up that I remember. Best
> I can tell is they just make it a userspace problem. So every possible
> keyboard needs a keymap file. Though I'm not sure how that would work
> with GPIO keys as you don't really have a scan code.
Is there an update for this binding or should I apply the current
version? I am OK with the driver changes...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Stefan Wahren @ 2026-04-08 16:52 UTC (permalink / raw)
To: Gregor Herburger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-2-e02d1dbe6008@linutronix.de>
Hi Gregor,
[drop Emma's old address]
Am 08.04.26 um 10:00 schrieb Gregor Herburger:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> drivers/nvmem/Kconfig | 12 +++
> drivers/nvmem/Makefile | 1 +
> drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 2 +
> 4 files changed, 174 insertions(+)
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
> This driver can also be built as a module. If so, the module
> will be called nvmem_qoriq_efuse.
>
> +config NVMEM_RASPBERRYPI_OTP
> + tristate "Raspberry Pi OTP support"
> + # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> + # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
I don't think these comments are necessary, because this applies to
other firmware drivers, too.
> + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
> + help
> + This driver provides access to the Raspberry Pi OTP memory via the
> + nvmem subsystem. The driver supports the customer otp as well as the
> + device specific private key OTP.
> +
> + This driver can also be built as a module. If so, the module
> + will be called raspberrypi-otp.
> endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index 7252b8ec88d4..8ca2095e068f 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
> nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
> obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
> nvmem-qoriq-efuse-y := qoriq-efuse.o
> +obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP) += raspberrypi-otp.o
> diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
> new file mode 100644
> index 000000000000..13ee3784b137
> --- /dev/null
> +++ b/drivers/nvmem/raspberrypi-otp.c
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/module.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <soc/bcm2835/raspberrypi-firmware.h>
> +
> +struct rpi_otp_priv {
> + struct rpi_firmware *fw;
> + struct device *dev;
> + u32 read_tag;
> + u32 write_tag;
> +};
> +
> +struct rpi_otp_driver_data {
> + const char *name;
> + u32 read_tag;
> + u32 write_tag;
> +};
> +
> +struct rpi_otp_header {
> + u32 start;
> + u32 count;
> + u32 data[];
> +};
> +
> +static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
> +{
> + struct rpi_otp_priv *priv = context;
> + struct rpi_otp_header *fwbuf;
> + int ret;
> +
> + fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
> + if (!fwbuf)
> + return -ENOMEM;
> +
> + fwbuf->start = offset / 4;
> + fwbuf->count = bytes / 4;
> +
> + ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
> + sizeof(struct rpi_otp_header) + bytes);
> + if (ret)
> + goto out;
> +
> + memcpy(buf, fwbuf->data, bytes);
> +
> +out:
> + kfree(fwbuf);
> + return ret;
> +}
> +
> +static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
> +{
> + struct rpi_otp_priv *priv = context;
> + struct rpi_otp_header *fwbuf;
> + int ret;
> +
> + fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
> + if (!fwbuf)
> + return -ENOMEM;
> +
> + fwbuf->start = offset / 4;
> + fwbuf->count = bytes / 4;
> + memcpy(fwbuf->data, val, bytes);
> +
> + ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
> + sizeof(struct rpi_otp_header) + bytes);
> +
> + kfree(fwbuf);
> + return ret;
> +}
> +
> +static const struct rpi_otp_driver_data rpi_otp_customer = {
> + .name = "rpi-otp-customer",
> + .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
> + .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
> +};
> +
> +static const struct rpi_otp_driver_data rpi_otp_private = {
> + .name = "rpi-otp-private",
> + .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
> + .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
> +};
> +
> +static int rpi_otp_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_device *nvmem;
> + struct rpi_otp_priv *priv;
> + struct device_node *np;
> + const struct rpi_otp_driver_data *data;
> + struct nvmem_config config = {
> + .read_only = false,
> + .word_size = 4,
> + .stride = 4,
> + .reg_read = rpi_otp_read,
> + .reg_write = rpi_otp_write,
> + .size = 32,
> + };
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + data = device_get_match_data(dev);
> + if (!data)
> + return -ENODEV;
> +
> + np = of_get_parent(dev->of_node);
> + if (!np) {
> + dev_err(dev, "Missing firmware node\n");
> + return -ENOENT;
> + }
> +
> + priv->fw = devm_rpi_firmware_get(&pdev->dev, np);
> + of_node_put(np);
> + if (!priv->fw)
> + return -EPROBE_DEFER;
> +
> + priv->dev = dev;
> + priv->read_tag = data->read_tag;
> + priv->write_tag = data->write_tag;
> + config.dev = dev;
> + config.priv = priv;
> + config.name = data->name;
> +
> + nvmem = devm_nvmem_register(dev, &config);
> + if (IS_ERR(nvmem))
> + return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
> +
> + return 0;
> +}
Is there any reason, why we cannot register this driver in
rpi_firmware_probe() like hwmon and clk driver?
I like to avoid the complete dt-binding from patch 1.
> +
> +static const struct of_device_id rpi_otp_of_match[] = {
> + {
> + .compatible = "raspberrypi,firmware-otp-customer",
> + .data = &rpi_otp_customer
> + },
> + {
> + .compatible = "raspberrypi,firmware-otp-private",
> + .data = &rpi_otp_private,
> + },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rpi_otp_of_match);
> +
> +static struct platform_driver raspberry_otp_driver = {
> + .probe = rpi_otp_probe,
> + .driver = {
> + .name = "rpi-otp",
> + .of_match_table = rpi_otp_of_match,
> + },
> +};
> +module_platform_driver(raspberry_otp_driver);
> +
> +MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
> +MODULE_DESCRIPTION("Raspberry OTP driver");
Raspberry Pi OTP driver ?
Regards
> +MODULE_LICENSE("GPL");
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index e1f87fbfe554..6e94ccf34f47 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
> RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
> RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
> RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
> + RPI_FIRMWARE_GET_PRIVATE_OTP = 0x00030081,
> + RPI_FIRMWARE_SET_PRIVATE_OTP = 0x00038081,
>
> /* Dispmanx TAGS */
> RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: fpga: Technologic Systems TS-7300 FPGA Manager
From: Phil Pemberton @ 2026-04-08 16:52 UTC (permalink / raw)
To: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Tom Rix, Florian Fainelli, linux-fpga, devicetree, linux-kernel,
Phil Pemberton
In-Reply-To: <20260408165223.3051759-1-philpem@philpem.me.uk>
Add device tree binding documentation for the Altera Cyclone II FPGA
found on Technologic Systems (now EmbeddedTS) TS-7300 boards, programmed
via the memory-mapped interface in the CPLD.
Signed-off-by: Phil Pemberton <philpem@philpem.me.uk>
---
.../fpga/technologic,ts7300-fpga.yaml | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
diff --git a/Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml b/Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
new file mode 100644
index 000000000000..c93e3a1a135b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/technologic,ts7300-fpga.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Technologic Systems TS-7300 FPGA Manager
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+description:
+ FPGA manager for the Altera Cyclone II FPGA on Technologic Systems
+ TS-7300 board. The FPGA is programmed via the memory-mapped interface
+ implemented in the CPLD.
+
+properties:
+ compatible:
+ const: technologic,ts7300-fpga
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ fpga-mgr@13c00000 {
+ compatible = "technologic,ts7300-fpga";
+ reg = <0x13c00000 0x2>;
+ };
+...
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Add device tree binding for ts73xx-fpga
From: Phil Pemberton @ 2026-04-08 16:52 UTC (permalink / raw)
To: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Tom Rix, Florian Fainelli, linux-fpga, devicetree, linux-kernel,
Phil Pemberton
The driver for the Technologic Systems (EmbeddedTS) TS-7300 board's
onboard FPGA didn't have an OF match table. This prevented it from being
instantiated from a device tree. This is undesirable given EP93xx is
moving to device tree, and effectively prevents it from being used.
This patch series adds the OF match table and a device tree binding.
Changes since v1:
- Use specific compatible "technologic,ts7300-fpga" instead of
wildcard "technologic,ts73xx-fpga" (Krzysztof)
- Fix subject line for dt-bindings patch (Krzysztof)
- Simplify example in binding doc (Krzysztof)
Phil Pemberton (2):
dt-bindings: fpga: Technologic Systems TS-7300 FPGA Manager
fpga: ts73xx-fpga: add OF match table for device tree probing
.../fpga/technologic,ts7300-fpga.yaml | 36 +++++++++++++++++++
drivers/fpga/ts73xx-fpga.c | 9 +++++
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
--
2.43.0
^ 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