* [PATCH 32/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
While at it, remove the duplicated &hdmi0_sound node.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
index 2c22abaf40a8..2076c050cd69 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
@@ -194,6 +194,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -217,10 +220,6 @@ &hdptxphy0 {
status = "okay";
};
-&hdmi0_sound {
- status = "okay";
-};
-
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0m2_xfer>;
@@ -282,6 +281,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
vdd_sd {
vdd_sd_en: vdd-sd-en {
rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 27/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5b-5bp-5t
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 and GPIO4_A1 lines to control the voltage
bias on the data lines for the HDMI0 and HDMI1 ports. These lines must
be asserted when operating in HDMI 2.1 FRL mode and deasserted for HDMI
1.4/2.0 TMDS mode.
Wire up both HDMI ports to their respective GPIO lines using the
frl-enable-gpios property to allow adjusting the bias when transitioning
between TMDS and FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index bf4a1d2e55ca..924de5a69570 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -183,6 +183,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -204,7 +207,8 @@ &hdmi0_sound {
&hdmi1 {
pinctrl-0 = <&hdmim0_tx1_cec &hdmim0_tx1_hpd
- &hdmim1_tx1_scl &hdmim1_tx1_sda>;
+ &hdmim1_tx1_scl &hdmim1_tx1_sda &hdmi1_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -505,6 +509,16 @@ &pd_npu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hdmi1_frl_en: hdmi1-frl-en {
+ rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 33/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-nanopi-r6
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
index 1b6a59f7cabc..d4560c0d6cd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
@@ -236,6 +236,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -404,6 +407,12 @@ lan2_led_pin: lan2-led-pin {
};
};
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
rtc_int: rtc-int {
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 34/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-odroid-m2
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts
index a72063c55140..2ec3bb6d682e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts
@@ -249,6 +249,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -438,6 +441,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
lcd {
lcd_pwren: lcd-pwren {
rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 26/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5-itx
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 line to control the voltage bias on the
HDMI1 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI1 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
index f7dd01d6fa0a..1f4c1eb7a8c6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
@@ -347,7 +347,8 @@ &gpu {
&hdmi1 {
pinctrl-0 = <&hdmim0_tx1_cec &hdmim0_tx1_hpd
- &hdmim1_tx1_scl &hdmim1_tx1_sda>;
+ &hdmim1_tx1_scl &hdmim1_tx1_sda &hdmi1_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -696,6 +697,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi1_frl_en: hdmi1-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
rtc_int: rtc-int {
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 31/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-indiedroid-nova
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts b/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
index 174d299cc6bb..9a98574ecf7d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
@@ -278,8 +278,10 @@ &gpu {
&hdmi0 {
pinctrl-0 = <&hdmim0_tx0_scl>, <&hdmim0_tx0_sda>,
- <&hdmim0_tx0_hpd>, <&hdmim0_tx0_cec>;
+ <&hdmim0_tx0_hpd>, <&hdmim0_tx0_cec>,
+ <&hdmi0_frl_en>;
pinctrl-names = "default";
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -517,6 +519,12 @@ bt_wake_host: bt-wake-host {
};
};
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
--
2.53.0
^ permalink raw reply related
* [PATCH 35/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-5
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..2fb1362ee15c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -181,6 +181,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -381,6 +384,12 @@ &pd_npu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 38/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B2 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
While at it, move hym8563 down to fix the ordering of &pinctrl entries.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
index 7e179862da6e..a54d1aac284f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
@@ -224,6 +224,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -367,9 +370,9 @@ &pd_gpu {
};
&pinctrl {
- hym8563 {
- hym8563_int: hym8563-int {
- rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
@@ -379,6 +382,12 @@ hp_detect: hp-detect {
};
};
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
leds {
led_pins: led-pins {
rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>,
--
2.53.0
^ permalink raw reply related
* [PATCH 36/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B5 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts
index 06120b2db690..a7b47670195c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts
@@ -147,6 +147,7 @@ &hdmi0 {
pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
&hdmim0_tx0_scl &hdmim0_tx0_sda
&hdmi_frl_pin>;
+ frl-enable-gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -246,7 +247,7 @@ key1_pin: key1-pin {
hdmi {
hdmi_frl_pin: hdmi-frl-pin {
- rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+ rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 40/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
index 7fe42f4ff827..8ffbbc5f9b6c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
@@ -262,7 +262,9 @@ &hdmi0 {
pinctrl-0 = <&hdmim0_tx0_cec
&hdmim1_tx0_hpd
&hdmim0_tx0_scl
- &hdmim0_tx0_sda>;
+ &hdmim0_tx0_sda
+ &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -461,6 +463,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
leds {
led_pins: led-pins {
rockchip,pins = <3 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>,
--
2.53.0
^ permalink raw reply related
* [PATCH 37/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-radxa-cm5-io
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
index f80d5a00a4bd..339df05c6d71 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
@@ -120,6 +120,9 @@ &gmac1 {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -217,6 +220,12 @@ usbc0_int: usbc0-int {
};
};
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
usb {
vcc5v0_host_en: vcc5v0-host-en {
rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 39/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
index 0991f6a21190..b3afbdd7119d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
@@ -327,7 +327,9 @@ &hdmi0 {
pinctrl-0 = <&hdmim0_tx0_cec
&hdmim1_tx0_hpd
&hdmim0_tx0_scl
- &hdmim0_tx0_sda>;
+ &hdmim0_tx0_sda
+ &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -373,6 +375,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
leds {
io_led: io-led {
rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/1] reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
From: Robby Cai @ 2026-04-17 9:28 UTC (permalink / raw)
To: Philipp Zabel
Cc: Frank.Li, s.hauer, festevam, krzk+dt, andrew.smirnov, kernel, imx,
linux-arm-kernel, linux-kernel, aisheng.dong, guoniu.zhou
In-Reply-To: <2605c4332e8a3e8950b0b15fc5377423cfed4a1f.camel@pengutronix.de>
On Fri, Apr 17, 2026 at 10:47:48AM +0200, Philipp Zabel wrote:
> On Fr, 2026-04-17 at 16:08 +0800, Robby Cai wrote:
> > On i.MX8MQ, the MIPI CSI reset lines are active-low and not self-clearing.
> > Writing '0' asserts reset and it remains asserted until explicitly
> > deasserted by software.
> >
> > This driver previously treated the MIPI CSI reset signals as active-high,
> > which led to incorrect reset assert/deassert sequencing. This issue was
> > exposed by commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly
> > release reset").
>
> If this patch is backported without 6d79bb8fd2aa, or the other way
> around, will that break MIPI CSI-2 on older kernels? That would warrant
> a Cc: stable tag.
>
Yes, will break.
These two patches should be backported as a pair to ensure correct behavior.
Regards,
Robby
^ permalink raw reply
* RE: [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on i.MX95
From: Hongxing Zhu @ 2026-04-17 9:28 UTC (permalink / raw)
To: Peng Fan, abelvesa@kernel.org, mturquette@baylibre.com,
sboyd@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com
Cc: linux-clk@vger.kernel.org, imx@nxp.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <PAXPR04MB845979CEDF7426A07BCB6FA388202@PAXPR04MB8459.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Peng Fan <peng.fan@nxp.com>
> Sent: Friday, April 17, 2026 5:22 PM
> To: Hongxing Zhu <hongxing.zhu@nxp.com>; abelvesa@kernel.org;
> mturquette@baylibre.com; sboyd@kernel.org; Frank Li <frank.li@nxp.com>;
> s.hauer@pengutronix.de; festevam@gmail.com
> Cc: linux-clk@vger.kernel.org; imx@nxp.com; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; kernel@pengutronix.de
> Subject: RE: [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on
> i.MX95
>
> Hi Richard,
>
> > Subject: [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch
> > on
> > i.MX95
> >
> > When the internal PLL is used as the PCIe reference clock source on
> > i.MX95, a REFCLK rise-fall time mismatch is observed during PCIe Gen1
> > compliance testing with the Lfast IO analyzer.
> >
> > Fix this issue by configuring the IREF_TX field to 0xF (15), which
> > adjusts the transmitter current reference to meet the PCIe
> > specification timing requirements.
>
> BLK CTRL in HSIOMIX should be save/restore for the settings you configured in
> probe phase.
Good suggestion, thanks.
Best Regards
Richard Zhu
>
> Regards
> Peng.
>
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > drivers/clk/imx/clk-imx95-blk-ctl.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/clk/imx/clk-imx95-blk-ctl.c
> > b/drivers/clk/imx/clk- imx95-blk-ctl.c index
> > 1f9259f45607..bc6957299cec 100644
> > --- a/drivers/clk/imx/clk-imx95-blk-ctl.c
> > +++ b/drivers/clk/imx/clk-imx95-blk-ctl.c
> > @@ -44,6 +44,8 @@ struct imx95_blk_ctl_clk_dev_data {
> > const char * const *parent_names;
> > u32 num_parents;
> > u32 reg;
> > + u32 reg_init_msk;
> > + u32 reg_init_val;
> > u32 bit_idx;
> > u32 bit_width;
> > u32 clk_type;
> > @@ -289,6 +291,8 @@ static const struct imx95_blk_ctl_clk_dev_data
> > hsio_blk_ctl_clk_dev_data[] = {
> > .parent_names = (const char *[]){ "func_out_en", },
> > .num_parents = 1,
> > .reg = 0,
> > + .reg_init_msk = GENMASK(10, 7),
> > + .reg_init_val = GENMASK(10, 7),
> > .bit_idx = 6,
> > .bit_width = 1,
> > .type = CLK_GATE,
> > @@ -410,6 +414,9 @@ static int imx95_bc_probe(struct platform_device
> > *pdev)
> > const struct imx95_blk_ctl_clk_dev_data *data = &bc-
> > >pdata->clk_dev_data[i];
> > void __iomem *reg = base + data->reg;
> >
> > + if (data->reg_init_msk)
> > + writel((readl(reg) & ~data->reg_init_msk) |
> > data->reg_init_val,
> > +reg);
> > +
> > if (data->type == CLK_MUX) {
> > hws[i] = clk_hw_register_mux(dev, data-
> > >name, data->parent_names,
> > data-
> > >num_parents, data->flags, reg,
> > --
> > 2.37.1
^ permalink raw reply
* Re: [PATCH 6/6] usb: typec: ucsi: huawei-gaokun: pass down HPD_IRQ events
From: Heikki Krogerus @ 2026-04-17 9:29 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Greg Kroah-Hartman, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Adrien Grassein, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Tomi Valkeinen, Bjorn Andersson,
Konrad Dybcio, Pengyu Luo, Nikita Travkin, Yongxing Mou,
dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260416-hpd-irq-events-v1-6-1ab1f1cfb2b2@oss.qualcomm.com>
Thu, Apr 16, 2026 at 02:22:37AM +0300, Dmitry Baryshkov kirjoitti:
> Pass IRQ_HPD events to the HPD bridge, letting those to be delivered to
> the DisplayPort driver.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> index ca749fde49bd..328ba92e1b44 100644
> --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> @@ -299,10 +299,11 @@ static void gaokun_ucsi_handle_altmode(struct gaokun_ucsi_port *port)
>
> /* UCSI callback .connector_status() have set orientation */
> if (port->bridge)
> - drm_aux_hpd_bridge_notify(&port->bridge->dev,
> - port->hpd_state ?
> - connector_status_connected :
> - connector_status_disconnected);
> + drm_aux_hpd_bridge_notify_with_irq(&port->bridge->dev,
> + port->hpd_state ?
> + connector_status_connected :
> + connector_status_disconnected,
> + port->hpd_irq);
>
> gaokun_ec_ucsi_pan_ack(uec->ec, port->idx);
> }
>
> --
> 2.47.3
--
heikki
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-17 9:31 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring
Cc: Lee Jones, Krzysztof Kozlowski, Conor Dooley, Andi Shyti,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <6758aaa2-ac1a-4751-aece-2b445b84f2bc@linaro.org>
On 4/17/26 9:53 AM, Neil Armstrong wrote:
> On 4/16/26 10:25, Ronald Claveau wrote:
>> On 4/15/26 11:48 PM, Rob Herring wrote:
>>> On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
>>>> The Khadas VIM4 MCU register is slightly different
>>>> from previous boards' MCU.
>>>> This board also features a switchable power source for its fan.
>>>>
>>>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>>> ---
>>>> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> index 084960fd5a1fd..67769ef5d58b1 100644
>>>> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> @@ -18,6 +18,7 @@ properties:
>>>> compatible:
>>>> enum:
>>>> - khadas,mcu # MCU revision is discoverable
>>>
>>> The revision is no longer discoverable as was claimed?
>>>
>>
>> The firmware revision is still discoverable, and via the same register,
>> but the VIM4 MCU has a different register layout (eg: no DEVICE_NO
>> register). The new compatible is needed to describe a different MCU
>> variant, not a different revision of the same MCU.
>> I will remove the comment as it is confusing with new boards.
>
> Yes basically it was discoverable for earlier MCU version, but is not
> for this particular board version.
>
> Keep the comment, but add a comment on the vim4 entry saying this variant
> is not discoverable.
>
> Neil
>
Ok make sense, I will do that.
>>
>>>> + - khadas,vim4-mcu
>>>> "#cooling-cells": # Only needed for boards having FAN control
>>>> feature
>>>> const: 2
>>>> @@ -25,6 +26,10 @@ properties:
>>>> reg:
>>>> maxItems: 1
>>>> + fan-supply:
>>>> + description: Phandle to the regulator that powers the fan.
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> +
>>>> required:
>>>> - compatible
>>>> - reg
>>>>
>>>> --
>>>> 2.49.0
>>>>
>>
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 5/5] media: synopsys: Add support for i.MX95
From: Frank Li @ 2026-04-17 9:45 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-5-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:56AM +0800, Guoniu Zhou wrote:
> Add support for the i.MX95 MIPI CSI-2 receiver. The i.MX95 variant is
> nearly identical to i.MX93, with the main difference being the use of
> IDI (Image Data Interface) instead of IPI (Image Pixel Interface).
> However, the IDI interface is transparent to software, requiring only
> a different register map definition while sharing the same PHY control
> functions with i.MX93.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> index 27e4c1027816..bbb41baf789e 100644
> --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> @@ -154,6 +154,17 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
> [DW_MIPI_CSI2RX_IPI_SOFTRSTN] = DW_REG(0xa0),
> };
>
> +static const u32 imx95_regs[DW_MIPI_CSI2RX_MAX] = {
> + [DW_MIPI_CSI2RX_N_LANES] = DW_REG(0x4),
> + [DW_MIPI_CSI2RX_RESETN] = DW_REG(0x8),
> + [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
> + [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
> + [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
> + [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
> + [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
> + [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
> +};
> +
> static const struct v4l2_mbus_framefmt default_format = {
> .width = 3840,
> .height = 2160,
> @@ -901,11 +912,22 @@ static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
> .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> };
>
> +static const struct dw_mipi_csi2rx_drvdata imx95_drvdata = {
> + .regs = imx95_regs,
> + .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
> + .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
> + .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> +};
> +
> static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
> {
> .compatible = "fsl,imx93-mipi-csi2",
> .data = &imx93_drvdata,
> },
> + {
> + .compatible = "fsl,imx95-mipi-csi2",
> + .data = &imx95_drvdata,
> + },
> {
> .compatible = "rockchip,rk3568-mipi-csi2",
> .data = &rk3568_drvdata,
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Ronald Claveau @ 2026-04-17 9:48 UTC (permalink / raw)
To: Jian Hu
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
In-Reply-To: <20260415-clkmsr_a1_t7-v2-4-02b6314427e6@amlogic.com>
Hello Jian,
On 4/15/26 10:33 AM, Jian Hu via B4 Relay wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add the clock measure device to the T7 SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed62..cec2ea74850d 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
> status = "disabled";
> };
>
> + clock-measurer@48000 {
> + compatible = "amlogic,t7-clk-measure";
> + reg = <0x0 0x48000 0x0 0x1c>;
> + };
> +
Can you please order by reg, it should be between pwm_ao_gh and pwm_ab.
Thank you.
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
>
--
Best regards,
Ronald
^ permalink raw reply
* [PATCH v7 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 29 +++++++++++++++----
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..690775dbb1ec 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,16 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
reg:
maxItems: 1
@@ -34,6 +37,10 @@ properties:
items:
- const: jpgenc
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
+
power-domains:
maxItems: 1
@@ -54,6 +61,16 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgenc
+ then:
+ required:
+ - mediatek,larb
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v7 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 8c684756d5fc..786cc2942c3a 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1867,6 +1867,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1898,6 +1902,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1937,6 +1973,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v7 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..fd895688a038 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,20 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
+
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
power-domains:
maxItems: 1
@@ -60,6 +67,31 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 1
+ clock-names:
+ minItems: 1
+ maxItems: 1
+ required:
+ - mediatek,larb
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ minItems: 2
+ maxItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v7 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on tag: next-20260410, linux-next/master
Changes compared with v6:
- Patches 1/3 (dt-bindings: decoder):
update the existing `allOf` condition for mediatek,mt8189-jpgdec to
make the 'mediatek,larb' property strictly required for MT8189 SoC.
- Patches 2/3 (dt-bindings: encoder):
Add an `allOf` condition to enforce that the `mediatek,larb` property
is strictly required when the compatible string contains
mediatek,mt8189-jpgenc.
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 29 ++++++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++
3 files changed, 107 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH tty v3 2/6] serial: Replace driver usage of UPF_CONS_FLOW
From: John Ogness @ 2026-04-17 10:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, Krzysztof Kozlowski, Alim Akhtar, David S. Miller,
Ilpo Järvinen, Andy Shevchenko, Thomas Fourier, Kees Cook,
linux-serial, linux-arm-kernel, linux-samsung-soc, sparclinux
In-Reply-To: <20260417102423.40984-1-john.ogness@linutronix.de>
Rather than using the UPF_CONS_FLOW bit of uart_port.flags to track
the user configuration of console flow control, use the newly added
uart_port.cons_flow (via its get/set functions).
A coccinelle script was used to perform the search/replace.
Note1: The sh-sci driver is blindly copying platform data
configuration flags to uart_port.flags. Thus UPF_CONS_FLOW
could get set. A follow-up commit will address this.
Note2: Aside from sh-sci, the samsung_tty driver is also using
UPF_CONS_FLOW as a platform data configuration flag.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_port.c | 4 ++--
drivers/tty/serial/bcm63xx_uart.c | 2 +-
drivers/tty/serial/omap-serial.c | 2 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/pxa.c | 2 +-
drivers/tty/serial/samsung_tty.c | 8 ++++----
drivers/tty/serial/serial_txx9.c | 4 ++--
drivers/tty/serial/sunsu.c | 2 +-
8 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index af78cc02f38e7..c91b0fa7111a7 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1988,7 +1988,7 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
wait_for_lsr(up, bits);
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
@@ -3351,7 +3351,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
* it regardless of the CTS state. Therefore, only use fifo
* if we don't use control flow.
*/
- !(up->port.flags & UPF_CONS_FLOW);
+ !uart_get_cons_flow(&up->port);
if (likely(use_fifo))
serial8250_console_fifo_write(up, s, count);
diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
index 51df9d2d8bfc5..be6777dfdc532 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -675,7 +675,7 @@ static void wait_for_xmitr(struct uart_port *port)
}
/* Wait up to 1s for flow control if necessary */
- if (port->flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(port)) {
tmout = 1000000;
while (--tmout) {
unsigned int val;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0b85f47ff19e0..a9879bc655745 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1092,7 +1092,7 @@ static void __maybe_unused wait_for_xmitr(struct uart_omap_port *up)
} while (!uart_lsr_tx_empty(status));
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 6729d8e83c3c5..08cb9ff30506f 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1444,7 +1444,7 @@ static void wait_for_xmitr(struct eg20t_port *up, int bits)
}
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(&up->port)) {
unsigned int tmout;
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = ioread8(up->membase + UART_MSR);
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index fea0255067ccd..80afa47f09880 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -573,7 +573,7 @@ static void wait_for_xmitr(struct uart_pxa_port *up)
} while (!uart_lsr_tx_empty(status));
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(&up->port)) {
tmout = 1000000;
while (--tmout &&
((serial_in(up, UART_MSR) & UART_MSR_CTS) == 0))
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index e27806bf2cf3e..f9b0dbded1f43 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -319,7 +319,7 @@ static void s3c24xx_serial_stop_tx(struct uart_port *port)
ourport->tx_enabled = 0;
ourport->tx_in_progress = 0;
- if (port->flags & UPF_CONS_FLOW)
+ if (uart_get_cons_flow(port))
s3c24xx_serial_rx_enable(port);
ourport->tx_mode = 0;
@@ -493,7 +493,7 @@ static void s3c24xx_serial_start_tx(struct uart_port *port)
struct tty_port *tport = &port->state->port;
if (!ourport->tx_enabled) {
- if (port->flags & UPF_CONS_FLOW)
+ if (uart_get_cons_flow(port))
s3c24xx_serial_rx_disable(port);
ourport->tx_enabled = 1;
@@ -781,7 +781,7 @@ static void s3c24xx_serial_rx_drain_fifo(struct s3c24xx_uart_port *ourport)
uerstat = rd_regl(port, S3C2410_UERSTAT);
ch = rd_reg(port, S3C2410_URXH);
- if (port->flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(port)) {
bool txe = s3c24xx_serial_txempty_nofifo(port);
if (ourport->rx_enabled) {
@@ -1830,7 +1830,7 @@ static int s3c24xx_serial_init_port(struct s3c24xx_uart_port *ourport,
if (cfg->uart_flags & UPF_CONS_FLOW) {
dev_dbg(port->dev, "enabling flow control\n");
- port->flags |= UPF_CONS_FLOW;
+ uart_set_cons_flow(port, true);
}
/* sort our the physical and virtual addresses for each UART */
diff --git a/drivers/tty/serial/serial_txx9.c b/drivers/tty/serial/serial_txx9.c
index 436a559234dfe..103f03c1fe748 100644
--- a/drivers/tty/serial/serial_txx9.c
+++ b/drivers/tty/serial/serial_txx9.c
@@ -422,7 +422,7 @@ static void wait_for_xmitr(struct uart_port *up)
udelay(1);
/* Wait up to 1s for flow control if necessary */
- if (up->flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(up)) {
tmout = 1000000;
while (--tmout &&
(sio_in(up, TXX9_SICISR) & TXX9_SICISR_CTSS))
@@ -857,7 +857,7 @@ serial_txx9_console_write(struct console *co, const char *s, unsigned int count)
* Disable flow-control if enabled (and unnecessary)
*/
flcr = sio_in(up, TXX9_SIFLCR);
- if (!(up->flags & UPF_CONS_FLOW) && (flcr & TXX9_SIFLCR_TES))
+ if (!uart_get_cons_flow(up) && (flcr & TXX9_SIFLCR_TES))
sio_out(up, TXX9_SIFLCR, flcr & ~TXX9_SIFLCR_TES);
uart_console_write(up, s, count, serial_txx9_console_putchar);
diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c
index 6505a1930da9a..97019b5ec49e2 100644
--- a/drivers/tty/serial/sunsu.c
+++ b/drivers/tty/serial/sunsu.c
@@ -1245,7 +1245,7 @@ static void wait_for_xmitr(struct uart_sunsu_port *up)
} while (!uart_lsr_tx_empty(status));
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_get_cons_flow(&up->port)) {
tmout = 1000000;
while (--tmout &&
((serial_in(up, UART_MSR) & UART_MSR_CTS) == 0))
--
2.47.3
^ permalink raw reply related
* [PATCH tty v3 0/6] 8250: Add console flow control
From: John Ogness @ 2026-04-17 10:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-serial, Krzysztof Kozlowski, Alim Akhtar,
David S. Miller, Ilpo Järvinen, Andy Shevchenko,
Thomas Fourier, Kees Cook, linux-arm-kernel, linux-samsung-soc,
sparclinux, Biju Das, Geert Uytterhoeven, Lad Prabhakar,
Wolfram Sang, Thierry Bultel, Thomas Gleixner, Osama Abdelkader,
Xin Zhao, Ingo Molnar, Andy Shevchenko, Krzysztof Kozlowski,
Gerhard Engleder, Lukas Wunner, Dr. David Alan Gilbert,
Joseph Tilahun
Hi,
This is v3 of a series to implement console flow control for the
8250 serial driver. v2 is here [0].
The 8250 driver already has code in place to support console flow
control. However, there is no way to activate it and it is
incomplete. This series provides the necessary missing pieces while
attempting to be as conservative as possible, so as not to introduce
any side effects into the many 8250 variants or other non-8250 serial
drivers.
Note that as of v3 I am now deprecating UPF_CONS_FLOW in favor of a
separate boolean field. In the commit message (patch 1) I explain my
reasoning for this decision.
For patch 2 I used the following Coccinelle script to perform the
modifications...
===== BEGIN cons_flow.cocci =====
// SPDX-License-Identifier: GPL-2.0-only
// Options: --all-includes
virtual patch
@r1@
type T1;
identifier U;
@@
T1 {
...
struct uart_port U;
...
};
@r2@
r1.T1 *E;
@@
- (E->port.flags & UPF_CONS_FLOW)
+ uart_get_cons_flow(&E->port)
@r3@
struct uart_port *U;
@@
- (U->flags & UPF_CONS_FLOW)
+ uart_get_cons_flow(U)
@r4@
struct uart_port *U;
@@
- U->flags |= UPF_CONS_FLOW
+ uart_set_cons_flow(U, true)
===== END cons_flow.cocci =====
Changes since v2:
- Deprecate UPF_CONS_FLOW. Provide separate boolean with wrappers as
alternative.
- Update all UPF_CONS_FLOW users to new cons_flow wrappers.
- Use irqsave variant of spin lock for status update.
- When 8250 console flow control is not specified, clear the policy.
Changes since v1:
- Prepend a patch to perform an extra LSR wait after CTS assertion if
the initial LSR wait timed out.
- Close a window in serial8250_register_8250_port() where console
flow control was briefly disabled.
- Add port lock synchronization to the port->status RMW update in
uart_set_options().
John Ogness
[0] https://lore.kernel.org/lkml/20260410144949.16581-1-john.ogness@linutronix.de
John Ogness (6):
serial: core: Add dedicated uart_port field for console flow
serial: Replace driver usage of UPF_CONS_FLOW
serial: sh-sci: Avoid deprecated UPF_CONS_FLOW
serial: 8250: Set cons_flow on port registration
serial: 8250: Check LSR timeout on console flow control
serial: 8250: Add support for console flow control
drivers/tty/serial/8250/8250_core.c | 6 ++++++
drivers/tty/serial/8250/8250_port.c | 21 +++++++++++++++++----
drivers/tty/serial/bcm63xx_uart.c | 2 +-
drivers/tty/serial/omap-serial.c | 2 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/pxa.c | 2 +-
drivers/tty/serial/samsung_tty.c | 8 ++++----
drivers/tty/serial/serial_core.c | 21 ++++++++++++++++++++-
drivers/tty/serial/serial_txx9.c | 4 ++--
drivers/tty/serial/sh-sci.c | 5 ++++-
drivers/tty/serial/sunsu.c | 2 +-
include/linux/serial_core.h | 20 ++++++++++++++++++++
12 files changed, 78 insertions(+), 17 deletions(-)
base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
--
2.47.3
^ permalink raw reply
* [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
From: Puranjay Mohan @ 2026-04-17 10:30 UTC (permalink / raw)
To: bpf, linux-arm-kernel
Cc: Puranjay Mohan, Jonas Rebmann, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Song Liu, Russell King,
kernel
The ARM32 BPF JIT does not support BPF-to-BPF function calls
(subprogram calls). When insn->src_reg == BPF_PSEUDO_CALL, the
imm field contains a pc-relative offset to another BPF function,
not a helper function index.
When a program containing BPF-to-BPF calls is loaded, the verifier
invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each
subprogram. Since ARM32 does not reject BPF_PSEUDO_CALL, the JIT
silently emits code for the call using the wrong address computation:
func = __bpf_call_base + imm
where imm is actually a pc-relative subprogram offset, producing
a bogus function pointer. Because build_body() reports success,
bpf_jit_binary_alloc() is reached and a JIT image is allocated.
ARM32 also lacks the jit_data/extra_pass mechanism needed for
the second JIT pass in bpf_jit_subprogs(). On the second pass,
bpf_int_jit_compile() performs a full fresh compilation,
allocating a new JIT binary and overwriting prog->bpf_func. The
first allocation is never freed. bpf_jit_subprogs() then detects
the function pointer changed and aborts with -ENOTSUPP, but the
original JIT binary has already been leaked. Each program
load/unload cycle leaks one JIT binary allocation, as reported
by kmemleak:
unreferenced object 0xbf0a1000 (size 4096):
backtrace:
bpf_jit_binary_alloc+0x64/0xfc
bpf_int_jit_compile+0x14c/0x348
bpf_jit_subprogs+0x4fc/0xa60
Fix this by rejecting BPF_PSEUDO_CALL early in build_insn(),
falling through to the existing 'notyet' path. This causes
build_body() to fail before any JIT binary is allocated, so
bpf_int_jit_compile() returns the original program unjitted.
bpf_jit_subprogs() then sees !prog->jited and cleanly falls
back to the interpreter.
Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
Reported-by: Jonas Rebmann <jre@pengutronix.de>
Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de
Tested-by: Jonas Rebmann <jre@pengutronix.de>
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
arch/arm/net/bpf_jit_32.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index deeb8f292454..91fef10e88bc 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -2047,6 +2047,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
/* function call */
case BPF_JMP | BPF_CALL:
{
+ if (insn->src_reg == BPF_PSEUDO_CALL)
+ goto notyet;
const s8 *r0 = bpf2a32[BPF_REG_0];
const s8 *r1 = bpf2a32[BPF_REG_1];
const s8 *r2 = bpf2a32[BPF_REG_2];
base-commit: 1f5ffc672165ff851063a5fd044b727ab2517ae3
--
2.52.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