* [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: christian.koever-draxl @ 2026-04-19 15:08 UTC (permalink / raw)
To: neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
Add the device tree for this board and document the compatible string.
Supported features:
- 1GB/2GB RAM (via U-Boot memory fixup)
- 10/100 Ethernet (Internal PHY)
- eMMC and SD card storage
- PWM-based CPU voltage regulation
- UART (Serial console)
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
but omitted the specific chip sub-node due to lack of mainline drivers (yet).
- The console uses uart_b at 921600 baud.
- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
- Tested on the 2GB RAM plus 16GB EMMC variant.
.../devicetree/bindings/arm/amlogic.yaml | 7 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
3 files changed, 252 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..82671d58d1da 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -254,6 +254,13 @@ properties:
- khadas,vim1s
- const: amlogic,s905y4
- const: amlogic,s4
+
+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
+ items:
+ - enum:
+ - amediatech,x98q
+ - const: amlogic,s905w2
+ - const: amlogic,s4
- description: Boards with the Amlogic S6 S905X5 SoC
items:
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..6f0bdd5bdca2 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
new file mode 100644
index 000000000000..f2db01730a3d
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
@@ -0,0 +1,244 @@
+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
+ */
+
+/dts-v1/;
+
+#include "meson-s4.dtsi"
+
+/ {
+ model = "Shenzhen Amedia X98Q";
+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ mmc0 = &emmc; /* eMMC */
+ mmc1 = &sd; /* SD card */
+ mmc2 = &sdio; /* SDIO */
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 52 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ reg = <0x0 0x05000000 0x0 0x3400000>;
+ no-map;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_32k: sdio-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&sdio_32k>;
+ clock-names = "ext_clock";
+ };
+
+ main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ vddio_sd: regulator-vddio-sd {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <1800000 1
+ 3300000 0>;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_5v>;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ /* SY8120B1ABC DC/DC Regulator. */
+ vddcpu: regulator-vddcpu {
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <689000>;
+ regulator-max-microvolt = <1049000>;
+
+ vin-supply = <&main_5v>;
+
+ pwms = <&pwm_ij 1 1500 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ /* Voltage Duty-Cycle */
+ voltage-table = <1049000 0>,
+ <1039000 3>,
+ <1029000 6>,
+ <1019000 9>,
+ <1009000 12>,
+ <999000 14>,
+ <989000 17>,
+ <979000 20>,
+ <969000 23>,
+ <959000 26>,
+ <949000 29>,
+ <939000 31>,
+ <929000 34>,
+ <919000 37>,
+ <909000 40>,
+ <899000 43>,
+ <889000 45>,
+ <879000 48>,
+ <869000 51>,
+ <859000 54>,
+ <849000 56>,
+ <839000 59>,
+ <829000 62>,
+ <819000 65>,
+ <809000 68>,
+ <799000 70>,
+ <789000 73>,
+ <779000 76>,
+ <769000 79>,
+ <759000 81>,
+ <749000 84>,
+ <739000 87>,
+ <729000 89>,
+ <719000 92>,
+ <709000 95>,
+ <699000 98>,
+ <689000 100>;
+ };
+};
+
+&emmc {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins1>;
+ pinctrl-names = "default";
+};
+
+&pwm_ij {
+ status = "okay";
+};
+
+&sd {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+&sdio {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ no-sd;
+ no-mmc;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+&uart_b {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Ferass El Hafidi @ 2026-04-19 15:19 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260419150855.121136-1-christian.koever-draxl@student.uibk.ac.at>
Hi, some drive-by feedback
On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>Add the device tree for this board and document the compatible string.
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
>- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
> but omitted the specific chip sub-node due to lack of mainline drivers (yet).
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
>- Tested on the 2GB RAM plus 16GB EMMC variant.
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
> 3 files changed, 252 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
>index a885278bc4e2..82671d58d1da 100644
>--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
>+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
>@@ -254,6 +254,13 @@ properties:
> - khadas,vim1s
> - const: amlogic,s905y4
> - const: amlogic,s4
>+
>+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
>+ items:
>+ - enum:
>+ - amediatech,x98q
>+ - const: amlogic,s905w2
>+ - const: amlogic,s4
>
> - description: Boards with the Amlogic S6 S905X5 SoC
> items:
It is better to send the dt-binding changes separate from the actual
DTS. The golden rule is one commit per change.
You can (and should) send both patches as part of a patch series.
>diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
>index 15f9c817e502..6f0bdd5bdca2 100644
>--- a/arch/arm64/boot/dts/amlogic/Makefile
>+++ b/arch/arm64/boot/dts/amlogic/Makefile
>@@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
>+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
Keep this file in alphabetic order.
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
>diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>new file mode 100644
>index 000000000000..f2db01730a3d
>--- /dev/null
>+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>@@ -0,0 +1,244 @@
>+
>+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>+/*
>+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
>+ */
Did you base this DTS on another DTS that is already upstream? This
looks a lot like
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts?h=v7.1/arm64-dt
If so, then you should keep their copyright. Something like:
/*
* Copyright (c) 2026 Christian Stefan Köver-Draxl
* Based on <...>:
* - Copyright (c) <authors of the DTB this one is based on>
*/
Correct me if I'm wrong.
>+
>+/dts-v1/;
>+
>+#include "meson-s4.dtsi"
>+
>+/ {
>+ model = "Shenzhen Amedia X98Q";
Shouldn't this be
model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
?
There are other Amediatech boards supported currently:
dts/amlogic/meson-g12a-x96-max.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Max";
dts/amlogic/meson-sm1-x96-air-gbit.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Air";
dts/amlogic/meson-sm1-x96-air.dts: model = "Shenzhen Amediatech Technology Co., Ltd X96 Air";
I think it might be preferable to use a similar model format for
consistency.
It is also the documented vendor prefix for amediatech. (see
Documentation/devicetree/bindings/vendor-prefixes.yaml)
>+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
>+ interrupt-parent = <&gic>;
>+ #address-cells = <2>;
>+ #size-cells = <2>;
>+
>+ aliases {
>+ mmc0 = &emmc; /* eMMC */
>+ mmc1 = &sd; /* SD card */
>+ mmc2 = &sdio; /* SDIO */
>+ serial0 = &uart_b;
>+ };
>+
>+ memory@0 {
>+ device_type = "memory";
>+ reg = <0x0 0x0 0x0 0x40000000>;
>+ };
>+
>+ reserved-memory {
>+ #address-cells = <2>;
>+ #size-cells = <2>;
>+ ranges;
>+
>+ /* 52 MiB reserved for ARM Trusted Firmware */
>+ secmon_reserved: secmon@5000000 {
>+ reg = <0x0 0x05000000 0x0 0x3400000>;
>+ no-map;
>+ };
>+ };
>+
>+ emmc_pwrseq: emmc-pwrseq {
>+ compatible = "mmc-pwrseq-emmc";
>+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
>+ };
>+
>+ sdio_32k: sdio-32k {
>+ compatible = "pwm-clock";
>+ #clock-cells = <0>;
>+ clock-frequency = <32768>;
>+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
>+ };
>+
>+ sdio_pwrseq: sdio-pwrseq {
>+ compatible = "mmc-pwrseq-simple";
>+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
>+ clocks = <&sdio_32k>;
>+ clock-names = "ext_clock";
>+ };
>+
>+ main_5v: regulator-main-5v {
>+ compatible = "regulator-fixed";
>+ regulator-name = "5V";
>+ regulator-min-microvolt = <5000000>;
>+ regulator-max-microvolt = <5000000>;
>+ regulator-always-on;
>+ };
>+
>+ sd_3v3: regulator-sd-3v3 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "SD_3V3";
>+ regulator-min-microvolt = <3300000>;
>+ regulator-max-microvolt = <3300000>;
>+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
>+ regulator-always-on;
>+ };
>+
>+ vddio_sd: regulator-vddio-sd {
>+ compatible = "regulator-gpio";
>+ regulator-name = "VDDIO_SD";
>+ regulator-min-microvolt = <1800000>;
>+ regulator-max-microvolt = <3300000>;
>+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
>+ gpios-states = <1>;
>+ states = <1800000 1
>+ 3300000 0>;
nit: keep this in one line.
>+ };
>+
>+ vddao_3v3: regulator-vddao-3v3 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "VDDAO_3V3";
>+ regulator-min-microvolt = <3300000>;
>+ regulator-max-microvolt = <3300000>;
>+ vin-supply = <&main_5v>;
>+ regulator-always-on;
>+ };
>+
>+ vddio_ao1v8: regulator-vddio-ao1v8 {
>+ compatible = "regulator-fixed";
>+ regulator-name = "VDDIO_AO1V8";
>+ regulator-min-microvolt = <1800000>;
>+ regulator-max-microvolt = <1800000>;
>+ vin-supply = <&vddao_3v3>;
>+ regulator-always-on;
>+ };
>+
>+ /* SY8120B1ABC DC/DC Regulator. */
>+ vddcpu: regulator-vddcpu {
>+ compatible = "pwm-regulator";
>+
>+ regulator-name = "VDDCPU";
>+ regulator-min-microvolt = <689000>;
>+ regulator-max-microvolt = <1049000>;
>+
>+ vin-supply = <&main_5v>;
>+
>+ pwms = <&pwm_ij 1 1500 0>;
>+ pwm-dutycycle-range = <100 0>;
>+
>+ regulator-boot-on;
>+ regulator-always-on;
>+ /* Voltage Duty-Cycle */
>+ voltage-table = <1049000 0>,
>+ <1039000 3>,
>+ <1029000 6>,
>+ <1019000 9>,
>+ <1009000 12>,
>+ <999000 14>,
>+ <989000 17>,
>+ <979000 20>,
>+ <969000 23>,
>+ <959000 26>,
>+ <949000 29>,
>+ <939000 31>,
>+ <929000 34>,
>+ <919000 37>,
>+ <909000 40>,
>+ <899000 43>,
>+ <889000 45>,
>+ <879000 48>,
>+ <869000 51>,
>+ <859000 54>,
>+ <849000 56>,
>+ <839000 59>,
>+ <829000 62>,
>+ <819000 65>,
>+ <809000 68>,
>+ <799000 70>,
>+ <789000 73>,
>+ <779000 76>,
>+ <769000 79>,
>+ <759000 81>,
>+ <749000 84>,
>+ <739000 87>,
>+ <729000 89>,
>+ <719000 92>,
>+ <709000 95>,
>+ <699000 98>,
>+ <689000 100>;
>+ };
>+};
>+
>+&emmc {
>+ status = "okay";
>+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
>+ pinctrl-1 = <&emmc_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+
>+ bus-width = <8>;
>+ cap-mmc-highspeed;
>+ mmc-ddr-1_8v;
>+ mmc-hs200-1_8v;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ mmc-pwrseq = <&emmc_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
>+
>+ðmac {
>+ status = "okay";
>+ phy-handle = <&internal_ephy>;
>+ phy-mode = "rmii";
>+};
>+
>+&ir {
>+ status = "okay";
>+ pinctrl-0 = <&remote_pins>;
>+ pinctrl-names = "default";
>+};
>+
>+&pwm_ef {
>+ status = "okay";
>+ pinctrl-0 = <&pwm_e_pins1>;
>+ pinctrl-names = "default";
>+};
>+
>+&pwm_ij {
>+ status = "okay";
>+};
>+
>+&sd {
>+ status = "okay";
>+ pinctrl-0 = <&sdcard_pins>;
>+ pinctrl-1 = <&sdcard_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ max-frequency = <50000000>;
>+ disable-wp;
>+
>+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
>+
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddao_3v3>;
>+};
>+
>+&sdio {
>+ status = "okay";
>+ pinctrl-0 = <&sdio_pins>;
>+ pinctrl-1 = <&sdio_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ sd-uhs-sdr50;
>+ sd-uhs-sdr104;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ no-sd;
>+ no-mmc;
>+ mmc-pwrseq = <&sdio_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
I suppose that's the Wi-Fi module you're talking about. I would put a comment
above to specify that it is indeed Wi-Fi and not yet supported.
Something like:
/*
* Wireless SDIO Module (Amlogic W150S1)
* Note: There is no driver for this at the moment.
*/
>+
>+&uart_b {
>+ status = "okay";
>+};
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Ferass El Hafidi @ 2026-04-19 15:42 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, neil.armstrong, khilman
Cc: linux-amlogic, devicetree, linux-arm-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260419150855.121136-1-christian.koever-draxl@student.uibk.ac.at>
On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>Add the device tree for this board and document the compatible string.
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
>- The Wi-Fi chip on this board is Amlogic W150S1. I have left the SDIO node enabled
> but omitted the specific chip sub-node due to lack of mainline drivers (yet).
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB if board supports more than 1GB.
>- Tested on the 2GB RAM plus 16GB EMMC variant.
>
Also, I just noticed now, but you seem to be missing a lot of people in
your To/Cc. You should use get_maintainer.pl to get the list of
the people you should send your patch to.
(you can also use b4 (v0.14 is what I use) to make sending patches
properly much easier)
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()
From: Simon Horman @ 2026-04-19 16:12 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260416-airoha-txq-potential-stall-v2-1-42c732074540@kernel.org>
On Thu, Apr 16, 2026 at 12:30:12PM +0200, Lorenzo Bianconi wrote:
> Since multiple net_device TX queues can share the same hw QDMA TX queue,
> there is no guarantee we have inflight packets queued in hw belonging to a
> net_device TX queue stopped in the xmit path because hw QDMA TX queue
> can be full. In this corner case the net_device TX queue will never be
> re-activated. In order to avoid any potential net_device TX queue stall,
> we need to wake all the net_device TX queues feeding the same hw QDMA TX
> queue in airoha_qdma_tx_napi_poll routine.
>
> Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> Changes in v2:
> - Add txq_stopped parameter to avoid any possible corner cases where the
> netdev queue stalls.
> - Link to v1: https://lore.kernel.org/r/20260413-airoha-txq-potential-stall-v1-1-7830363b1543@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
FTR, I believe Sashiko's review does not need to block progress of this
patch as it flags pre-existing conditions.
^ permalink raw reply
* Re: [PATCH v7 3/4] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
From: Marc Zyngier @ 2026-04-19 17:19 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260418-hybrid-v7-3-2bf39ad009bf@rsg.ci.i.u-tokyo.ac.jp>
On Sat, 18 Apr 2026 09:14:25 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> On a heterogeneous arm64 system, KVM's PMU emulation is based on the
> features of a single host PMU instance. When a vCPU is migrated to a
> pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
> incrementing.
>
> Although this behavior is permitted by the architecture, Windows does
> not handle it gracefully and may crash with a division-by-zero error.
>
> The current workaround requires VMMs to pin vCPUs to a set of pCPUs
> that share a compatible PMU. This is difficult to implement correctly in
> QEMU/libvirt, where pinning occurs after vCPU initialization, and it
> also restricts the guest to a subset of available pCPUs.
>
> Introduce the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY attribute to
> create a "fixed-counters-only" PMU. When set, KVM exposes a PMU that is
> compatible with all pCPUs but that does not support programmable
> event counters which may have different feature sets on different PMUs.
>
> This allows Windows guests to run reliably on heterogeneous systems
> without crashing, even without vCPU pinning, and enables VMMs to
> schedule vCPUs across all available pCPUs, making full use of the host
> hardware.
>
> Much like KVM_ARM_VCPU_PMU_V3_IRQ and other read-write attributes, this
> attribute provides a getter that facilitates kernel and userspace
> debugging/testing.
OK, so that's the sales pitch. But how is it implemented? I would like
to be able to read a high-level description of the implementation
trade-offs.
>
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> Documentation/virt/kvm/devices/vcpu.rst | 29 ++++++
> arch/arm64/include/asm/kvm_host.h | 2 +
> arch/arm64/include/uapi/asm/kvm.h | 1 +
> arch/arm64/kvm/arm.c | 1 +
> arch/arm64/kvm/pmu-emul.c | 155 +++++++++++++++++++++++---------
> include/kvm/arm_pmu.h | 2 +
> 6 files changed, 147 insertions(+), 43 deletions(-)
>
> diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> index 60bf205cb373..e0aeb1897d77 100644
> --- a/Documentation/virt/kvm/devices/vcpu.rst
> +++ b/Documentation/virt/kvm/devices/vcpu.rst
> @@ -161,6 +161,35 @@ explicitly selected, or the number of counters is out of range for the
> selected PMU. Selecting a new PMU cancels the effect of setting this
> attribute.
>
> +1.6 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
> +------------------------------------------------------
> +
> +:Parameters: no additional parameter in kvm_device_attr.addr
> +
> +:Returns:
> +
> + ======= =====================================================
> + -EBUSY Attempted to set after initializing PMUv3 or running
> + VCPU, or attempted to set for the first time after
> + setting an event filter
> + -ENXIO Attempted to get before setting
> + -ENODEV Attempted to set while PMUv3 not supported
> + ======= =====================================================
> +
> +If set, PMUv3 will be emulated without programmable event counters. The VCPU
> +will use any compatible hardware PMU. This attribute is particularly useful on
Not quite "any PMU". It will use *the* PMU of the physical CPU,
irrespective of the implementation.
> +heterogeneous systems where different hardware PMUs cover different physical
> +CPUs. The compatibility of hardware PMUs can be checked with
> +KVM_ARM_VCPU_PMU_V3_SET_PMU. All VCPUs in a VM share this attribute. It isn't
> +possible to set it for the first time if a PMU event filter is already present.
"for the first time" gives the impression that it will work if you try
again. I'd rather we say that "This feature is incompatible with the
existence of a PMU event filter".
Furthermore, the architecture currently describes *two* fixed-function
counters (cycles and instructions), while KVM only expose the cycle
counter. I'm all for the extra abstraction, but what does it mean for
migration if we enable FEAT_PMUv3_ICNTR?
> +
> +Note that KVM will not make any attempts to run the VCPU on the physical CPUs
> +with compatible hardware PMUs. This is entirely left to userspace. However,
> +attempting to run the VCPU on an unsupported CPU will fail and KVM_RUN will
> +return with exit_reason = KVM_EXIT_FAIL_ENTRY and populate the fail_entry struct
> +by setting hardware_entry_failure_reason field to
> +KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED and the cpu field to the processor id.
> +
This is mostly a copy-paste of the previous section. How relevant is
this to the fixed-counters-only feature? If the whole point of this
stuff is to ensure compatibility across CPUs with different PMU
implementations, surely what you describe here is the opposite of what
you want.
My preference would be to move this to a separate patch in any case,
more on that below.
> 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL
> =================================
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 59f25b85be2b..b59e0182472c 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -353,6 +353,8 @@ struct kvm_arch {
> #define KVM_ARCH_FLAG_WRITABLE_IMP_ID_REGS 10
> /* Unhandled SEAs are taken to userspace */
> #define KVM_ARCH_FLAG_EXIT_SEA 11
> + /* PMUv3 is emulated without progammable event counters */
> +#define KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY 12
> unsigned long flags;
>
> /* VM-wide vCPU feature set */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index a792a599b9d6..474c84fa757f 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -436,6 +436,7 @@ enum {
> #define KVM_ARM_VCPU_PMU_V3_FILTER 2
> #define KVM_ARM_VCPU_PMU_V3_SET_PMU 3
> #define KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS 4
> +#define KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY 5
> #define KVM_ARM_VCPU_TIMER_CTRL 1
> #define KVM_ARM_VCPU_TIMER_IRQ_VTIMER 0
> #define KVM_ARM_VCPU_TIMER_IRQ_PTIMER 1
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 620a465248d1..dca16ca26d32 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -634,6 +634,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> if (has_vhe())
> kvm_vcpu_load_vhe(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> + kvm_vcpu_load_pmu(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> if (kvm_arm_is_pvtime_enabled(&vcpu->arch))
> kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index ef5140bbfe28..d1009c144581 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -326,7 +326,10 @@ u64 kvm_pmu_implemented_counter_mask(struct kvm_vcpu *vcpu)
>
> static void kvm_pmc_enable_perf_event(struct kvm_pmc *pmc)
> {
> - if (!pmc->perf_event) {
> + struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
> +
> + if (!pmc->perf_event ||
> + !cpumask_test_cpu(vcpu->cpu, &to_arm_pmu(pmc->perf_event->pmu)->supported_cpus)) {
> kvm_pmu_create_perf_event(pmc);
> return;
> }
> @@ -667,10 +670,8 @@ static bool kvm_pmc_counts_at_el2(struct kvm_pmc *pmc)
> return kvm_pmc_read_evtreg(pmc) & ARMV8_PMU_INCLUDE_EL2;
> }
>
> -static int kvm_map_pmu_event(struct kvm *kvm, unsigned int eventsel)
> +static int kvm_map_pmu_event(struct arm_pmu *pmu, unsigned int eventsel)
> {
> - struct arm_pmu *pmu = kvm->arch.arm_pmu;
> -
> /*
> * The CPU PMU likely isn't PMUv3; let the driver provide a mapping
> * for the guest's PMUv3 event ID.
This refactor should be in its own patch. This sort of minor change is
adding noise to the mean of the patch, for no good reason.
> @@ -681,6 +682,23 @@ static int kvm_map_pmu_event(struct kvm *kvm, unsigned int eventsel)
> return eventsel;
> }
>
> +static struct arm_pmu *kvm_pmu_probe_armpmu(int cpu)
> +{
> + struct arm_pmu_entry *entry;
> + struct arm_pmu *pmu;
> +
> + guard(rcu)();
> +
> + list_for_each_entry_rcu(entry, &arm_pmus, entry) {
> + pmu = entry->arm_pmu;
> +
> + if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
> + return pmu;
> + }
> +
> + return NULL;
> +}
> +
> /**
> * kvm_pmu_create_perf_event - create a perf event for a counter
> * @pmc: Counter context
> @@ -694,6 +712,12 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> int eventsel;
> u64 evtreg;
>
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags)) {
> + arm_pmu = kvm_pmu_probe_armpmu(vcpu->cpu);
> + if (!arm_pmu)
> + return;
How is it possible to not get a PMU here? We don't expose the PMU to a
guest at all if there are CPUs without PMUs, see the comment in
kvm_host_pmu_init(). So I'd expect this to never fail.
> + }
> +
> evtreg = kvm_pmc_read_evtreg(pmc);
>
> kvm_pmu_stop_counter(pmc);
> @@ -722,7 +746,7 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> * Don't create an event if we're running on hardware that requires
> * PMUv3 event translation and we couldn't find a valid mapping.
> */
> - eventsel = kvm_map_pmu_event(vcpu->kvm, eventsel);
> + eventsel = kvm_map_pmu_event(arm_pmu, eventsel);
> if (eventsel < 0)
> return;
>
> @@ -810,42 +834,6 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
> list_add_tail_rcu(&entry->entry, &arm_pmus);
> }
>
> -static struct arm_pmu *kvm_pmu_probe_armpmu(void)
> -{
> - struct arm_pmu_entry *entry;
> - struct arm_pmu *pmu;
> - int cpu;
> -
> - guard(rcu)();
> -
> - /*
> - * It is safe to use a stale cpu to iterate the list of PMUs so long as
> - * the same value is used for the entirety of the loop. Given this, and
> - * the fact that no percpu data is used for the lookup there is no need
> - * to disable preemption.
> - *
> - * It is still necessary to get a valid cpu, though, to probe for the
> - * default PMU instance as userspace is not required to specify a PMU
> - * type. In order to uphold the preexisting behavior KVM selects the
> - * PMU instance for the core during vcpu init. A dependent use
> - * case would be a user with disdain of all things big.LITTLE that
> - * affines the VMM to a particular cluster of cores.
> - *
> - * In any case, userspace should just do the sane thing and use the UAPI
> - * to select a PMU type directly. But, be wary of the baggage being
> - * carried here.
> - */
> - cpu = raw_smp_processor_id();
> - list_for_each_entry_rcu(entry, &arm_pmus, entry) {
> - pmu = entry->arm_pmu;
> -
> - if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
> - return pmu;
> - }
> -
> - return NULL;
> -}
> -
Same thing for the refactoring of this function. Moving it, changing
the signature and moving the comment somewhere else would be better
placed on its own.
> static u64 __compute_pmceid(struct arm_pmu *pmu, bool pmceid1)
> {
> u32 hi[2], lo[2];
> @@ -888,6 +876,9 @@ u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
> u64 val, mask = 0;
> int base, i, nr_events;
>
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags))
> + return 0;
> +
> if (!pmceid1) {
> val = compute_pmceid0(cpu_pmu);
> base = 0;
> @@ -915,6 +906,26 @@ u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
> return val & mask;
> }
>
> +void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu)
> +{
> + unsigned long mask = kvm_pmu_enabled_counter_mask(vcpu);
> + struct kvm_pmc *pmc;
> + struct arm_pmu *cpu_pmu;
Move these to be inside the loop.
> + int i;
> +
> + for_each_set_bit(i, &mask, 32) {
> + pmc = kvm_vcpu_idx_to_pmc(vcpu, i);
> + if (!pmc->perf_event)
> + continue;
> +
> + cpu_pmu = to_arm_pmu(pmc->perf_event->pmu);
> + if (!cpumask_test_cpu(vcpu->cpu, &cpu_pmu->supported_cpus)) {
> + kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
> + break;
> + }
> + }
> +}
> +
Why do we need to inflict this on VMs that do not have the fixed
counter restriction?
And even then, all you have to reconfigure is the cycle counter. So
why the loop? All we want to find out is whether the cycle counter is
instantiated on the PMU that matches the current CPU.
> void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu)
> {
> u64 mask = kvm_pmu_implemented_counter_mask(vcpu);
> @@ -1016,6 +1027,9 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
> {
> struct arm_pmu *arm_pmu = kvm->arch.arm_pmu;
>
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags))
> + return 0;
> +
> /*
> * PMUv3 requires that all event counters are capable of counting any
> * event, though the same may not be true of non-PMUv3 hardware.
> @@ -1070,7 +1084,24 @@ static void kvm_arm_set_pmu(struct kvm *kvm, struct arm_pmu *arm_pmu)
> */
> int kvm_arm_set_default_pmu(struct kvm *kvm)
> {
> - struct arm_pmu *arm_pmu = kvm_pmu_probe_armpmu();
> + /*
> + * It is safe to use a stale cpu to iterate the list of PMUs so long as
> + * the same value is used for the entirety of the loop. Given this, and
> + * the fact that no percpu data is used for the lookup there is no need
> + * to disable preemption.
> + *
> + * It is still necessary to get a valid cpu, though, to probe for the
> + * default PMU instance as userspace is not required to specify a PMU
> + * type. In order to uphold the preexisting behavior KVM selects the
> + * PMU instance for the core during vcpu init. A dependent use
> + * case would be a user with disdain of all things big.LITTLE that
> + * affines the VMM to a particular cluster of cores.
> + *
> + * In any case, userspace should just do the sane thing and use the UAPI
> + * to select a PMU type directly. But, be wary of the baggage being
> + * carried here.
> + */
> + struct arm_pmu *arm_pmu = kvm_pmu_probe_armpmu(raw_smp_processor_id());
>
> if (!arm_pmu)
> return -ENODEV;
> @@ -1098,6 +1129,7 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
> break;
> }
>
> + clear_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags);
Why does this need to be cleared? I'd rather we make sure it is never
set the first place.
> kvm_arm_set_pmu(kvm, arm_pmu);
> cpumask_copy(kvm->arch.supported_cpus, &arm_pmu->supported_cpus);
> ret = 0;
> @@ -1108,11 +1140,42 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
> return ret;
> }
>
> +static int kvm_arm_pmu_v3_set_pmu_fixed_counters_only(struct kvm_vcpu *vcpu)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct arm_pmu_entry *entry;
> + struct arm_pmu *arm_pmu;
> + struct cpumask *supported_cpus = kvm->arch.supported_cpus;
> +
> + lockdep_assert_held(&kvm->arch.config_lock);
> +
> + if (kvm_vm_has_ran_once(kvm) ||
> + (kvm->arch.pmu_filter &&
> + !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags)))
> + return -EBUSY;
> +
> + set_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags);
> + kvm_arm_set_nr_counters(kvm, 0);
> + cpumask_clear(supported_cpus);
What is the purpose of this cpumask_clear()? Under what conditions can
you have something else?
> +
> + guard(rcu)();
> +
> + list_for_each_entry_rcu(entry, &arm_pmus, entry) {
> + arm_pmu = entry->arm_pmu;
> + cpumask_or(supported_cpus, supported_cpus, &arm_pmu->supported_cpus);
Why isn't supported_cpus directly set to possible_cpus? Isn't that the
base requirement that you can run on any CPU at all?
> + }
> +
> + return 0;
> +}
> +
> static int kvm_arm_pmu_v3_set_nr_counters(struct kvm_vcpu *vcpu, unsigned int n)
> {
> struct kvm *kvm = vcpu->kvm;
>
> - if (!kvm->arch.arm_pmu)
> + lockdep_assert_held(&kvm->arch.config_lock);
> +
> + if (!kvm->arch.arm_pmu &&
> + !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags))
> return -EINVAL;
>
> if (n > kvm_arm_pmu_get_max_counters(kvm))
> @@ -1227,6 +1290,8 @@ int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
>
> return kvm_arm_pmu_v3_set_nr_counters(vcpu, n);
> }
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> + return kvm_arm_pmu_v3_set_pmu_fixed_counters_only(vcpu);
> case KVM_ARM_VCPU_PMU_V3_INIT:
> return kvm_arm_pmu_v3_init(vcpu);
> }
> @@ -1253,6 +1318,9 @@ int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> irq = vcpu->arch.pmu.irq_num;
> return put_user(irq, uaddr);
> }
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags))
With 6 occurrences of this test_bit(), it feels like it'd be valuable
to have a dedicate predicate to help with readability.
> + return 0;
> }
>
> return -ENXIO;
> @@ -1266,6 +1334,7 @@ int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> case KVM_ARM_VCPU_PMU_V3_FILTER:
> case KVM_ARM_VCPU_PMU_V3_SET_PMU:
> case KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS:
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> if (kvm_vcpu_has_pmu(vcpu))
> return 0;
> }
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 96754b51b411..1375cbaf97b2 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -56,6 +56,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> +void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu);
> void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu);
> int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
> struct kvm_device_attr *attr);
> @@ -161,6 +162,7 @@ static inline u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
> static inline void kvm_pmu_update_vcpu_events(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_pmu_restore_guest(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_pmu_restore_host(struct kvm_vcpu *vcpu) {}
> +static inline void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu) {}
> static inline u8 kvm_arm_pmu_get_pmuver_limit(void)
> {
>
In conclusion, I find this patch to be rather messy. For a start, it
needs to be split in at least 5 patches:
- at least two for the refactoring
- one for the PMU core changes
- one for the UAPI
- one for documentation
I'd also like some clarification on how this is intended to work if we
enable FEAT_PMUv3_ICNTR, because the definition seems to be designed
to encompass all fixed-function counters, and I expect this to grow
over time.
I'm also not planning to look at the selftest at this stage.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: add support for Amedia X98Q
From: Christian Stefan Köver-Draxl @ 2026-04-19 17:59 UTC (permalink / raw)
To: Ferass El Hafidi, linux-amlogic, neil.armstrong, khilman
Cc: devicetree, linux-arm-kernel
In-Reply-To: <tdqzjg.e0dtukngm56y@postmarketos.org>
On 4/19/26 17:19, Ferass El Hafidi wrote:
> Hi, some drive-by feedback
>
> On Sun, 19 Apr 2026 15:08, christian.koever-draxl@student.uibk.ac.at
> wrote:
>> From: Christian Stefan Kövér-Draxl
>> <christian.koever-draxl@student.uibk.ac.at>
>>
>> The X98Q is a TV box based on the Amlogic S4 (S905W2) SoC.
>> Add the device tree for this board and document the compatible string.
>>
>> Supported features:
>> - 1GB/2GB RAM (via U-Boot memory fixup)
>> - 10/100 Ethernet (Internal PHY)
>> - eMMC and SD card storage
>> - PWM-based CPU voltage regulation
>> - UART (Serial console)
>>
>> Signed-off-by: Christian Stefan Kövér-Draxl
>> <christian.koever-draxl@student.uibk.ac.at>
>> ---
>> - The Wi-Fi chip on this board is Amlogic W150S1. I have left the
>> SDIO node enabled
>> but omitted the specific chip sub-node due to lack of mainline
>> drivers (yet).
>> - The console uses uart_b at 921600 baud.
>> - Verified memory via /proc/device-tree; U-Boot patches the node to
>> around 2GB if board supports more than 1GB.
>> - Tested on the 2GB RAM plus 16GB EMMC variant.
>>
>> .../devicetree/bindings/arm/amlogic.yaml | 7 +
>> arch/arm64/boot/dts/amlogic/Makefile | 1 +
>> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 244 ++++++++++++++++++
>> 3 files changed, 252 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml
>> b/Documentation/devicetree/bindings/arm/amlogic.yaml
>> index a885278bc4e2..82671d58d1da 100644
>> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
>> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
>> @@ -254,6 +254,13 @@ properties:
>> - khadas,vim1s
>> - const: amlogic,s905y4
>> - const: amlogic,s4
>> + + - description: Boards with the Amlogic Meson S4 S905W2 SoC
>> + items:
>> + - enum:
>> + - amediatech,x98q
>> + - const: amlogic,s905w2
>> + - const: amlogic,s4
>>
>> - description: Boards with the Amlogic S6 S905X5 SoC
>> items:
>
> It is better to send the dt-binding changes separate from the actual
> DTS. The golden rule is one commit per change.
>
> You can (and should) send both patches as part of a patch series.
Thanks for the Review! I have split this for v2.
>
>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile
>> b/arch/arm64/boot/dts/amlogic/Makefile
>> index 15f9c817e502..6f0bdd5bdca2 100644
>> --- a/arch/arm64/boot/dts/amlogic/Makefile
>> +++ b/arch/arm64/boot/dts/amlogic/Makefile
>> @@ -86,6 +86,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
>> +dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
>
> Keep this file in alphabetic order.
Thanks, i have fixed it!
>
>> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>> b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>> new file mode 100644
>> index 000000000000..f2db01730a3d
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>> @@ -0,0 +1,244 @@
>> +
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2026 Christian Stefan Köver-Draxl
>> + */
>
> Did you base this DTS on another DTS that is already upstream? This
> looks a lot like
> https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts?h=v7.1/arm64-dt
>
>
> If so, then you should keep their copyright. Something like:
>
> /*
> * Copyright (c) 2026 Christian Stefan Köver-Draxl
> * Based on <...>:
> * - Copyright (c) <authors of the DTB this one is based on>
> */
>
> Correct me if I'm wrong.
Yes, I used the VIM1S as a base. I will update the copyright header to
include the original authors.
>
>> +
>> +/dts-v1/;
>> +
>> +#include "meson-s4.dtsi"
>> +
>> +/ {
>> + model = "Shenzhen Amedia X98Q";
>
> Shouldn't this be
> model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
> ?
>
> There are other Amediatech boards supported currently:
>
> dts/amlogic/meson-g12a-x96-max.dts: model = "Shenzhen Amediatech
> Technology Co., Ltd X96 Max";
> dts/amlogic/meson-sm1-x96-air-gbit.dts: model = "Shenzhen Amediatech
> Technology Co., Ltd X96 Air";
> dts/amlogic/meson-sm1-x96-air.dts: model = "Shenzhen Amediatech
> Technology Co., Ltd X96 Air";
>
> I think it might be preferable to use a similar model format for
> consistency.
>
> It is also the documented vendor prefix for amediatech. (see
> Documentation/devicetree/bindings/vendor-prefixes.yaml)
I have updated the vendor prefix accordingly.
>
>> + compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
>> + interrupt-parent = <&gic>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + aliases {
>> + mmc0 = &emmc; /* eMMC */
>> + mmc1 = &sd; /* SD card */
>> + mmc2 = &sdio; /* SDIO */
>> + serial0 = &uart_b;
>> + };
>> +
>> + memory@0 {
>> + device_type = "memory";
>> + reg = <0x0 0x0 0x0 0x40000000>;
>> + };
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + /* 52 MiB reserved for ARM Trusted Firmware */
>> + secmon_reserved: secmon@5000000 {
>> + reg = <0x0 0x05000000 0x0 0x3400000>;
>> + no-map;
>> + };
>> + };
>> +
>> + emmc_pwrseq: emmc-pwrseq {
>> + compatible = "mmc-pwrseq-emmc";
>> + reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + sdio_32k: sdio-32k {
>> + compatible = "pwm-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <32768>;
>> + pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
>> + };
>> +
>> + sdio_pwrseq: sdio-pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
>> + clocks = <&sdio_32k>;
>> + clock-names = "ext_clock";
>> + };
>> +
>> + main_5v: regulator-main-5v {
>> + compatible = "regulator-fixed";
>> + regulator-name = "5V";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + };
>> +
>> + sd_3v3: regulator-sd-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "SD_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
>> + regulator-always-on;
>> + };
>> +
>> + vddio_sd: regulator-vddio-sd {
>> + compatible = "regulator-gpio";
>> + regulator-name = "VDDIO_SD";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
>> + gpios-states = <1>;
>> + states = <1800000 1
>> + 3300000 0>;
>
> nit: keep this in one line.
Done for v2!
BTW: I applied this part from the VIM1S. So maybe that dts needs to be
adjusted too in the future.
>
>> + };
>> +
>> + vddao_3v3: regulator-vddao-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VDDAO_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + vin-supply = <&main_5v>;
>> + regulator-always-on;
>> + };
>> +
>> + vddio_ao1v8: regulator-vddio-ao1v8 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VDDIO_AO1V8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + vin-supply = <&vddao_3v3>;
>> + regulator-always-on;
>> + };
>> +
>> + /* SY8120B1ABC DC/DC Regulator. */
>> + vddcpu: regulator-vddcpu {
>> + compatible = "pwm-regulator";
>> +
>> + regulator-name = "VDDCPU";
>> + regulator-min-microvolt = <689000>;
>> + regulator-max-microvolt = <1049000>;
>> +
>> + vin-supply = <&main_5v>;
>> +
>> + pwms = <&pwm_ij 1 1500 0>;
>> + pwm-dutycycle-range = <100 0>;
>> +
>> + regulator-boot-on;
>> + regulator-always-on;
>> + /* Voltage Duty-Cycle */
>> + voltage-table = <1049000 0>,
>> + <1039000 3>,
>> + <1029000 6>,
>> + <1019000 9>,
>> + <1009000 12>,
>> + <999000 14>,
>> + <989000 17>,
>> + <979000 20>,
>> + <969000 23>,
>> + <959000 26>,
>> + <949000 29>,
>> + <939000 31>,
>> + <929000 34>,
>> + <919000 37>,
>> + <909000 40>,
>> + <899000 43>,
>> + <889000 45>,
>> + <879000 48>,
>> + <869000 51>,
>> + <859000 54>,
>> + <849000 56>,
>> + <839000 59>,
>> + <829000 62>,
>> + <819000 65>,
>> + <809000 68>,
>> + <799000 70>,
>> + <789000 73>,
>> + <779000 76>,
>> + <769000 79>,
>> + <759000 81>,
>> + <749000 84>,
>> + <739000 87>,
>> + <729000 89>,
>> + <719000 92>,
>> + <709000 95>,
>> + <699000 98>,
>> + <689000 100>;
>> + };
>> +};
>> +
>> +&emmc {
>> + status = "okay";
>> + pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
>> + pinctrl-1 = <&emmc_clk_gate_pins>;
>> + pinctrl-names = "default", "clk-gate";
>> +
>> + bus-width = <8>;
>> + cap-mmc-highspeed;
>> + mmc-ddr-1_8v;
>> + mmc-hs200-1_8v;
>> + max-frequency = <200000000>;
>> + non-removable;
>> + disable-wp;
>> +
>> + mmc-pwrseq = <&emmc_pwrseq>;
>> + vmmc-supply = <&vddao_3v3>;
>> + vqmmc-supply = <&vddio_ao1v8>;
>> +};
>> +
>> +ðmac {
>> + status = "okay";
>> + phy-handle = <&internal_ephy>;
>> + phy-mode = "rmii";
>> +};
>> +
>> +&ir {
>> + status = "okay";
>> + pinctrl-0 = <&remote_pins>;
>> + pinctrl-names = "default";
>> +};
>> +
>> +&pwm_ef {
>> + status = "okay";
>> + pinctrl-0 = <&pwm_e_pins1>;
>> + pinctrl-names = "default";
>> +};
>> +
>> +&pwm_ij {
>> + status = "okay";
>> +};
>> +
>> +&sd {
>> + status = "okay";
>> + pinctrl-0 = <&sdcard_pins>;
>> + pinctrl-1 = <&sdcard_clk_gate_pins>;
>> + pinctrl-names = "default", "clk-gate";
>> + bus-width = <4>;
>> + cap-sd-highspeed;
>> + max-frequency = <50000000>;
>> + disable-wp;
>> +
>> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
>> +
>> + vmmc-supply = <&vddao_3v3>;
>> + vqmmc-supply = <&vddao_3v3>;
>> +};
>> +
>> +&sdio {
>> + status = "okay";
>> + pinctrl-0 = <&sdio_pins>;
>> + pinctrl-1 = <&sdio_clk_gate_pins>;
>> + pinctrl-names = "default", "clk-gate";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + bus-width = <4>;
>> + cap-sd-highspeed;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> + max-frequency = <200000000>;
>> + non-removable;
>> + disable-wp;
>> +
>> + no-sd;
>> + no-mmc;
>> + mmc-pwrseq = <&sdio_pwrseq>;
>> + vmmc-supply = <&vddao_3v3>;
>> + vqmmc-supply = <&vddio_ao1v8>;
>> +};
>
> I suppose that's the Wi-Fi module you're talking about. I would put a
> comment
> above to specify that it is indeed Wi-Fi and not yet supported.
>
> Something like:
>
> /*
> * Wireless SDIO Module (Amlogic W150S1)
> * Note: There is no driver for this at the moment.
> */
>
Yes that makes sense. I will add that.
>> +
>> +&uart_b {
>> + status = "okay";
>> +};
>> --
>> 2.53.0
>
> --
> Best regards,
> Ferass
Thanks again,
Christian
^ permalink raw reply
* [PATCH 0/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD SoC and Geist board
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a register-compatible
variant of the R8A77965 (M3-N) with reduced set of peripherals. Add support
for the Geist board based on the Renesas R-Car R8A779MD (M3Le).
The DU part does probe, and to the best of my knowledge, should correctly
describe the hardware, but is otherwise untested due to no remote display
access. Note that the DU uses ports 0 and 2, which is unusual.
VIN is also untested due to no remote hardware access.
Marek Vasut (5):
dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
drm/rcar-du: Add support for Renesas R-Car R8A779MD M3Le
dt-bindings: clock: cs2000-cp: document CS2500
dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
Nguyen Tran (2):
arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD
Geist
.../bindings/clock/cirrus,cs2000-cp.yaml | 10 +-
.../bindings/display/renesas,du.yaml | 70 ++
.../bindings/soc/renesas/renesas.yaml | 6 +
arch/arm64/boot/dts/renesas/Makefile | 3 +
.../dts/renesas/geist-panel-aa104xd12.dtso | 17 +
.../arm64/boot/dts/renesas/r8a779md-geist.dts | 832 ++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a779md.dtsi | 48 +
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 25 +
drivers/soc/renesas/renesas-soc.c | 1 +
9 files changed, 1009 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md-geist.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md.dtsi
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* [PATCH 2/7] drm/rcar-du: Add support for Renesas R-Car R8A779MD M3Le
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Add support the Renesas R-Car R8A779MD M3Le SoC. This SoC is
similar to R-Car R8A77965 M3-N SoC, except the HDMI port@1 is
not present.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
index 031d07f4508e9..be862b5524fd2 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
@@ -564,6 +564,30 @@ static const struct rcar_du_device_info rcar_du_r8a779h0_info = {
.dsi_clk_mask = BIT(0),
};
+static const struct rcar_du_device_info rcar_du_r8a779md_info = {
+ .gen = 3,
+ .features = RCAR_DU_FEATURE_CRTC_IRQ
+ | RCAR_DU_FEATURE_CRTC_CLOCK
+ | RCAR_DU_FEATURE_VSP1_SOURCE
+ | RCAR_DU_FEATURE_INTERLACED
+ | RCAR_DU_FEATURE_TVM_SYNC,
+ .channels_mask = BIT(1) | BIT(0),
+ .routes = {
+ /* R8A779MD has one RGB output and one LVDS output. */
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(1),
+ .port = 0,
+ },
+ [RCAR_DU_OUTPUT_LVDS0] = {
+ .possible_crtcs = BIT(0),
+ .port = 2,
+ },
+ },
+ .num_lvds = 1,
+ .num_rpf = 5,
+ .dpll_mask = BIT(1),
+};
+
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
@@ -591,6 +615,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a779a0", .data = &rcar_du_r8a779a0_info },
{ .compatible = "renesas,du-r8a779g0", .data = &rcar_du_r8a779g0_info },
{ .compatible = "renesas,du-r8a779h0", .data = &rcar_du_r8a779h0_info },
+ { .compatible = "renesas,du-r8a779md", .data = &rcar_du_r8a779md_info },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/7] dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Extend the Renesas DU display bindings to support the Renesas R-Car
R8A779MD M3Le SoC. This SoC is similar to R-Car R8A77965 M3-N SoC,
except the HDMI port@1 is not present.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../bindings/display/renesas,du.yaml | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
index c27dfea7fc622..3c3667ff4a27f 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -42,6 +42,7 @@ properties:
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
- renesas,du-r8a779g0 # for R-Car V4H compatible DU
- renesas,du-r8a779h0 # for R-Car V4M compatible DU
+ - renesas,du-r8a779md # for R-Car M3Le compatible DU
reg:
maxItems: 1
@@ -890,6 +891,75 @@ allOf:
- reset-names
- renesas,vsps
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,du-r8a779md
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ items:
+ - description: Functional clock for DU0
+ - description: Functional clock for DU1
+ - description: Functional clock for DU3
+ - description: DU_DOTCLKIN0 input clock
+ - description: DU_DOTCLKIN1 input clock
+ - description: DU_DOTCLKIN3 input clock
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: du.0
+ - const: du.1
+ - const: du.3
+ - pattern: '^dclkin\.[013]$'
+ - pattern: '^dclkin\.[013]$'
+ - pattern: '^dclkin\.[013]$'
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: du.0
+ - const: du.3
+
+ ports:
+ properties:
+ port@0:
+ description: DPAD 0
+ port@1: false
+ port@2:
+ description: LVDS 0
+ port@3: false
+
+ required:
+ - port@0
+ - port@2
+
+ renesas,cmms:
+ minItems: 3
+ maxItems: 3
+
+ renesas,vsps:
+ minItems: 3
+ maxItems: 3
+
+ required:
+ - clock-names
+ - interrupts
+ - resets
+ - reset-names
+ - renesas,vsps
+
additionalProperties: false
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH 3/7] dt-bindings: clock: cs2000-cp: document CS2500
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Document backward compatibility support for CS2500 chip, which
is a drop-in replacement for CS2000 chip.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index d416c374e8534..031c52b2e5cec 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -11,14 +11,18 @@ maintainers:
description: |
The CS2000-CP is an extremely versatile system clocking device that
- utilizes a programmable phase lock loop.
+ utilizes a programmable phase lock loop. CP2500-CP is a compatible
+ drop-in replacement for CP2000-CP.
Link: https://www.cirrus.com/products/cs2000/
properties:
compatible:
- enum:
- - cirrus,cs2000-cp
+ oneOf:
+ - items:
+ - const: cirrus,cs2500-cp
+ - const: cirrus,cs2000-cp
+ - const: cirrus,cs2000-cp
clocks:
description:
--
2.53.0
^ permalink raw reply related
* [PATCH 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
SoC and the Renesas Geist development board. The Renesas M3Le SoC is
a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals. The Geist board is derived from Renesas Salvator-X/XS
boards, with adjustment for the R8A779MD SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
Documentation/devicetree/bindings/soc/renesas/renesas.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
index 5c22c51b1533d..bda223237c812 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
@@ -473,6 +473,12 @@ properties:
- const: renesas,r8a779mb
- const: renesas,r8a7795
+ - description: R-Car M3Le (R8A779MD)
+ items:
+ - const: renesas,geist # M3Le Geist
+ - const: renesas,r8a779md
+ - const: renesas,r8a77965
+
- description: R-Car X5H (R8A78000)
items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH 5/7] soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Add support for identifying the R-Car M3Le (R8A779MD) SoC.
The Renesas R-Car R8A779MD M3Le SoC is a variant of the
already supported R-Car M3-N SoC with reduced peripherals.
Enable support for the M3Le SoC through already existing
ARCH_R8A77965 configuration symbol. PRR reads 0x67c05501 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/soc/renesas/renesas-soc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 38ff0b823bdaf..c82835cf6d8e9 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -361,6 +361,7 @@ static const struct of_device_id renesas_socs[] __initconst __maybe_unused = {
{ .compatible = "renesas,r8a77965", .data = &soc_rcar_m3_n },
{ .compatible = "renesas,r8a779m4", .data = &soc_rcar_m3_n },
{ .compatible = "renesas,r8a779m5", .data = &soc_rcar_m3_n },
+ { .compatible = "renesas,r8a779md", .data = &soc_rcar_m3_n },
#endif
#ifdef CONFIG_ARCH_R8A77970
{ .compatible = "renesas,r8a77970", .data = &soc_rcar_v3m },
--
2.53.0
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Nguyen Tran, Marek Vasut, Conor Dooley, David Airlie,
Geert Uytterhoeven, Kieran Bingham, Krzysztof Kozlowski,
Kuninori Morimoto, Laurent Pinchart, Magnus Damm, Maxime Ripard,
Michael Turquette, Rob Herring, Simona Vetter, Stephen Boyd,
Thomas Zimmermann, Tomi Valkeinen, devicetree, dri-devel,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a variant of the
R-Car M3-N (R8A77965) SoC. The Renesas M3Le SoC is a register-compatible
variant of the R8A77965 (M3-N) with reduced set of peripherals.
Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a779md.dtsi | 48 +++++++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md.dtsi
diff --git a/arch/arm64/boot/dts/renesas/r8a779md.dtsi b/arch/arm64/boot/dts/renesas/r8a779md.dtsi
new file mode 100644
index 0000000000000..7e0f5fe4cd439
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a779md.dtsi
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Device Tree Source for the R-Car M3Le (R8A779MD) SoC
+ *
+ * Copyright (C) 2025-2026 Renesas Electronics Corp.
+ */
+
+#include "r8a77965.dtsi"
+
+/ {
+ compatible = "renesas,r8a779md", "renesas,r8a77965";
+};
+
+/delete-node/ &csi20;
+/delete-node/ &drif00;
+/delete-node/ &drif01;
+/delete-node/ &drif10;
+/delete-node/ &drif11;
+/delete-node/ &drif20;
+/delete-node/ &drif21;
+/delete-node/ &drif30;
+/delete-node/ &drif31;
+/delete-node/ &hdmi0;
+/delete-node/ &mlp;
+/delete-node/ &pciec1;
+/delete-node/ &sata;
+/delete-node/ &sdhi3;
+/delete-node/ &usb3_peri0;
+/delete-node/ &usb3_phy0;
+/delete-node/ &vin0csi20;
+/delete-node/ &vin1csi20;
+/delete-node/ &vin2csi20;
+/delete-node/ &vin3csi20;
+/delete-node/ &vin4csi20;
+/delete-node/ &vin5csi20;
+/delete-node/ &vin6csi20;
+/delete-node/ &vin7csi20;
+/delete-node/ &xhci0;
+
+&du {
+ compatible = "renesas,du-r8a779md";
+ renesas,cmms = <&cmm0>, <&cmm3>;
+ renesas,vsps = <&vspd0 0>, <&vspd1 0>;
+
+ ports {
+ /delete-node/ port@1;
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Nguyen Tran, Marek Vasut, Conor Dooley, David Airlie,
Geert Uytterhoeven, Kieran Bingham, Krzysztof Kozlowski,
Kuninori Morimoto, Laurent Pinchart, Magnus Damm, Maxime Ripard,
Michael Turquette, Rob Herring, Simona Vetter, Stephen Boyd,
Thomas Zimmermann, Tomi Valkeinen, devicetree, dri-devel,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Add support for the Geist board based on the Renesas R-Car R8A779MD (M3Le)
SoC, a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals. The Geist board design references the Renesas Salvator-X/XS
boards, adapting their configuration for the R8A779MD SoC.
Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/Makefile | 3 +
.../dts/renesas/geist-panel-aa104xd12.dtso | 17 +
.../arm64/boot/dts/renesas/r8a779md-geist.dts | 832 ++++++++++++++++++
3 files changed, 852 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md-geist.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index ca45d2857ea7f..0b8fbc7b00c6e 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -60,6 +60,9 @@ r8a77965-salvator-xs-panel-aa104xd12-dtbs := r8a77965-salvator-xs.dtb salvator-p
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-xs-panel-aa104xd12.dtb
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb-kf.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a779md-geist.dtb
+r8a779md-geist-panel-aa104xd12-dtbs := r8a779md-geist.dtb geist-panel-aa104xd12.dtbo
+dtb-$(CONFIG_ARCH_R8A77965) += r8a779md-geist-panel-aa104xd12.dtb
dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb
dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle-function-expansion.dtbo
diff --git a/arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
new file mode 100644
index 0000000000000..c8e39811eb051
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree overlay for the AA104XD12 panel connected to LVDS0 on a Geist board
+ *
+ * Copyright 2026 Marek Vasut
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "salvator-panel-aa104xd12.dtso"
+
+&{/panel} {
+ data-mapping = "jeida-24";
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a779md-geist.dts b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
new file mode 100644
index 0000000000000..1a25acf638ea1
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
@@ -0,0 +1,832 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Device Tree Source for the Geist board with R-Car M3Le
+ *
+ * Copyright (C) 2025-2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "r8a779md.dtsi"
+
+/ {
+ model = "Renesas Geist board based on r8a779md";
+ compatible = "renesas,geist", "renesas,r8a779md", "renesas,r8a77965";
+
+ aliases {
+ serial0 = &scif2;
+ serial1 = &hscif1;
+ ethernet0 = &avb;
+ mmc0 = &sdhi2;
+ mmc1 = &sdhi0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=on";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x48000000 0x0 0x78000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* Device specific region for Lossy Decompression */
+ lossy_decompress: linux,lossy_decompress@54000000 {
+ no-map;
+ reg = <0x00000000 0x54000000 0x0 0x03000000>;
+ };
+ };
+
+ audio_clkout: audio-clkout {
+ /*
+ * FIXME
+ * This is same as <&rcar_sound 0>
+ * but needed to avoid cs2500/rcar_sound probe dead-lock
+ */
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 50000>;
+
+ brightness-levels = <256 128 64 16 8 4 0>;
+ default-brightness-level = <6>;
+
+ power-supply = <®_12v>;
+ enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ };
+
+ cvbs-in {
+ compatible = "composite-video-connector";
+ label = "CVBS IN";
+
+ port {
+ cvbs_con: endpoint {
+ remote-endpoint = <&adv7482_ain7>;
+ };
+ };
+ };
+
+ hdmi-in {
+ compatible = "hdmi-connector";
+ label = "HDMI IN";
+ type = "a";
+
+ port {
+ hdmi_in_con: endpoint {
+ remote-endpoint = <&adv7482_hdmi>;
+ };
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&keys_pins>;
+ pinctrl-names = "default";
+
+ key-1 {
+ gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_1>;
+ label = "SW4-1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-2 {
+ gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_2>;
+ label = "SW4-2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-3 {
+ gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_3>;
+ label = "SW4-3";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-4 {
+ gpios = <&gpio5 23 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_4>;
+ label = "SW4-4";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-a {
+ gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_A>;
+ label = "TSW0";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-b {
+ gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_B>;
+ label = "TSW1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-c {
+ gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_C>;
+ label = "TSW2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ };
+
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_12v: regulator2 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sound_card: sound {
+ compatible = "audio-graph-card";
+
+ label = "rcar-sound";
+ dais = <&rsnd_port0>; /* AK4619 Audio Codec */
+ };
+
+ vbus0_usb2: regulator-vbus0-usb2 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB20_VBUS0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ gpio = <&gpio6 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <3300000 1>, <1800000 0>;
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_in: endpoint {
+ remote-endpoint = <&adv7123_out>;
+ };
+ };
+ };
+
+ vga-encoder {
+ compatible = "adi,adv7123";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7123_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ adv7123_out: endpoint {
+ remote-endpoint = <&vga_in>;
+ };
+ };
+ };
+ };
+
+ x12_clk: x12 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+
+ /* External DU dot clocks */
+ x21_clk: x21-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <33000000>;
+ };
+
+ x22_clk: x22-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <33000000>;
+ };
+
+ x23_clk: x23-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ x3013_clk: x3013-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+&audio_clk_a {
+ clock-frequency = <22579200>;
+};
+
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+ phy-handle = <&phy0>;
+ tx-internal-delay-ps = <2000>;
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ rxc-skew-ps = <1500>;
+ reg = <0>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <100>;
+ reset-deassert-us = <100>;
+ };
+};
+
+&csi40 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ csi40_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&adv7482_txa>;
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ clocks = <&cpg CPG_MOD 724>,
+ <&cpg CPG_MOD 723>,
+ <&cpg CPG_MOD 721>,
+ <&versaclock5 1>,
+ <&x21_clk>,
+ <&versaclock5 2>;
+ clock-names = "du.0", "du.1", "du.3",
+ "dclkin.0", "dclkin.1", "dclkin.3";
+ status = "okay";
+
+ ports {
+ port@0 {
+ du_out_rgb: endpoint {
+ remote-endpoint = <&adv7123_in>;
+ };
+ };
+ };
+};
+
+&ehci0 {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&extalr_clk {
+ clock-frequency = <32768>;
+};
+
+&extal_clk {
+ clock-frequency = <16666666>;
+};
+
+&hscif1 {
+ pinctrl-0 = <&hscif1_pins>;
+ pinctrl-names = "default";
+
+ uart-has-rtscts;
+ /* Please only enable hscif1 or scif1 */
+ status = "okay";
+};
+
+&hsusb {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+ clock-frequency = <100000>;
+ status = "okay";
+
+ ak4619: codec@10 {
+ compatible = "asahi-kasei,ak4619";
+ reg = <0x10>;
+ clocks = <&rcar_sound 3>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ ak4619_endpoint: endpoint {
+ remote-endpoint = <&rsnd_endpoint0>;
+ };
+ };
+ };
+
+ /* Pin-to-pin, register map, and control compatible with CS2000 and CS2200 */
+ cs2500: clk_multiplier@4f {
+ #clock-cells = <0>;
+ compatible = "cirrus,cs2500-cp", "cirrus,cs2000-cp";
+ reg = <0x4f>;
+ clocks = <&audio_clkout>, <&x12_clk>;
+ clock-names = "clk_in", "ref_clk";
+
+ assigned-clocks = <&cs2500>;
+ assigned-clock-rates = <24576000>; /* 1/1 divide */
+ };
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ versaclock3: clock-generator@68 {
+ compatible = "renesas,5p35023";
+ reg = <0x68>;
+ #clock-cells = <1>;
+ clocks = <&x3013_clk>;
+ assigned-clocks = <&versaclock3 4>, <&versaclock3 5>;
+ assigned-clock-rates = <100000000>, <100000000>;
+ };
+
+ versaclock5: clock-generator@6a {
+ compatible = "idt,5p49v5923";
+ reg = <0x6a>;
+ #clock-cells = <1>;
+ clocks = <&x23_clk>;
+ clock-names = "xin";
+ };
+
+ video-receiver@70 {
+ compatible = "adi,adv7482";
+ reg = <0x70 0x71 0x72 0x73 0x74 0x75
+ 0x60 0x61 0x62 0x63 0x64 0x65>;
+ reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater",
+ "infoframe", "cbus", "cec", "sdp", "txa", "txb" ;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>,
+ <31 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "intrq1", "intrq2";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@7 {
+ reg = <7>;
+
+ adv7482_ain7: endpoint {
+ remote-endpoint = <&cvbs_con>;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+
+ adv7482_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in_con>;
+ };
+ };
+
+ port@a {
+ reg = <10>;
+
+ adv7482_txa: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csi40_in>;
+ };
+ };
+ };
+ };
+
+ csa_vdd: adc@7c {
+ compatible = "maxim,max9611";
+ reg = <0x7c>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+
+ csa_dvfs: adc@7f {
+ compatible = "maxim,max9611";
+ reg = <0x7f>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+};
+
+&i2c_dvfs {
+ status = "okay";
+
+ clock-frequency = <400000>;
+
+ eeprom@50 {
+ compatible = "rohm,br24t01", "atmel,24c01";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+};
+
+&ohci0 {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pcie_bus_clk {
+ status = "disabled";
+};
+
+&pciec0 {
+ clocks = <&cpg CPG_MOD 319>, <&versaclock3 4>;
+ status = "okay";
+};
+
+&pciec0_rp {
+ clocks = <&versaclock3 5>;
+};
+
+&pfc {
+ pinctrl-0 = <&scif_clk_pins>;
+ pinctrl-names = "default";
+
+ avb_pins: avb {
+ mux {
+ groups = "avb_link", "avb_mdio", "avb_mii";
+ function = "avb";
+ };
+
+ pins_mdio {
+ groups = "avb_mdio";
+ drive-strength = <24>;
+ };
+
+ pins_mii_tx {
+ pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC", "PIN_AVB_TD0",
+ "PIN_AVB_TD1", "PIN_AVB_TD2", "PIN_AVB_TD3";
+ drive-strength = <12>;
+ };
+ };
+
+ du_pins: du {
+ groups = "du_rgb888", "du_sync", "du_oddf", "du_clk_out_0";
+ function = "du";
+ };
+
+ hscif1_pins: hscif1 {
+ groups = "hscif1_data_a", "hscif1_ctrl_a";
+ function = "hscif1";
+ };
+
+ i2c2_pins: i2c2 {
+ groups = "i2c2_a";
+ function = "i2c2";
+ };
+
+ irq0_pins: irq0 {
+ groups = "intc_ex_irq0";
+ function = "intc_ex";
+ };
+
+ keys_pins: keys {
+ pins = "GP_5_17", "GP_5_20", "GP_5_22";
+ bias-pull-up;
+ };
+
+ pwm1_pins: pwm1 {
+ groups = "pwm1_a";
+ function = "pwm1";
+ };
+
+ pwm2_pins: pwm2 {
+ groups = "pwm2_a";
+ function = "pwm2";
+ };
+
+ scif1_pins: scif1 {
+ groups = "scif1_data_a", "scif1_ctrl";
+ function = "scif1";
+ };
+
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+
+ scif_clk_pins: scif_clk {
+ groups = "scif_clk_a";
+ function = "scif_clk";
+ };
+
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
+
+ sound_pins: sound {
+ groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
+ function = "ssi";
+ };
+
+ sound_clk_pins: sound_clk {
+ groups = "audio_clk_a_a", "audio_clk_b_a", "audio_clk_c_a",
+ "audio_clkout_a", "audio_clkout3_a";
+ function = "audio_clk";
+ };
+
+ usb0_pins: usb0 {
+ groups = "usb0";
+ function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ mux {
+ groups = "usb1";
+ function = "usb1";
+ };
+
+ ovc {
+ pins = "GP_6_27";
+ bias-pull-up;
+ };
+
+ pwen {
+ pins = "GP_6_26";
+ bias-pull-down;
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-0 = <&pwm2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&rcar_sound {
+ pinctrl-0 = <&sound_pins>, <&sound_clk_pins>;
+ pinctrl-names = "default";
+
+ /* Single DAI */
+ #sound-dai-cells = <0>;
+
+ /* audio_clkout0/1/2/3 */
+ #clock-cells = <1>;
+ clock-frequency = <12288000 11289600>;
+
+ status = "okay";
+
+ /* update <audio_clk_b> to <cs2500> */
+ clocks = <&cpg CPG_MOD 1005>,
+ <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+ <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+ <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+ <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+ <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+ <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+ <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+ <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+ <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+ <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+ <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+ <&audio_clk_a>, <&cs2500>,
+ <&audio_clk_c>,
+ <&cpg CPG_MOD 922>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rsnd_port0: port {
+ rsnd_endpoint0: endpoint {
+ remote-endpoint = <&ak4619_endpoint>;
+ dai-format = "left_j";
+ bitclock-master = <&rsnd_endpoint0>;
+ frame-master = <&rsnd_endpoint0>;
+ playback = <&ssi0>, <&src0>, <&dvc0>;
+ capture = <&ssi1>, <&src1>, <&dvc1>;
+ };
+ };
+ };
+};
+
+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
+&scif1 {
+ pinctrl-0 = <&scif1_pins>;
+ pinctrl-names = "default";
+
+ uart-has-rtscts;
+ /* Please only enable hscif1 or scif1 */
+ /* status = "okay"; */
+};
+
+&scif2 {
+ pinctrl-0 = <&scif2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins>;
+ pinctrl-names = "default", "state_uhs";
+
+ iommus = <&ipmmu_ds1 34>;
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ mmc-hs200-1_8v;
+ no-sd;
+ no-sdio;
+ non-removable;
+ fixed-emmc-driver-type = <1>;
+ full-pwr-cycle-in-suspend;
+ status = "okay";
+};
+
+&ssi1 {
+ shared-pin;
+};
+
+&usb_extal_clk {
+ clock-frequency = <50000000>;
+};
+
+&usb2_phy0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+
+ vbus-supply = <&vbus0_usb2>;
+ status = "okay";
+};
+
+&usb2_phy1 {
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&vin0 {
+ status = "okay";
+};
+
+&vin1 {
+ status = "okay";
+};
+
+&vin2 {
+ status = "okay";
+};
+
+&vin3 {
+ status = "okay";
+};
+
+&vin4 {
+ status = "okay";
+};
+
+&vin5 {
+ status = "okay";
+};
+
+&vin6 {
+ status = "okay";
+};
+
+&vin7 {
+ status = "okay";
+};
+
+&vspb {
+ status = "okay";
+};
+
+&vspi0 {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* Re: Testing remoteproc on imx8mp-evk
From: Fabio Estevam @ 2026-04-19 19:53 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: NXP Linux Team,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5CSzvBdgN5b5E0v0DB1FT4481pRTwoQJ9YzC8yMt81kmA@mail.gmail.com>
On Wed, Mar 25, 2026 at 10:48 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peng,
>
> I'm trying to use remoteproc on an imx8mp-evk board running mainline
> U-Boot and the mainline kernel.
>
> Could you please share a simple Cortex-M7 .elf file I can use for
> testing? Even a simple Hello World will suffice.
>
> It would be helpful if we add an imx8mp-evk devicetree overlay that
> includes the described remoteproc nodes.
>
> Could you please share the remoteproc devicetree?
I used the remoteproc description as the one sent by Marek for
imx8mp-data-modul-edm-sbc-overlay-cm7.dtso:
https://lore.kernel.org/linux-arm-kernel/20260407211850.79881-4-marex@nabladev.com/
I had to manually build the hello_world_cm7 SDK example, and now it
loads successfully:
# cat /sys/class/remoteproc/remoteproc0/state
offline
# echo hello_world_cm7.elf > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
# echo stop > /sys/class/remoteproc/remoteproc0/state
# dmesg | grep remoteproc
[ 0.197328] remoteproc remoteproc0: imx-rproc is available
[ 82.061452] remoteproc remoteproc0: powering up imx-rproc
[ 82.066846] remoteproc remoteproc0: Booting fw image
hello_world_cm7.elf, size 232592
[ 82.067105] remoteproc remoteproc0: remote processor imx-rproc is now up
[ 99.565501] remoteproc remoteproc0: stopped remote processor imx-rproc
^ permalink raw reply
* Re: [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Linus Walleij @ 2026-04-19 20:22 UTC (permalink / raw)
To: Guangshuo Li
Cc: Imre Kaloz, Daniel Lezcano, Thomas Gleixner, Guenter Roeck,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260413154727.3051321-1-lgs201920130244@gmail.com>
Hi Guangshuo,
thanks for your patch!
On Mon, Apr 13, 2026 at 5:47 PM Guangshuo Li <lgs201920130244@gmail.com> wrote:
> ixp4xx_timer_probe() directly returns the result of
> platform_device_register(&ixp4xx_watchdog_device). When registration
> fails, the embedded struct device in ixp4xx_watchdog_device has already
> been initialized by device_initialize(), but the failure path does not
> drop the device reference, leading to a reference leak.
(...)
> - return platform_device_register(&ixp4xx_watchdog_device);
> + ret = platform_device_register(&ixp4xx_watchdog_device);
> + if (ret)
> + platform_device_put(&ixp4xx_watchdog_device);
If the problem in the description is indeed there, it seems the bug
is inside platform_device_register(), surely a function returning an
error code is supposed to clean up any resources it takes before
returning an error. It seems wrong to try to fix this in all the
consumers.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Andre Przywara @ 2026-04-19 20:55 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260419-h616-t113s-hstimer-v1-0-1af74ebef7c5@mmpsystems.pl>
On Sun, 19 Apr 2026 14:46:06 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
Hi Michal,
> Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> and describe corresponding nodes in dts for H616 and T113-S3.
>
> H616 uses same model as existing driver except register shift compared
> to older variants.
>
> Added register layout abstraction in the driver, extended the binding
> with new compatibles and wired up dts nodes for H616 and T113-S3 which
> uses H616 as fallback compatible.
Can you say *why* we need this? IIUC Linux only ever uses one clock
source, and selects the (non-optional) Generic Timer (aka arch timer)
for that? So can you say what this hstimer clock source adds? I guess
higher resolution, but what is your use case, so why would you need the
200 MHz? And does this offset the higher access cost of an MMIO
access, compared to the arch timer's sysreg based access? Also, IIUC,
people would need to manually select this as the clocksource, why and
when would they do so? (Given they even know about it in the first
place).
Also the hstimer hasn't been used since the A20, so nobody seemed to
have missed it meanwhile?
Cheers,
Andre
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> Michal Piekos (4):
> dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
> clocksource/drivers/sun5i: add H616 hstimer support
> arm64: dts: allwinner: h616: add hstimer node
> arm: dts: allwinner: t113s: add hstimer node
>
> .../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
> arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
> drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
> 4 files changed, 78 insertions(+), 7 deletions(-)
> ---
> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> change-id: 20260413-h616-t113s-hstimer-62939948f91c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Guenter Roeck @ 2026-04-19 21:07 UTC (permalink / raw)
To: Linus Walleij, Guangshuo Li
Cc: Imre Kaloz, Daniel Lezcano, Thomas Gleixner, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <CAD++jLnC5MGg1e_Suv6BD_=XKbsn1aLxHxRfCdD3Nos+2XRzfw@mail.gmail.com>
On 4/19/26 13:22, Linus Walleij wrote:
> Hi Guangshuo,
>
> thanks for your patch!
>
> On Mon, Apr 13, 2026 at 5:47 PM Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
>> ixp4xx_timer_probe() directly returns the result of
>> platform_device_register(&ixp4xx_watchdog_device). When registration
>> fails, the embedded struct device in ixp4xx_watchdog_device has already
>> been initialized by device_initialize(), but the failure path does not
>> drop the device reference, leading to a reference leak.
> (...)
>
>> - return platform_device_register(&ixp4xx_watchdog_device);
>> + ret = platform_device_register(&ixp4xx_watchdog_device);
>> + if (ret)
>> + platform_device_put(&ixp4xx_watchdog_device);
>
> If the problem in the description is indeed there, it seems the bug
> is inside platform_device_register(), surely a function returning an
> error code is supposed to clean up any resources it takes before
> returning an error. It seems wrong to try to fix this in all the
> consumers.
>
From platform_device_register():
/**
* platform_device_register - add a platform-level device
* @pdev: platform device we're adding
*
* NOTE: _Never_ directly free @pdev after calling this function, even if it
* returned an error! Always use platform_device_put() to give up the
* reference initialised in this function instead.
*/
Not that any code actually does that as far as I can see, but isn't
the above doing exactly what the comment suggests ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Linus Walleij @ 2026-04-19 21:19 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Michael Walle
Cc: Bartosz Golaszewski, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸]
In-Reply-To: <52bf9ce2b7754af8af69b0afee0d07b2@realtek.com>
Hi Yu-Chun,
On Fri, Apr 10, 2026 at 11:39 AM Yu-Chun Lin [林祐君]
<eleanor.lin@realtek.com> wrote:
> We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
> our platform due to the specific hardware design:
>
> 1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
> into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
> register for each individual GPIO. This single register controls the
> input/output state, direction, and interrupt trigger type for that specific pin.
Isn't that attainable by:
- setting .ngpio_per_reg to 1 in struct gpio_regmap_config
- extend .reg_mask_xlate callback with an enum for each operation
(need to change all users of the .reg_mask_xlate callback but
who cares, they are not many):
e.g.
enum gpio_regmap_operation {
GPIO_REGMAP_GET_OP,
GPIO_REGMAP_SET_OP,
GPIO_REGMAP_SET_WITH_CLEAR_OP,
GPIO_REGMAP_GET_DIR_OP,
GPIO_REGMAP_SET_DIR_OP,
};
int (*reg_mask_xlate)(struct gpio_regmap *gpio,
enum_gpio_regmap_operation op,
unsigned int base,
unsigned int offset, unsigned int *reg,
unsigned int *mask);
This way .reg_mask_xlate() can hit different bits in the returned
*mask depending on operation and it will be find to pack all of
the bits into one 32bit register.
Added Michael Walle to the the thread, he will know if this is a
good idea.
> 2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
> mask to be written simultaneously when updating the register values.
Which is to just set bit 31.
With the above scheme your .reg_mask_xlate callback can just set bit 31
no matter what operating you're doing. Piece of cake.
> 3. Hardware Debounce: We also need to support hardware debounce settings per pin,
> which requires custom configuration via set_config mapped to these specific per-pin
> registers.
Just add a version of an optional .set_config() call to gpio-regmap.c
to handle this using .reg_mask_xlate() per above and add a new
GPIO_REGMAP_CONFIG_OP to the above enum, problem solved.
If it seems too hard I can write patch 1 & 2 adding this infrastructure
but I bet you can easily see what can be done with gpio-regmap.c
here provided Michael W approves the idea.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
From: Andre Przywara @ 2026-04-19 21:21 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260419-h616-t113s-hstimer-v1-1-1af74ebef7c5@mmpsystems.pl>
On Sun, 19 Apr 2026 14:46:07 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> H616 is compatible with the existing sun5i binding, but
> require its own compatible string to differentiate register offsets.
Just a nit: if the register offsets are different, then it's not
compatible, not even with the binding. So just say something like "they
are similar, but with different register offsets".
> T113-S3 uses same offsets as H616.
So it looks like (somewhat naturally) this is true for D1 as well? And
since that SoC was the first, we use "sun20i-d1" as the compatible
string prefix for this SoC's devices. I think we should follow suit
here and name that similarly.
>
> Add allwinner,sun50i-h616-hstimer
> Add allwinner,sun8i-t113s-hstimer with fallback to
> allwinner,sun50i-h616-hstimer
> Extend schema condition for interrupts to cover H616 compatible variant.
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> .../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> index f1853daec2f9..bb60a85dc34b 100644
> --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> @@ -15,9 +15,13 @@ properties:
> oneOf:
> - const: allwinner,sun5i-a13-hstimer
> - const: allwinner,sun7i-a20-hstimer
> + - const: allwinner,sun50i-h616-hstimer
> - items:
> - const: allwinner,sun6i-a31-hstimer
> - const: allwinner,sun7i-a20-hstimer
> + - items:
> + - const: allwinner,sun8i-t113s-hstimer
> + - const: allwinner,sun50i-h616-hstimer
>
> reg:
> maxItems: 1
> @@ -45,7 +49,9 @@ required:
> if:
> properties:
> compatible:
> - const: allwinner,sun5i-a13-hstimer
> + enum:
> + - allwinner,sun5i-a13-hstimer
> + - allwinner,sun50i-h616-hstimer
IIUC this just matches the H616, but wouldn't match the T113/D1? And
there is some construct with "contains" to match for fallback
compatibles?
Cheers,
Andre
>
> then:
> properties:
>
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Linus Walleij @ 2026-04-19 21:25 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Frank Wunderlich, bartosz.golaszewski, linux, sean.wang,
matthias.bgg, angelogioacchino.delregno, brgl, linux-mediatek,
linux-gpio, linux-kernel, linux-arm-kernel
In-Reply-To: <dc46f7d784281642aad6d47e79a3e91652eec667@linux.dev>
On Mon, Apr 13, 2026 at 6:59 PM Frank Wunderlich
<frank.wunderlich@linux.dev> wrote:
> Am 13. April 2026 um 10:01 schrieb "Linus Walleij" <linusw@kernel.org mailto:linusw@kernel.org?to=%22Linus%20Walleij%22%20%3Clinusw%40kernel.org%3E >:
> >
> > On Fri, Apr 10, 2026 at 11:24 AM Frank Wunderlich
> > <frank-w@public-files.de> wrote:
> >
> > >
> > > Gesendet: Freitag, 10. April 2026 um 09:09
> > > Von: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > > An: "Frank Wunderlich" <linux@fw-web.de>, "Sean Wang" <sean.wang@kernel.org>, "Linus Walleij" <linusw@kernel.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Bartosz Golaszewski" <brgl@kernel.org>
> > > CC: linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > > Betreff: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
> > >
> > > If the gpio_chip::get_direction() callback is not implemented by the GPIO
> > > controller driver, GPIOLIB emits a warning.
> > >
> > > Implement get_direction() for the GPIO part of pinctrl-moore.
> > >
> > > Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
> > > Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()")
> > > Reported-by: Frank Wunderlich <linux@fw-web.de>
> > >
> > > please use the email i used for SoB in my linked patch (closes link below), the other email i use only for sending patches due to mail provider limitation.
> > >
> > I can't fix this up because the closes link isn't working right now.
> > Is it the same
> > as the one this mail came from frank-w@public-files.de?
>
> yes, closes-link works for me
Fixed up and applied. Will be going in as fix for v7.1.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Linus Walleij @ 2026-04-19 21:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: Guangshuo Li, Imre Kaloz, Daniel Lezcano, Thomas Gleixner,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <aa801626-2e33-489a-931f-600540fe4ae3@roeck-us.net>
On Sun, Apr 19, 2026 at 11:08 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/19/26 13:22, Linus Walleij wrote:
> > Hi Guangshuo,
> >
> > thanks for your patch!
> >
> > On Mon, Apr 13, 2026 at 5:47 PM Guangshuo Li <lgs201920130244@gmail.com> wrote:
> >
> >> ixp4xx_timer_probe() directly returns the result of
> >> platform_device_register(&ixp4xx_watchdog_device). When registration
> >> fails, the embedded struct device in ixp4xx_watchdog_device has already
> >> been initialized by device_initialize(), but the failure path does not
> >> drop the device reference, leading to a reference leak.
> > (...)
> >
> >> - return platform_device_register(&ixp4xx_watchdog_device);
> >> + ret = platform_device_register(&ixp4xx_watchdog_device);
> >> + if (ret)
> >> + platform_device_put(&ixp4xx_watchdog_device);
> >
> > If the problem in the description is indeed there, it seems the bug
> > is inside platform_device_register(), surely a function returning an
> > error code is supposed to clean up any resources it takes before
> > returning an error. It seems wrong to try to fix this in all the
> > consumers.
> >
>
> From platform_device_register():
>
> /**
> * platform_device_register - add a platform-level device
> * @pdev: platform device we're adding
> *
> * NOTE: _Never_ directly free @pdev after calling this function, even if it
> * returned an error! Always use platform_device_put() to give up the
> * reference initialised in this function instead.
> */
>
> Not that any code actually does that as far as I can see, but isn't
> the above doing exactly what the comment suggests ?
Yeah and Johan Hovold wrote that comment and he usually knows
what he's doing so let's go with this then, I'm convinced!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: rockchip: Fix GPIO after convert to dynamic base allocation
From: Linus Walleij @ 2026-04-19 21:42 UTC (permalink / raw)
To: Jonas Karlman
Cc: Bartosz Golaszewski, Heiko Stuebner, Shawn Lin,
Bartosz Golaszewski, linux-gpio, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260416154928.2103388-1-jonas@kwiboo.se>
Thanks for fixing this Jonas,
this also uses the function in the right way: instead of using
gc->base which just happened to match the pin base it passes
bank->pin_base which makes a lot of sense.
(My original response mail was a bit whimsical because I
didn't realize the offset passed as argument 1 is local and not
global.... but you figured that out.)
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Andrey Konovalov @ 2026-04-19 21:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKv5y+gq=TnOAEXSqgBRpmHNjwqCfxpLaw5XkcbQ+23bg@mail.gmail.com>
On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> I think we're talking past each other.
> We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
> We're not going to modify arm64 JIT at all.
>
> This is purely KASAN_GENRIC and only on x86-64.
> JIT will emit exactly what compilers emit for generic
> which is __asan_load/store. This is as stable ABI as it can get
> and we don't want to deviate from it.
OK, I supposed that's fair. You did throw me off point with your
performance comment. But if you decide to add SW_TAGS support at some
point, I think this discussion needs to be revisited.
But please add a comment saying that those functions are only exposed
for BPF JIT and they are not supposed to be used by other parts of the
kernel. And in case you do end up adding a new config option, guard
the public declarations by a corresponding ifdef.
> The goal here is to find bugs in the verifier.
> If something got past it, that shouldn't have,
> kasan generic on x86-64 is enough.
FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
^ permalink raw reply
* [PATCH] rtc: ab8500: replace sprintf() with sysfs_emit()
From: Maxwell Doose @ 2026-04-19 22:36 UTC (permalink / raw)
To: linusw, alexandre.belloni; +Cc: linux-arm-kernel, linux-rtc, linux-kernel
This patch replaces sprintf() with sysfs_emit() to ensure proper
bounds checking. It also simplifies the return logic by directly
returning the error after logging, instead of logging, calling
sprintf(), then returning.
Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
drivers/rtc/rtc-ab8500.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index ed2b6b8bb3bf..c6147837f957 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -284,11 +284,10 @@ static ssize_t ab8500_sysfs_show_rtc_calibration(struct device *dev,
retval = ab8500_rtc_get_calibration(dev, &calibration);
if (retval < 0) {
dev_err(dev, "Failed to read RTC calibration attribute\n");
- sprintf(buf, "0\n");
return retval;
}
- return sprintf(buf, "%d\n", calibration);
+ return sysfs_emit(buf, "%d\n", calibration);
}
static DEVICE_ATTR(rtc_calibration, S_IRUGO | S_IWUSR,
--
2.53.0
^ permalink raw reply related
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