* [PATCH v8 5/6] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
5 and 5B boards use gmac for ethernet where the Pro has a PCIe attached
NIC.
Move the 5/5B-specific bits (analog-sound/es8388, FUSB302 Type-C,
gmac1, pwm-leds, i2s1_8ch routing, USB role-switch plumbing) out of
rk3588s-orangepi-5.dtsi into a new rk3588s-orangepi-5-5b.dtsi that is
included by both 5 and 5B.
The RK806 PLDO1 and PLDO2 outputs are wired differently between the
5/5B and the Pro (PLDO1/PLDO2 are swapped), so label the PMIC node
rk806_single in the base dtsi, drop pldo-reg1/pldo-reg2 from it, and
define them via a &rk806_single regulators augmentation in
rk3588s-orangepi-5-5b.dtsi. The Pro will supply its own mapping.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Alexey Charkov <alchark@gmail.com>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 256 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 253 +----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 272 insertions(+), 245 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..b42d2f5d9e3e
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+
+ vbus_typec: regulator-vbus-typec {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&typec5v_pwren>;
+ regulator-name = "vbus_typec";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pinctrl {
+ usb-typec {
+ usbc0_int: usbc0-int {
+ rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ typec5v_pwren: typec5v-pwren {
+ rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index fd5c6a025cd1..9bdecd5a07e5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,28 +39,14 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
- vbus_typec: regulator-vbus-typec {
+ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&typec5v_pwren>;
- regulator-name = "vbus_typec";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc5v0_sys>;
+ gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
+ regulator-name = "vcc_3v3_sd_s0";
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3_s3>;
};
vcc5v0_sys: regulator-vcc5v0-sys {
@@ -109,16 +57,6 @@ vcc5v0_sys: regulator-vcc5v0-sys {
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
-
- vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
- compatible = "regulator-fixed";
- gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
- regulator-name = "vcc_3v3_sd_s0";
- regulator-boot-on;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc_3v3_s3>;
- };
};
&combphy0_ps {
@@ -161,20 +99,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +194,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcca_3v3_s0>;
- DVDD-supply = <&vcca_1v8_s0>;
- HPVDD-supply = <&vcca_3v3_s0>;
- PVDD-supply = <&vcca_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,32 +207,10 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
-&mdio1 {
- rgmii_phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <0x1>;
- reset-assert-us = <20000>;
- reset-deassert-us = <100000>;
- reset-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_LOW>;
- };
-};
-
&pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
@@ -392,22 +231,6 @@ hp_detect: hp-detect {
rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
-
- usb-typec {
- usbc0_int: usbc0-int {
- rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- typec5v_pwren: typec5v-pwren {
- rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-};
-
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
};
&rknn_core_0 {
@@ -491,7 +314,7 @@ &spi2 {
pinctrl-names = "default";
pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
- pmic@0 {
+ rk806_single: pmic@0 {
compatible = "rockchip,rk806";
reg = <0x0>;
interrupt-parent = <&gpio0>;
@@ -666,31 +489,6 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg1 {
- regulator-name = "vcc_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcca_1v8_s0: pldo-reg2 {
- regulator-name = "vcca_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
vdda_1v2_s0: pldo-reg3 {
regulator-name = "vdda_1v2_s0";
regulator-always-on;
@@ -841,26 +639,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +651,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +662,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +670,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.53.0
^ permalink raw reply related
* [PATCH v8 4/6] arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels to match schematic
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
The Orange Pi 5, 5B and 5 Pro schematics label the RK806 PLDO outputs
using the pattern VCC_*_S0 / VCCA_*_S0 / VDDA_*_S0. Rename the base
dtsi regulator labels (and the es8388 supply references) to match:
pldo-reg1: avcc_1v8_s0 -> vcc_1v8_s0
pldo-reg2: vcc_1v8_s0 -> vcca_1v8_s0
pldo-reg3: avdd_1v2_s0 -> vdda_1v2_s0
pldo-reg4: vcc_3v3_s0 -> vcca_3v3_s0
Also update the saradc vref-supply reference to track the pldo-reg1
rename. No functional change.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..fd5c6a025cd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -274,10 +274,10 @@ es8388: audio-codec@10 {
compatible = "everest,es8388", "everest,es8328";
reg = <0x10>;
clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
assigned-clock-rates = <12288000>;
#sound-dai-cells = <0>;
@@ -441,7 +441,7 @@ &rknn_mmu_2 {
};
&saradc {
- vref-supply = <&avcc_1v8_s0>;
+ vref-supply = <&vcc_1v8_s0>;
status = "okay";
};
@@ -666,8 +666,8 @@ regulator-state-mem {
};
};
- avcc_1v8_s0: pldo-reg1 {
- regulator-name = "avcc_1v8_s0";
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -678,8 +678,8 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg2 {
- regulator-name = "vcc_1v8_s0";
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -691,8 +691,8 @@ regulator-state-mem {
};
};
- avdd_1v2_s0: pldo-reg3 {
- regulator-name = "avdd_1v2_s0";
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-name = "vdda_1v2_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200000>;
@@ -703,8 +703,8 @@ regulator-state-mem {
};
};
- vcc_3v3_s0: pldo-reg4 {
- regulator-name = "vcc_3v3_s0";
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-name = "vcca_3v3_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <3300000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore, Dmitry Baryshkov
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..42c1f3d5ba0c 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "lontium,lt8711uxd",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.53.0
^ permalink raw reply related
* [PATCH v8 1/6] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore, Krzysztof Kozlowski
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
^ permalink raw reply related
* [PATCH v8 2/6] dt-bindings: display: bridge: simple: document the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore, Krzysztof Kozlowski
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..752c736c8f85 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - lontium,lt8711uxd
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.53.0
^ permalink raw reply related
* [PATCH v8 0/6] Add support for Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
This series adds initial support for the Xunlong Orange Pi 5 Pro, based on
the Rockchip RK3588S SoC. The board features eMMC, SD card, NVMe (PCIe),
a Motorcomm YT6801 NIC (PCIe), WiFi/BT (BCM43456), dual HDMI output (the
second via a Lontium LT8711UXD DP-to-HDMI bridge on dp0), and a 40-pin
expansion header.
The series was tested against Linux 7.0
This series depends on:
https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
Please take a look.
Thank you,
Dennis Gilmore
Changes in v8:
- Bridge node: renamed label from lt8711uxd to hdmi-bridge
- Bridge node: added vdd-supply = <&vcc3v3_dp>. The vcc3v3_dp regulator
gates power to the LT8711UXD. regulator-always-on is kept because
drm_simple_bridge only enables vdd-supply with HPD which does not
happen without power on
- GPIO output pinctrl groups (bt_wake_gpio, dp_bridge_en, ethernet_en,
vcc5v0_otg_en, wifi_enable_h) changed from pcfg_pull_none to
pcfg_pull_down to match the RK3588S power-on-reset default state
- pcie2x1l1 (NVMe): switched from GPIO-mode reset to hardware sideband pins
using pinctrl-0 = <&pcie30x1m1_1_perstn>, <&pcie30x1m1_1_clkreqn>,
<&pcie30x1m1_1_waken>. Note: despite the "pcie30" prefix in the DTSI
group names, the SoC pin-mux table confirms these alt-function 4 pads
physically route to pcie2x1l1's native PERST#/CLKREQ#/WAKE# inputs.
reset-gpios is retained alongside the pinctrl entry for U-Boot
compatibility (pcie_dw_rockchip in U-Boot requires reset-gpios).
- pcie2x1l2 (NIC): added &pcie20x1m0_clkreqn and &pcie20x1m0_waken to
pinctrl-0
- Renamed pinctrl group vcc3v3_phy1_en to ethernet_en to match the
schematic signal name (Ethernet_EN)
- link to v7: https://lore.kernel.org/linux-devicetree/20260414214104.1363987-1-dennis@ausil.us/
Changes in v7:
- Fix up whitespace issues identified by checkpatch.pl --strict in
rk3588s-orangepi-5-5b.dtsi
- checkpatch gave a warning for WARNING: phy-mode "rgmii-rxid" without
comment, as this was moved over I left it untouched
- Added lontium,lt8711uxd to the compatible enum in the simple-bridge
binding
- Added lontium,lt8711uxd match entry with DRM_MODE_CONNECTOR_HDMIA to
the simple-bridge driver
- New patch to rename the regulator labels for the es8388 supplies to
match the schematics and they all use vcca_*
- Fixed ES8388 PVDD-supply — vcca_3v3_s0 → vcca_1v8_s0, 5 Pro is
different to 5 and 5b.
- analog-sound: use CPU-as-clock-master on the Pro. The ES8388 is wired to
i2s2_2ch (the only I2S block physically routed to the codec pins on this
board), which uses the legacy rockchip_i2s driver. That driver's
slave-mode trigger path hangs for 200 µs polling I2S_CLR and bails with
-ETIMEDOUT ("lrclk update failed"). The TDM-capable i2s0/i2s1/i2s5
blocks served by rockchip_i2s_tdm don't have this issue, which is why
other mainline ES8388 boards get away with bitclock-master = masterdai.
Drop bitclock-master/frame-master and the masterdai label to let the I2S
block generate BCLK/LRCK itself
- Removed regulator-always-on/regulator-boot-on from vcc3v3_dp
- Added pinctrl entries for all GPIO pins (dp_bridge_en, vcc3v3_phy1_en,
wifi_enable_h, pcie2x1l1_rst, pcie2x1l2_rst)
- DP bridge rework — replaced dp-connector node with proper chain:
- lt8711uxd bridge node (compatible lontium,lt8711uxd, with port@0/port@1
endpoints). Bridge power is gated by the vcc3v3_dp regulator, whose
enable GPIO (GPIO3_PC2) is driven via the dp_bridge_en pinctrl group;
no enable-gpios/vdd-supply on the bridge node itself.
- hdmi1-con connector node (compatible hdmi-connector, type a)
- dp0_out endpoint now points to bridge input instead of old connector
- remove accidentally included unnecessary changes
- link to v6: https://lore.kernel.org/linux-devicetree/20260411024743.195385-1-dennis@ausil.us/
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5: https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4: https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3: https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purpose
- actually clean up the delete lines and comments missed in v2
- link to v2: https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- link to v1: https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (6):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
dt-bindings: display: bridge: simple: document the Lontium LT8711UXD
DP-to-HDMI bridge
drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels
to match schematic
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/bridge/simple-bridge.yaml | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 256 ++++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 440 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 263 +----------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
9 files changed, 725 insertions(+), 250 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
^ permalink raw reply
* [PATCH] remoteproc: xlnx: check remote node state
From: Tanmay Shah @ 2026-04-25 3:02 UTC (permalink / raw)
To: michal.simek, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc, Tanmay Shah
The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++++++
drivers/remoteproc/xlnx_r5_remoteproc.c | 37 ++++++++++++++++++-------
include/linux/firmware/xlnx-zynqmp.h | 21 ++++++++++++++
3 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index fbe8510f4927..af838b2dc327 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1450,6 +1450,34 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
}
EXPORT_SYMBOL_GPL(zynqmp_pm_get_node_status);
+/**
+ * zynqmp_pm_get_rpu_node_status - PM call to request a RPU node's current power state
+ * @node: ID of the RPU component or sub-system in question
+ * @status: Current operating state of the requested RPU node.
+ * @requirements: Current requirements asserted on the RPU node.
+ * @usage: Usage information, used for RPU slave nodes only:
+ * PM_USAGE_NO_MASTER - No master is currently using
+ * the node
+ * PM_USAGE_CURRENT_MASTER - Only requesting master is
+ * currently using the node
+ * PM_USAGE_OTHER_MASTER - Only other masters are
+ * currently using the node
+ * PM_USAGE_BOTH_MASTERS - Both the current and at least
+ * one other master is currently
+ * using the node
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements, u32 *const usage)
+{
+ if (zynqmp_pm_feature(PM_GET_NODE_STATUS) < PM_API_VERSION_2)
+ return -EOPNOTSUPP;
+
+ return zynqmp_pm_get_node_status(node, status, requirements, usage);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_node_status);
+
/**
* zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
* be powered down forcefully
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 50a9974f3202..e2f25d94177d 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -948,16 +948,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
goto free_rproc;
}
- /*
- * If firmware is already available in the memory then move rproc state
- * to DETACHED. Firmware can be preloaded via debugger or by any other
- * agent (processors) in the system.
- * If firmware isn't available in the memory and resource table isn't
- * found, then rproc state remains OFFLINE.
- */
- if (!zynqmp_r5_get_rsc_table_va(r5_core))
- r5_rproc->state = RPROC_DETACHED;
-
r5_core->rproc = r5_rproc;
return r5_core;
@@ -1210,6 +1200,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
{
struct device *dev = cluster->dev;
struct zynqmp_r5_core *r5_core;
+ u32 req, usage, status;
int ret = -EINVAL, i;
r5_core = cluster->r5_cores[0];
@@ -1255,6 +1246,32 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
ret = zynqmp_r5_get_sram_banks(r5_core);
if (ret)
return ret;
+
+ /*
+ * It is possible that firmware is loaded into the memory, but
+ * RPU (remote) is not running. In such case, RPU state will be
+ * moved to RPROC_DETACHED wrongfully. To avoid it first make
+ * sure RPU is power-on and out of reset before parsing for the
+ * resource table.
+ */
+ ret = zynqmp_pm_get_rpu_node_status(r5_core->pm_domain_id,
+ &status, &req, &usage);
+ if (ret) {
+ dev_warn(r5_core->dev,
+ "failed to get rpu node status, err %d\n", ret);
+ continue;
+ }
+
+ /*
+ * If RPU state is power on and out of reset i.e. running, then
+ * assign RPROC_DETACHED state. If the RPU is not out of reset
+ * then do not attempt to attach to the remote processor.
+ */
+ if (status == PM_NODE_RUNNING) {
+ if (zynqmp_r5_get_rsc_table_va(r5_core))
+ dev_dbg(r5_core->dev, "rsc tbl not found\n");
+ r5_core->rproc->state = RPROC_DETACHED;
+ }
}
return 0;
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index d70dcd462b44..7e27b0f7bf7e 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -542,6 +542,18 @@ enum pm_gem_config_type {
GEM_CONFIG_FIXED = 2,
};
+/**
+ * enum pm_node_status - Device node status provided by xilpm fw
+ * @PM_NODE_UNUSED: Device is not used
+ * @PM_NODE_RUNNING: Device is power-on and out of reset
+ * @PM_NODE_HALT: Device is power-on but in the reset state
+ */
+enum pm_node_status {
+ PM_NODE_UNUSED = 0,
+ PM_NODE_RUNNING = 1,
+ PM_NODE_HALT = 12,
+};
+
/**
* struct zynqmp_pm_query_data - PM query data
* @qid: query ID
@@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode);
int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
u32 *const requirements, u32 *const usage);
+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements, u32 *const usage);
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
@@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
return -ENODEV;
}
+static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements,
+ u32 *const usage)
+{
+ return -ENODEV;
+}
+
static inline int zynqmp_pm_set_sd_config(u32 node,
enum pm_sd_config_type config,
u32 value)
base-commit: 6f860d238b44da8ac57be25289b9f4410691c4e2
--
2.34.1
^ permalink raw reply related
* RE: [PATCH] EDAC/xilinx: Fix stack off-by-one in debugfs UE injection handlers
From: Zhuo, Qiuxu @ 2026-04-25 2:51 UTC (permalink / raw)
To: Shengzhuo Wei, Shubhrajyoti Datta, Sai Krishna Potthuri,
Borislav Petkov, Luck, Tony, Michal Simek
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260425-edac-stack-off-by-one-v1-1-4b2dd2b9c7df@cherr.cc>
> From: Shengzhuo Wei <me@cherr.cc>
> Sent: Saturday, April 25, 2026 2:49 AM
> To: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>; Sai Krishna Potthuri
> <sai.krishna.potthuri@amd.com>; Borislav Petkov <bp@alien8.de>; Luck,
> Tony <tony.luck@intel.com>; Michal Simek <michal.simek@amd.com>
> Cc: linux-edac@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Shengzhuo Wei <me@cherr.cc>
> Subject: [PATCH] EDAC/xilinx: Fix stack off-by-one in debugfs UE injection
> handlers
>
> Two EDAC debugfs write handlers copy up to sizeof(buf) bytes into a fixed-size
> stack buffer and then unconditionally NUL-terminate it via buf[len] = '\0'.
> When userspace writes >= sizeof(buf) bytes, len becomes sizeof(buf) and the
> NUL write lands 1 byte past the end of the stack buffer.
>
> Fix by clamping the copy length to sizeof(buf) - 1 so that the NUL terminator is
> always in-bounds.
>
> Fixes: 3bd2706c910f ("EDAC/zynqmp: Add EDAC support for Xilinx ZynqMP
> OCM")
> Fixes: 83bf24051a60 ("EDAC/versal: Make the bit position of injected errors
> configurable")
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
LGTM,
Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
^ permalink raw reply
* Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Jinjie Ruan @ 2026-04-25 2:05 UTC (permalink / raw)
To: Catalin Marinas
Cc: Thomas Gleixner, peterz, sudeep.holla, yangyicong,
dietmar.eggemann, Jonathan Cameron, linux-kernel, James Morse,
linux-arm-kernel
In-Reply-To: <aetnTT51ucm2azGG@arm.com>
On 4/24/2026 8:51 PM, Catalin Marinas wrote:
> (updating Jonathan's email address to match MAINTAINERS)
>
> On Fri, Apr 24, 2026 at 09:56:24AM +0800, Jinjie Ruan wrote:
>> On 4/24/2026 4:11 AM, Catalin Marinas wrote:
>>> On Thu, Apr 23, 2026 at 08:32:34PM +0800, Jinjie Ruan wrote:
>>>> On 4/23/2026 6:08 PM, Thomas Gleixner wrote:
>>>>> On Sat, Apr 18 2026 at 12:55, Catalin Marinas wrote:
>>>>>> Another option would have been to avoid marking such CPUs present but I
>>>>>> think this will break other things. Yet another option is to register
>>>>>> all CPU devices even if they never come up (like maxcpus greater than
>>>>>> actual CPUs).
>>>>>>
>>>>>> Opinions? It might be an arm64+ACPI-only thing.
>>>>>
>>>>> I think so. The proper thing to do is to apply sane limits:
>>>>>
>>>>> 1) The possible CPUs enumerated by firmware N_POSSIBLE_FW
>>>>>
>>>>> 2) The maxcpus limit on the command line N_MAXCPUS_CL
>>>>>
>>>>> So the actual possible CPUs evaluates to:
>>>>>
>>>>> num_possible = min(N_POSSIBLE_FW, N_MAXCPUS_CL, CONFIG_NR_CPUS);
>>>>>
>>>>> The evaluation of the firmware should not mark CPUs present which are
>>>>> actually not. ACPI gives you that information. See:
>>>>>
>>>>> 5.2.12.14 GIC CPU Interface (GICC) Structure
>>>>>
>>>>> in the ACPI spec. That has two related bits:
>>>>>
>>>>> Enabled:
>>>>>
>>>>> If this bit is set, the processor is ready for use. If this bit is
>>>>> clear and the Online Capable bit is set, the system supports enabling
>>>>> this processor during OS runtime. If this bit is clear and the Online
>>>>> Capable bit is also clear, this processor is un- usable, and the
>>>>> operating system support will not attempt to use it.
>>>>>
>>>>> Online Capable:
>>>>>
>>>>> The information conveyed by this bit depends on the value of the
>>>>> Enabled bit. If the Enabled bit is set, this bit is reserved and must
>>>>> be zero. Otherwise, if this bit is set, the system supports enabling
>>>>> this processor later during OS runtime
>>>>>
>>>>> So the combination of those gives you the right answer:
>>>>>
>>>>> Enabled Online
>>>>> Capable
>>>>> 0 0 Not present, not possible
>>>>> 0 1 Not present, but possible to "hotplug" layter
>>>>> 1 0 Present
>>>>> 1 1 Invalid
>>>>
>>>> On x86, it seems that all CPUs with the ACPI_MADT_ENABLED bit set will
>>>> be marked as present.
>>>>
>>>> acpi_parse_x2apic()
>>>> -> enabled = processor->lapic_flags & ACPI_MADT_ENABLED
>>>> -> topology_register_apic(enabled)
>>>> -> topo_register_apic(enabled)
>>>> -> set_cpu_present(cpu, true)
>>>
>>> Yes but arm64 marks all CPUs present even if !ACPI_MADT_ENABLED as we
>>> don't have the notion of hardware CPU hotplug.
>>>
>>> I need to dig some more into the original vCPU hotplug support and why
>>> we ended up with all CPUs marked as present even if not calling
>>> register_cpu():
>>>
>>> https://lore.kernel.org/linux-arm-kernel/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
>>>
>>> What's the MADT GICC provided by qemu with "-smp cpus=4,maxcpus=8"? If
>>> it says Enabled for the first 4 and Online Capable for the rest, maybe
>>> we can try something like below:
>>
>> Yes, you are absolutely right,Enabled for the first 4(with GIC Flags:
>> 0x1, bit0 set) and Online Capable for the rest(with GIC Flags: 0x8, bit3
>> set). The ACPI MADT disassembly result is as follows:
>
> That's great, thanks for checking.
>
> I'd like to get some feedback from Jonathan and James as they
> contributed the vCPU hotplug support. The reason was for kubernetes to
> add vCPUs to an existing VM. Hopefully no-one relied on
> /sys/devices/system/cpu/present to report 0-7 in the above
> configuration.
Yes, only cpu 0~3 present.
# cat /sys/devices/system/cpu/possible
0-7
# cat /sys/devices/system/cpu/enabled
0-3
# cat /sys/devices/system/cpu/present
0-3
# cat /sys/devices/system/cpu/online
0-3
# cat /sys/devices/system/cpu/offline
4-7
>
> Have you tried the vCPU hotplug with this patch (the original use-case)?
Yes，the basic vCPU hotplug has no problem as below:
Add the last four CPUs:
(qemu) device_add host-arm-cpu,id=cpu4,core-id=2,thread-id=0
(qemu) [ 678.984281] ACPI: CPU4 has been hot-added
(qemu) device_add host-arm-cpu,id=cpu5,core-id=2,thread-id=1
(qemu) [ 686.593536] ACPI: CPU5 has been hot-added
(qemu) device_add host-arm-cpu,id=cpu6,core-id=3,thread-id=0
(qemu) [ 699.493530] ACPI: CPU6 has been hot-added
(qemu) device_add host-arm-cpu,id=cpu7,core-id=3,thread-id=1
(qemu) [ 706.165770] ACPI: CPU7 has been hot-added
# cat /sys/devices/system/cpu/cpu*/online
1
1
1
1
0
0
0
0
# echo 1 > /sys/devices/system/cpu/cpu4/online
[ 868.423001] Detected PIPT I-cache on CPU4
[ 868.437103] GICv3: CPU4: found redistributor 4 region
0:0x0000000008120000
[ 868.437193] GICv3: CPU4: using allocated LPI pending table
@0x0000000040120000
[ 868.437330] CPU4: Booted secondary processor 0x0000000004 [0x410fd082]
# echo 1 > /sys/devices/system/cpu/cpu5/online
[ 871.855694] Detected PIPT I-cache on CPU5
[ 871.869725] GICv3: CPU5: found redistributor 5 region
0:0x0000000008140000
[ 871.869811] GICv3: CPU5: using allocated LPI pending table
@0x0000000040130000
[ 871.869938] CPU5: Booted secondary processor 0x0000000005 [0x410fd082]
# echo 1 > /sys/devices/system/cpu/cpu6/online
[ 874.756497] Detected PIPT I-cache on CPU6
[ 874.770521] GICv3: CPU6: found redistributor 6 region
0:0x0000000008160000
[ 874.770606] GICv3: CPU6: using allocated LPI pending table
@0x0000000040140000
[ 874.770748] CPU6: Booted secondary processor 0x0000000006 [0x410fd082]
# echo 1 > /sys/devices/system/cpu/cpu7/online
[ 878.212505] Detected PIPT I-cache on CPU7
[ 878.226560] GICv3: CPU7: found redistributor 7 region
0:0x0000000008180000
[ 878.226646] GICv3: CPU7: using allocated LPI pending table
@0x0000000040150000
[ 878.226783] CPU7: Booted secondary processor 0x0000000007 [0x410fd082]
# cat /sys/devices/system/cpu/cpu*/online
1
1
1
1
1
1
1
1
# cat /sys/devices/system/cpu/enabled
0-7
# cat /sys/devices/system/cpu/present
0-7
# cat /sys/devices/system/cpu/online
0-7
Unplug the last four CPUs.
# (qemu) device_del cpu4
(qemu) [ 977.336251] psci: CPU4 killed (polled 0 ms)
(qemu) device_del cpu5
(qemu) [ 979.948212] psci: CPU5 killed (polled 0 ms)
(qemu) device_del cpu6
(qemu) [ 981.976337] psci: CPU6 killed (polled 0 ms)
(qemu) device_del cpu7
(qemu) [ 984.476253] psci: CPU7 killed (polled 0 ms)
# cat /sys/devices/system/cpu/cpu*/online
1
1
1
1
# cat /sys/devices/system/cpu/possible
0-7
# cat /sys/devices/system/cpu/enabled
0-3
# cat /sys/devices/system/cpu/present
0-3
# cat /sys/devices/system/cpu/online
0-3
# cat /sys/devices/system/cpu/offline
4-7
>
> Anyway, feel free to post a v2 with the above proposal, cc Jonathan (on
> kernel.org) and James Morse and we'll take it from there. You can add a
> suggested-by me.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH rc v2 1/5] iommu/arm-smmu-v3: Add arm_smmu_adopt_strtab() for kdump
From: Nicolin Chen @ 2026-04-25 0:56 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, kevin.tian, joro, praan, baolu.lu,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <20260424205031.GK3444440@nvidia.com>
On Fri, Apr 24, 2026 at 05:50:31PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 11:33:16AM -0700, Nicolin Chen wrote:
> > On Fri, Apr 24, 2026 at 01:56:13PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Apr 15, 2026 at 02:17:36PM -0700, Nicolin Chen wrote:
> > > > +static int arm_smmu_adopt_strtab_2lvl(struct arm_smmu_device *smmu, u32 cfg_reg,
> > [..]
> > > > + cfg->l2.l1tab = devm_memremap(
> > > > + smmu->dev, dma, num_l1_ents * sizeof(struct arm_smmu_strtab_l1),
> > > > + MEMREMAP_WB);
> > >
> > > WB shouldn't be unconditional? If the SMMU is working non-coherently
> > > we need to map it NC. Same remark everwhere
> >
> > Hmm, I am trying to add a coherent-only gate for the series.
>
> OK, may just add a comment to that effect here
Yea, I will add an assertion to the adopt functions as well.
> > MEMREMAP_WC might work. But we cannot verify that on a coherent
> > SMMU, right?
>
> At most you could fake the smmu to noncoherent and check it maps the
> right thing and assume the arch code does it right
I see. I tend to leave it until somebody can verify. It should be
easy to make a followup change:
unsigned long flags = coherent ? MEMREMAP_WB : MEMREMAP_WC;
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v3 05/11] iommu: Change group->devices to RCU-protected list
From: Nicolin Chen @ 2026-04-25 0:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Baolu Lu, Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260424225820.GN3444440@nvidia.com>
On Fri, Apr 24, 2026 at 07:58:20PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 12:12:40PM -0700, Nicolin Chen wrote:
> > On Fri, Apr 24, 2026 at 10:11:48AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 23, 2026 at 08:08:59PM -0700, Nicolin Chen wrote:
> > > > On Fri, Apr 24, 2026 at 10:53:49AM +0800, Baolu Lu wrote:
> > > > > On 4/17/26 07:28, Nicolin Chen wrote:
> > > > > mutex_unlock(&group->mutex);
> > > > > /*
> > > > > * FIXME: Mis-locked because the ops->probe_finalize() call-back
> > > > > * of some IOMMU drivers calls arm_iommu_attach_device() which
> > > > > * in-turn might call back into IOMMU core code, where it tries
> > > > > * to take group->mutex, resulting in a deadlock.
> > > > > */
> > > > > for_each_group_device(group, gdev)
> > > > > iommu_group_do_probe_finalize(gdev->dev);
> > > > > }
> > > > >
> > > > > return 0;
> > > > > }
> > > > >
> > > > > Will the change above trigger a lockdep splat due to this "mis-locked"
> > > > > case?"
> > > >
> > > > Oh, I missed this one. That's a good finding!
> > > >
> > > > Perhaps we can just change it to list_for_each_entry_rcu holding
> > > > rcu_read_lock() and drop the FIXME.
> > >
> > > You can't hold rcu across that function IIRC
> >
> > Oh right. I didn't think too carefully...
> >
> > I tend to keep it as-is. So, maybe just list_for_each_entry?
>
> Does your series make this existing race materially worse?
I think it would be a status quo.
The only possible place is __iommu_group_remove_device() that this
series touched by changing the kfree(gdev) within the mutex to the
kfree_rcu(gdev, rcu) outside the mutex, which actually added small
delay. Though that doesn't fix a potential race, it shouldn't make
things worse.
Nicolin
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Ihor Solodrai @ 2026-04-24 23:31 UTC (permalink / raw)
To: Alexei Starovoitov, Andrey Konovalov
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: <CAADnVQKuptG_opA12O=Xb9_+cHf3f=ycAZdfUp17P2HBYQzdsg@mail.gmail.com>
On 4/19/26 3:51 PM, Alexei Starovoitov wrote:
> On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> 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.
>
> I feel concerns of misuse are overblown.
> Being in include/linux/kasan.h doesn't make them free-for-all
> all of a sudden, but if you prefer we can just copy paste:
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> into bpf_jit_comp.c
>
>>> 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.
>
> Ohh. Good point. Looks like modern arm64 cpus in public clouds
> don't have that enabled, so one would need pixel phone to
> catch verifier bugs via hw_tags.
This comment got me curious, and acckktually if we *really* want to,
we can get some KASAN_HW_TAGS testing for BPF already.
The first option is emulation, since QEMU supports MTE [1], e.g.:
qemu-system-aarch64 -machine virt,mte=on ...
This is of course slow, because it runs in software, so it's
infeasible to run this for every signle patch on BPF CI. But we could
run it on schedule on the base branches or smth like that.
[1] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
The second option is set up an AmpereOne machine on Oracle Cloud
(assuming they are available, haven't checked), because apparently [2]
those CPUs run with MTE.
It's a bunch of infra work and spending, but it is doable if it was
a priority.
[2] https://arxiv.org/abs/2511.17773
> So we still need this x86-specific jit kasan.
> I guess eventually it can be removed when hw_tags support is widespread.
^ permalink raw reply
* Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs
From: Alexei Starovoitov @ 2026-04-24 23:28 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Alexis Lothoré (eBPF Foundation), 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,
Andrey Konovalov, 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: <71fb19ff-6dde-43f4-a0e9-5c8cf2ba4ed4@linux.dev>
On Fri, Apr 24, 2026 at 4:10 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> I wonder if it's feasible to implement KASAN support on the verifier
> side in post-verification fixups. AI slop for illustration:
>
> ;; Original (1 BPF insn):
> dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
>
> ;; Rewrite (~7 BPF insns):
> r_tmp1 = src ; BPF_MOV64_REG
> r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
> r_tmp2 = r_tmp1 ; copy
> r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
> r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
> r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
> if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
> dst = *(u64 *)(src + off) ; original access (fast path)
> goto +1 ; skip slowpath
> call __asan_report_load8 ; BPF kfunc
> dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
>
> A sort of inline kasan directly in BPF.
>
> There are plenty of issues with it: instruction limit, exposing asan
> API as kfuncs, etc. On the flip side we get cross-arch support out of
> the box with no or mininal JIT changes.
>
> Honestly I'm not excited about this approach, but curious if anyone
> thought about this, or maybe it was already discussed?
We discussed this.
It won't work because we don't have that many temp registers for once
and second it has to preserve all (both callee and caller saved regs).
This is arch specific.
Second, we do not want other archs. This feature is x86-64 only.
It's being added to find _verifier_ bugs. To do that one arch is enough.
>
> > - not all memory accessing BPF instructions are being instrumented:
> > - it focuses on STX/LDX instructions
> > - it discards instructions accessing BPF program stack (already
> > monitored by page guards)
> > - it discards possibly faulting instructions, like BPF_PROBE_MEM or
> > BPF_PROBE_ATOMIC insns
> >
> > The series is marked and sent as RFC:
> > - to allow collecting feedback early and make sure that it goes into the
> > right direction
> > - because it depends on Xu's work to pass data between the verifier and
> > JIT compilers. This work is not merged yet, see [2]. I have been
> > tracking the various revisions he sent on the ML and based my local
> > branch on his work
> > - because tests brought by this series currently can't run on BPF CI:
> > they expect kasan multishot to be enabled, otherwise the first test
> > will make all other kasan-related tests fail.
>
> AFAICT this can be trivially fixed on BPF CI side, we just need to set
> kasan_multi_shot for the VMs running the tests. I will do that, your
> next revision doesn't have to be and RFC.
+1
> > - because some cases like atomic loads/stores are not instrumented yet
> > (and are still making me scratch my head)
> > - because it will hopefully provide a good basis to discuss the topic at
> > LSFMMBPF (see [3])
>
> Apparently, KASAN reporting routine takes a lock [1]:
>
> __asan_load()
> -> check_region_inline()
> -> kasan_report()
> -> start_report()
> -> raw_spin_lock_irqsave(&report_lock, *flags);
>
> BPF programs can run in NMI context, and so it appears to be possible
> to get an unflagged (because of lockdep_off() in start_report)
> deadlock, if an NMI fires on a CPU already holding report_lock.
> Although I guess you'd need two KASAN bugs to happen
> simultaneously for that to occur?... A rare event, I would hope.
>
> It could be addressed with either in_nmi() check at runtime, or
> forbidding kasan for NMI-runnable BPF program types.
We don't need that. If this bpf KASAN finds a bug, it means that
it found a verifier bug. All things are out of the window.
kasan_report() splat can just as well be the last thing that users will see.
^ permalink raw reply
* [PATCH 2/3] media: imx8-isi: add missing v4l2_subdev_cleanup() in crossbar and pipe
From: Xiaolei Wang @ 2026-04-24 23:19 UTC (permalink / raw)
To: laurent.pinchart, mchehab, Frank.Li, s.hauer, kernel, festevam,
aisheng.dong, jacopo, guoniu.zhou, s.riedmueller, Xiaolei.Wang
Cc: linux-media, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260424231926.406079-1-xiaolei.wang@windriver.com>
Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call
v4l2_subdev_init_finalize() which allocates the subdev active state,
but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup()
calls v4l2_subdev_cleanup() to free it.
This causes a memory leak on every rmmod, reported by kmemleak:
unreferenced object 0xffff0000d06fc800 (size 192):
comm "(udev-worker)", pid 254, jiffies 4294913455
backtrace (crc 36eeae58):
kmemleak_alloc+0x34/0x40
__kvmalloc_node_noprof+0x5f8/0x7d8
__v4l2_subdev_state_alloc+0x1fc/0x30c
__v4l2_subdev_init_finalize+0x178/0x368
Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup()
in both crossbar and pipe cleanup paths.
Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c | 1 +
drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
index 605a45124103..c580c831972e 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
@@ -491,6 +491,7 @@ int mxc_isi_crossbar_init(struct mxc_isi_dev *isi)
void mxc_isi_crossbar_cleanup(struct mxc_isi_crossbar *xbar)
{
+ v4l2_subdev_cleanup(&xbar->sd);
media_entity_cleanup(&xbar->sd.entity);
kfree(xbar->pads);
kfree(xbar->inputs);
diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
index a41c51dd9ce0..cb50af2270f6 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
@@ -819,6 +819,7 @@ void mxc_isi_pipe_cleanup(struct mxc_isi_pipe *pipe)
{
struct v4l2_subdev *sd = &pipe->sd;
+ v4l2_subdev_cleanup(sd);
media_entity_cleanup(&sd->entity);
mutex_destroy(&pipe->lock);
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] media: imx8-isi: fix use-after-free on remove
From: Xiaolei Wang @ 2026-04-24 23:19 UTC (permalink / raw)
To: laurent.pinchart, mchehab, Frank.Li, s.hauer, kernel, festevam,
aisheng.dong, jacopo, guoniu.zhou, s.riedmueller, Xiaolei.Wang
Cc: linux-media, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260424231926.406079-1-xiaolei.wang@windriver.com>
KASAN reports a slab-use-after-free in __media_entity_remove_link()
during rmmod of imx8_isi:
BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650
Read of size 2 at addr ffff0000d47cb02a by task rmmod/724
Call trace:
__media_entity_remove_link+0x608/0x650
__media_entity_remove_links+0x78/0x144
__media_device_unregister_entity+0x150/0x280
media_device_unregister_entity+0x48/0x68
v4l2_device_unregister_subdev+0x158/0x300
v4l2_async_unbind_subdev_one+0x22c/0x358
v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0
v4l2_async_nf_unregister+0x5c/0x14c
mxc_isi_remove+0x124/0x2a0 [imx8_isi]
Allocated by task 249:
__kmalloc_noprof+0x27c/0x690
mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi]
Freed by task 724:
kfree+0x1e4/0x5b0
mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi]
mxc_isi_remove+0x11c/0x2a0 [imx8_isi]
The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup()
before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media
entity pads, but the subsequent v4l2 cleanup still tries to remove
media links that reference those pads.
Fix this by calling mxc_isi_v4l2_cleanup() before
mxc_isi_crossbar_cleanup() to ensure all media entities are properly
unregistered while the pads are still valid.
Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
index 4bf8570e1b9e..2d639b789910 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
@@ -556,8 +556,8 @@ static void mxc_isi_remove(struct platform_device *pdev)
mxc_isi_pipe_cleanup(pipe);
}
- mxc_isi_crossbar_cleanup(&isi->crossbar);
mxc_isi_v4l2_cleanup(isi);
+ mxc_isi_crossbar_cleanup(&isi->crossbar);
}
static const struct of_device_id mxc_isi_of_match[] = {
--
2.43.0
^ permalink raw reply related
* [PATCH 3/3] media: imx8-isi: fix resource leaks in probe error paths and remove
From: Xiaolei Wang @ 2026-04-24 23:19 UTC (permalink / raw)
To: laurent.pinchart, mchehab, Frank.Li, s.hauer, kernel, festevam,
aisheng.dong, jacopo, guoniu.zhou, s.riedmueller, Xiaolei.Wang
Cc: linux-media, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260424231926.406079-1-xiaolei.wang@windriver.com>
mxc_isi_probe() allocates isi->pipes with kzalloc_objs() but never
frees it on any probe failure path or in mxc_isi_remove(), leaking
the allocation on every failed probe and every normal unbind.
Additionally, when mxc_isi_pipe_init() fails partway through the
channel loop or when mxc_isi_v4l2_init() fails, the already
initialized pipes are not cleaned up — their media entities and
mutexes are leaked.
Fix the pipes memory leak by switching from kzalloc_objs() to
devm_kcalloc(), which ties the allocation lifetime to the device
and eliminates the need for explicit kfree() in all error paths
and in mxc_isi_remove().
Fix the pipe init leak by cleaning up already-initialized pipes
in the err_xbar error path.
Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
index 2d639b789910..8533a979d60a 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
@@ -485,7 +485,8 @@ static int mxc_isi_probe(struct platform_device *pdev)
isi->pdata = of_device_get_match_data(dev);
- isi->pipes = kzalloc_objs(isi->pipes[0], isi->pdata->num_channels);
+ isi->pipes = devm_kcalloc(dev, isi->pdata->num_channels,
+ sizeof(*isi->pipes), GFP_KERNEL);
if (!isi->pipes)
return -ENOMEM;
@@ -538,6 +539,8 @@ static int mxc_isi_probe(struct platform_device *pdev)
return 0;
err_xbar:
+ while (i--)
+ mxc_isi_pipe_cleanup(&isi->pipes[i]);
mxc_isi_crossbar_cleanup(&isi->crossbar);
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] media: imx8-isi: fix resource lifecycle bugs
From: Xiaolei Wang @ 2026-04-24 23:19 UTC (permalink / raw)
To: laurent.pinchart, mchehab, Frank.Li, s.hauer, kernel, festevam,
aisheng.dong, jacopo, guoniu.zhou, s.riedmueller, Xiaolei.Wang
Cc: linux-media, imx, linux-arm-kernel, linux-kernel, stable
This series fixes three resource lifecycle issues in the imx8-isi driver,
all introduced by commit cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver").
Patch 1 fixes a use-after-free on rmmod: mxc_isi_remove() called
crossbar cleanup before v4l2 cleanup, freeing the crossbar pads while
the media framework still needed them to remove links. Fix by swapping
the cleanup order.
Patch 2 fixes a memory leak on rmmod: both crossbar and pipe cleanup
paths were missing v4l2_subdev_cleanup() calls to free the subdev
active state allocated by v4l2_subdev_init_finalize().
Patch 3 fixes resource leaks in probe error paths: the pipes array
allocated with kzalloc_objs() was never freed on failure or remove,
and already-initialized pipes were not cleaned up when a later pipe
init or v4l2 init failed. Fix by switching to devm_kcalloc() and
adding pipe cleanup in the error path.
Xiaolei Wang (3):
media: imx8-isi: fix use-after-free on remove
media: imx8-isi: add missing v4l2_subdev_cleanup() in crossbar and
pipe
media: imx8-isi: fix resource leaks in probe error paths and remove
drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c | 7 +++++--
drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c | 1 +
drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack
From: Ihor Solodrai @ 2026-04-24 23:18 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), 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, H. Peter Anvin, Shuah Khan, Maxime Coquelin,
Alexandre Torgue, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, Andrew Morton
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, Xu Kuohai, bpf,
linux-kernel, netdev, linux-kselftest, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-2-1a5831230821@bootlin.com>
On 4/13/26 11:28 AM, Alexis Lothoré (eBPF Foundation) wrote:
> In order to prepare to emit KASAN checks in JITed programs, JIT
> compilers need to be aware about whether some load/store instructions
> are targeting the bpf program stack, as those should not be monitored
> (we already have guard pages for that, and it is difficult anyway to
> correctly monitor any kind of data passed on stack).
>
> To support this need, make the BPF verifier mark the instructions that
> access program stack:
> - add a setter that allows the verifier to mark instructions accessing
> the program stack
> - add a getter that allows JIT compilers to check whether instructions
> being JITed are accessing the stack
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> include/linux/bpf.h | 2 ++
> include/linux/bpf_verifier.h | 2 ++
> kernel/bpf/core.c | 10 ++++++++++
> kernel/bpf/verifier.c | 7 +++++++
> 4 files changed, 21 insertions(+)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index b4b703c90ca9..774a0395c498 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -1543,6 +1543,8 @@ void bpf_jit_uncharge_modmem(u32 size);
> bool bpf_prog_has_trampoline(const struct bpf_prog *prog);
> bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struct bpf_prog *prog,
> int insn_idx);
> +bool bpf_insn_accesses_stack(const struct bpf_verifier_env *env,
> + const struct bpf_prog *prog, int insn_idx);
> #else
> static inline int bpf_trampoline_link_prog(struct bpf_tramp_link *link,
> struct bpf_trampoline *tr,
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index b148f816f25b..ab99ed4c4227 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -660,6 +660,8 @@ struct bpf_insn_aux_data {
> u16 const_reg_map_mask;
> u16 const_reg_subprog_mask;
> u32 const_reg_vals[10];
> + /* instruction accesses stack */
> + bool accesses_stack;
> };
>
> #define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 8b018ff48875..340abfdadbed 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1582,6 +1582,16 @@ bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struc
> insn_idx += prog->aux->subprog_start;
> return env->insn_aux_data[insn_idx].indirect_target;
> }
> +
> +bool bpf_insn_accesses_stack(const struct bpf_verifier_env *env,
> + const struct bpf_prog *prog, int insn_idx)
> +{
> + if (!env)
> + return false;
> + insn_idx += prog->aux->subprog_start;
> + return env->insn_aux_data[insn_idx].accesses_stack;
> +}
> +
> #endif /* CONFIG_BPF_JIT */
>
> /* Base function for offset calculation. Needs to go into .text section,
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 1e36b9e91277..7bce4fb4e540 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3502,6 +3502,11 @@ static void mark_indirect_target(struct bpf_verifier_env *env, int idx)
> env->insn_aux_data[idx].indirect_target = true;
> }
>
> +static void mark_insn_accesses_stack(struct bpf_verifier_env *env, int idx)
> +{
> + env->insn_aux_data[idx].accesses_stack = true;
> +}
> +
> #define LR_FRAMENO_BITS 3
> #define LR_SPI_BITS 6
> #define LR_ENTRY_BITS (LR_SPI_BITS + LR_FRAMENO_BITS + 1)
> @@ -6490,6 +6495,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> else
> err = check_stack_write(env, regno, off, size,
> value_regno, insn_idx);
> +
> + mark_insn_accesses_stack(env, insn_idx);
I am not sure this can be done unconditionally here.
It may be possible in different states to have different pointer
types for the affected reg (PTR_TO_STACK in one execution path and say
PTR_TO_MAP_VALUE in another). And if set uncoditionally,
instrumentation may be skipped for legitimate targets.
Maybe reset by default in check_mem_access()?
> } else if (reg_is_pkt_pointer(reg)) {
> if (t == BPF_WRITE && !may_access_direct_pkt_data(env, NULL, t)) {
> verbose(env, "cannot write into packet\n");
>
^ permalink raw reply
* Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs
From: Ihor Solodrai @ 2026-04-24 23:10 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), 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, H. Peter Anvin, Shuah Khan, Maxime Coquelin,
Alexandre Torgue, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, Andrew Morton
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, Xu Kuohai, bpf,
linux-kernel, netdev, linux-kselftest, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-0-1a5831230821@bootlin.com>
On 4/13/26 11:28 AM, Alexis Lothoré (eBPF Foundation) wrote:
> Hello,
> this series aims to bring basic support for KASAN checks to BPF JITed
> programs. This follows the first RFC posted in [1].
Hi Alexis,
Thank you for working on this, it's a real testing gap.
I have a few comments, see below.
The series doesn't apply cleanly on bpf-next right now, but I was able
to apply to a little older revision (eb5249b12507).
>
> KASAN allows to spot memory management mistakes by reserving a fraction
> of memory as "shadow memory" that will map to the rest of the memory and
> allow its monitoring. Each memory-accessing instruction is then
> instrumented at build time to call some ASAN check function, that will
> analyze the corresponding bits in shadow memory, and if it detects the
> access as invalid, trigger a detailed report. The goal of this series is
> to replicate this mechanism for BPF programs when they are being JITed
> into native instructions: that's then the (runtime) JIT compiler who is
> in charge of inserting calls to the corresponding kasan checks, when a
> program is being loaded into the kernel. This task involves:
> - identifying at program load time the instructions performing memory
> accesses
> - identifying those accesses properties (size ? read or write ?) to
> define the relevant kasan check function to call
> - just before the identified instructions:
> - perform the basic context saving (ie: saving registers)
> - inserting a call to the relevant kasan check function
> - restore context
> - whenever the instrumented program executes, if it performs an invalid
> access, it triggers a kasan report identical to those instrumented on
> kernel side at build time.
>
> As discussed in [1], this series is based on some choices and
> assumptions:
> - it focuses on x86_64 for now, and so only on KASAN_GENERIC
I wonder if it's feasible to implement KASAN support on the verifier
side in post-verification fixups. AI slop for illustration:
;; Original (1 BPF insn):
dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
;; Rewrite (~7 BPF insns):
r_tmp1 = src ; BPF_MOV64_REG
r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
r_tmp2 = r_tmp1 ; copy
r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
dst = *(u64 *)(src + off) ; original access (fast path)
goto +1 ; skip slowpath
call __asan_report_load8 ; BPF kfunc
dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
A sort of inline kasan directly in BPF.
There are plenty of issues with it: instruction limit, exposing asan
API as kfuncs, etc. On the flip side we get cross-arch support out of
the box with no or mininal JIT changes.
Honestly I'm not excited about this approach, but curious if anyone
thought about this, or maybe it was already discussed?
> - not all memory accessing BPF instructions are being instrumented:
> - it focuses on STX/LDX instructions
> - it discards instructions accessing BPF program stack (already
> monitored by page guards)
> - it discards possibly faulting instructions, like BPF_PROBE_MEM or
> BPF_PROBE_ATOMIC insns
>
> The series is marked and sent as RFC:
> - to allow collecting feedback early and make sure that it goes into the
> right direction
> - because it depends on Xu's work to pass data between the verifier and
> JIT compilers. This work is not merged yet, see [2]. I have been
> tracking the various revisions he sent on the ML and based my local
> branch on his work
> - because tests brought by this series currently can't run on BPF CI:
> they expect kasan multishot to be enabled, otherwise the first test
> will make all other kasan-related tests fail.
AFAICT this can be trivially fixed on BPF CI side, we just need to set
kasan_multi_shot for the VMs running the tests. I will do that, your
next revision doesn't have to be and RFC.
> - because some cases like atomic loads/stores are not instrumented yet
> (and are still making me scratch my head)
> - because it will hopefully provide a good basis to discuss the topic at
> LSFMMBPF (see [3])
Apparently, KASAN reporting routine takes a lock [1]:
__asan_load()
-> check_region_inline()
-> kasan_report()
-> start_report()
-> raw_spin_lock_irqsave(&report_lock, *flags);
BPF programs can run in NMI context, and so it appears to be possible
to get an unflagged (because of lockdep_off() in start_report)
deadlock, if an NMI fires on a CPU already holding report_lock.
Although I guess you'd need two KASAN bugs to happen
simultaneously for that to occur?... A rare event, I would hope.
It could be addressed with either in_nmi() check at runtime, or
forbidding kasan for NMI-runnable BPF program types.
That said, this may be a case of being overly defensive to appease the
ai overlords.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/kasan/report.c?h=v7.0#n204
>
> Despite this series not being ready for integration yet, anyone
> interested in running it locally can perform the following steps to run
> the JITed KASAN instrumentation selftests:
> - rebasing locally this series on [2]
> - building and running the corresponding kernel with kasan_multi_shot
> enabled
> - running `test_progs -a kasan`
>
> And should get a variety of KASAN tests executed for BPF programs:
>
> #162/1 kasan/bpf_kasan_uaf_read_1:OK
> #162/2 kasan/bpf_kasan_uaf_read_2:OK
> #162/3 kasan/bpf_kasan_uaf_read_4:OK
> #162/4 kasan/bpf_kasan_uaf_read_8:OK
> #162/5 kasan/bpf_kasan_uaf_write_1:OK
> #162/6 kasan/bpf_kasan_uaf_write_2:OK
> #162/7 kasan/bpf_kasan_uaf_write_4:OK
> #162/8 kasan/bpf_kasan_uaf_write_8:OK
> #162/9 kasan/bpf_kasan_oob_read_1:OK
> #162/10 kasan/bpf_kasan_oob_read_2:OK
> #162/11 kasan/bpf_kasan_oob_read_4:OK
> #162/12 kasan/bpf_kasan_oob_read_8:OK
> #162/13 kasan/bpf_kasan_oob_write_1:OK
> #162/14 kasan/bpf_kasan_oob_write_2:OK
> #162/15 kasan/bpf_kasan_oob_write_4:OK
> #162/16 kasan/bpf_kasan_oob_write_8:OK
> #162 kasan:OK
> Summary: 1/16 PASSED, 0 SKIPPED, 0 FAILED
>
> [1] https://lore.kernel.org/bpf/DG7UG112AVBC.JKYISDTAM30T@bootlin.com/
> [2] https://lore.kernel.org/bpf/cover.1776062885.git.xukuohai@hotmail.com/
> [3] https://lore.kernel.org/bpf/DGGNCXX79H8O.2P6K8L1QW1M8K@bootlin.com/
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> Alexis Lothoré (eBPF Foundation) (8):
> kasan: expose generic kasan helpers
> bpf: mark instructions accessing program stack
> bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
> bpf, x86: add helper to emit kasan checks in x86 JITed programs
> bpf, x86: emit KASAN checks into x86 JITed programs
> selftests/bpf: do not run verifier JIT tests when BPF_JIT_KASAN is enabled
> bpf, x86: enable KASAN for JITed programs on x86
> selftests/bpf: add tests to validate KASAN on JIT programs
>
> arch/x86/Kconfig | 1 +
> arch/x86/net/bpf_jit_comp.c | 106 +++++++++++++
> include/linux/bpf.h | 2 +
> include/linux/bpf_verifier.h | 2 +
> include/linux/kasan.h | 13 ++
> kernel/bpf/Kconfig | 9 ++
> kernel/bpf/core.c | 10 ++
> kernel/bpf/verifier.c | 7 +
> mm/kasan/kasan.h | 10 --
> tools/testing/selftests/bpf/prog_tests/kasan.c | 165 +++++++++++++++++++++
> tools/testing/selftests/bpf/progs/kasan.c | 146 ++++++++++++++++++
> .../testing/selftests/bpf/test_kmods/bpf_testmod.c | 79 ++++++++++
> tools/testing/selftests/bpf/test_loader.c | 5 +
> tools/testing/selftests/bpf/unpriv_helpers.c | 5 +
> tools/testing/selftests/bpf/unpriv_helpers.h | 1 +
> 15 files changed, 551 insertions(+), 10 deletions(-)
> ---
> base-commit: 7990a071b32887a1a883952e8cf60134b6d6fea0
> change-id: 20260126-kasan-fcd68f64cd7b
>
> Best regards,
> --
> Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>
^ permalink raw reply
* Re: [RFC PATCH 2/5] arm64: dts: rockchip: add ISP nodes to rk3588
From: Laurent Pinchart @ 2026-04-24 23:00 UTC (permalink / raw)
To: Paul Elder
Cc: Xu Hongfei, michael.riesch, stefan.klug, linux-media,
linux-arm-kernel, linux-rockchip, linux-kernel, Heiko Stuebner
In-Reply-To: <20260424175853.638202-3-paul.elder@ideasonboard.com>
Hi Paul,
Thank you for the patch.
On Sat, Apr 25, 2026 at 02:58:47AM +0900, Paul Elder wrote:
> From: Xu Hongfei <xuhf@rock-chips.com>
>
> Add device tree nodes for the ISP and their iommus on the RK3588.
>
> Signed-off-by: Xu Hongfei <xuhf@rock-chips.com>
> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 60 +++++++++++++++++++
> 1 file changed, 60 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> index 8b98e5c3cc8b..607b03d55dfd 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> @@ -3535,6 +3535,66 @@ gpio4: gpio@fec50000 {
> #interrupt-cells = <2>;
> };
> };
> +
> + isp0: isp@fdcb0000 {
> + compatible = "rockchip,rk3588-isp";
> + reg = <0x0 0xfdcb0000 0x0 0x7f00>;
> + interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "isp_irq", "mi_irq";
> + clocks = <&cru ACLK_ISP0>, <&cru HCLK_ISP0>,
> + <&cru CLK_ISP0_CORE>, <&cru CLK_ISP0_CORE_MARVIN>,
> + <&cru CLK_ISP0_CORE_VICAP>;
> + clock-names = "aclk", "hclk", "clk_core",
> + "clk_core_marvin", "clk_core_vicap";
> + power-domains = <&power RK3588_PD_VI>;
> + iommus = <&isp0_mmu>;
> + status = "disabled";
> + };
> +
> + isp0_mmu: iommu@fdcb7f00 {
> + compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> + reg = <0x0 0xfdcb7f00 0x0 0x100>;
> + interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "isp0_mmu";
I don't think interrupt-names is needed. Same for the second IOMMU.
> + clocks = <&cru ACLK_ISP0>, <&cru HCLK_ISP0>;
> + clock-names = "aclk", "iface";
> + power-domains = <&power RK3588_PD_VI>;
> + #iommu-cells = <0>;
> + rockchip,disable-mmu-reset;
> + status = "disabled";
> + };
> +
> + isp1: isp@fdcc0000 {
> + compatible = "rockchip,rk3588-isp";
> + reg = <0x0 0xfdcc0000 0x0 0x7f00>;
> + interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "isp_irq", "mi_irq";
> + clocks = <&cru ACLK_ISP1>, <&cru HCLK_ISP1>,
> + <&cru CLK_ISP1_CORE>, <&cru CLK_ISP1_CORE_MARVIN>,
> + <&cru CLK_ISP1_CORE_VICAP>;
> + clock-names = "aclk", "hclk", "clk_core",
> + "clk_core_marvin", "clk_core_vicap";
> + power-domains = <&power RK3588_PD_ISP1>;
> + iommus = <&isp1_mmu>;
> + status = "disabled";
> + };
> +
> + isp1_mmu: iommu@fdcc7f00 {
> + compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> + reg = <0x0 0xfdcc7f00 0x0 0x100>;
> + interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "isp1_mmu";
> + clocks = <&cru ACLK_ISP1>, <&cru HCLK_ISP1>;
> + clock-names = "aclk", "iface";
> + power-domains = <&power RK3588_PD_ISP1>;
> + #iommu-cells = <0>;
> + rockchip,disable-mmu-reset;
> + status = "disabled";
> + };
> };
>
> #include "rk3588-base-pinctrl.dtsi"
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 05/11] iommu: Change group->devices to RCU-protected list
From: Jason Gunthorpe @ 2026-04-24 22:58 UTC (permalink / raw)
To: Nicolin Chen
Cc: Baolu Lu, Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <aevAqKFq7ATYk3+i@Asurada-Nvidia>
On Fri, Apr 24, 2026 at 12:12:40PM -0700, Nicolin Chen wrote:
> On Fri, Apr 24, 2026 at 10:11:48AM -0300, Jason Gunthorpe wrote:
> > On Thu, Apr 23, 2026 at 08:08:59PM -0700, Nicolin Chen wrote:
> > > On Fri, Apr 24, 2026 at 10:53:49AM +0800, Baolu Lu wrote:
> > > > On 4/17/26 07:28, Nicolin Chen wrote:
> > > > mutex_unlock(&group->mutex);
> > > > /*
> > > > * FIXME: Mis-locked because the ops->probe_finalize() call-back
> > > > * of some IOMMU drivers calls arm_iommu_attach_device() which
> > > > * in-turn might call back into IOMMU core code, where it tries
> > > > * to take group->mutex, resulting in a deadlock.
> > > > */
> > > > for_each_group_device(group, gdev)
> > > > iommu_group_do_probe_finalize(gdev->dev);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Will the change above trigger a lockdep splat due to this "mis-locked"
> > > > case?"
> > >
> > > Oh, I missed this one. That's a good finding!
> > >
> > > Perhaps we can just change it to list_for_each_entry_rcu holding
> > > rcu_read_lock() and drop the FIXME.
> >
> > You can't hold rcu across that function IIRC
>
> Oh right. I didn't think too carefully...
>
> I tend to keep it as-is. So, maybe just list_for_each_entry?
Does your series make this existing race materially worse?
Jason
^ permalink raw reply
* Re: [PATCH 1/1] Revert "scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()"
From: Bart Van Assche @ 2026-04-24 22:55 UTC (permalink / raw)
To: ed.tsai, Alim Akhtar, James E.J. Bottomley, Martin K. Petersen,
Matthias Brugger, AngeloGioacchino Del Regno, Avri Altman
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, linux-scsi
In-Reply-To: <20260424063603.382328-2-ed.tsai@mediatek.com>
On 4/23/26 11:35 PM, ed.tsai@mediatek.com wrote:
> Note that these DMA addresses are only used in ufshcd_print_tr() for
> error logging, so the impact is limited to misleading error logs.
Instead of fixing these offsets, please remove the ucd_rsp_dma_addr and
ucd_prdt_dma_addr members from struct ufshcd_lrb.
Thanks,
Bart.
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-24 22:49 UTC (permalink / raw)
To: Paul Moore
Cc: Yeoreum Yun, roberto.sassu, Jonathan McDowell,
linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, jmorris, serge, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <CAHC9VhS4JmPmCJrYTdbjxb3TO-uK6cB3Zij-ef=wswGce2BGzg@mail.gmail.com>
On Fri, 2026-04-24 at 18:10 -0400, Paul Moore wrote:
> (I'm assuming you meant initcall and not syscall above, but if you're
> talking about something else, please let me know.)
>
> Saying that you aren't comfortable moving IMA initialization to
> late-sync is inconsistent with allowing IMA initialization to be
> deferred to late-sync. Either it is okay to initialize IMA in
> late-sync or it isn't. You must pick one.
Yes, we're discussing late_initcall and late_initcall_sync.
I prefer to look at it as being pragmatic. I'd rather err on the side of caution
and not move the syscall to late_initcall_sync, than move it. However, others
have moved the syscall to address the TPM-bypass issue for their environment.
Mimi
^ permalink raw reply
* [RFC PATCH net-next 3/3] net: macb: add TX stall watchdog as defence-in-depth safety net
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
Patches 1/3 and 2/3 address two candidate races that could lead
to a TCOMP completion being missed on PCIe-attached macb
instances. This patch adds a defence-in-depth safety net, in
case a further race remains that we have not identified.
The watchdog is a per-queue delayed_work that runs once per
second. It snapshots queue->tx_tail; if the ring is non-empty
(queue->tx_head != queue->tx_tail) and tx_tail has not advanced
since the previous tick, it calls macb_tx_restart().
No new recovery logic is introduced. macb_tx_restart() already
exists in this file, is correctly locked (tx_ptr_lock, bp->lock),
and verifies that the hardware's TBQP is behind the driver's
head index before re-asserting TSTART. On a healthy ring it is
a no-op at the hardware level; the watchdog only supplies the
missing trigger.
On a healthy queue the per-tick cost is one spin_lock_irqsave()
/ spin_unlock_irqrestore() and one branch. The delayed_work is
only scheduled between macb_open() and macb_close(), and is
cancelled synchronously on close.
Context for submission: on our 24-node Raspberry Pi 5 fleet,
before this series, an out-of-band user-space watchdog
(monitoring tx_packets from /sys/class/net/.../statistics and
toggling the link down/up when it froze) was required to keep
nodes usable. We include this kernel-side watchdog as a cleaner
in-kernel equivalent for any residual stall that patches 1 and
2 do not cover. We are willing to drop this patch if the view
is that 1 and 2 should stand alone.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb.h | 5 ++
drivers/net/ethernet/cadence/macb_main.c | 59 ++++++++++++++++++++++++
2 files changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 2de56017e..9115f2b47 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -1278,6 +1278,11 @@ struct macb_queue {
dma_addr_t tx_ring_dma;
struct work_struct tx_error_task;
bool txubr_pending;
+
+ /* TX stall watchdog -- see macb_tx_stall_watchdog() in macb_main.c */
+ struct delayed_work tx_stall_watchdog_work;
+ unsigned int tx_stall_last_tail;
+
struct napi_struct napi_tx;
dma_addr_t rx_ring_dma;
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index ea231b1c5..ea2306ef7 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2002,6 +2002,59 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
return work_done;
}
+#define MACB_TX_STALL_INTERVAL_MS 1000
+
+/*
+ * TX stall watchdog.
+ *
+ * Defence-in-depth against lost TCOMP interrupts. macb already has a
+ * recovery chain (tx_pending -> txubr_pending -> macb_tx_restart())
+ * that fires on TCOMP; if TCOMP itself is lost the TX ring stalls
+ * silently until something else kicks TSTART. This watchdog runs
+ * once per second per queue, snapshots tx_tail, and calls
+ * macb_tx_restart() if the ring is non-empty and tx_tail has not
+ * advanced since the previous tick.
+ *
+ * macb_tx_restart() already checks the hardware's TBQP against the
+ * driver's head index before re-asserting TSTART, so on a healthy
+ * ring this is a no-op at the hardware level. The watchdog only
+ * adds the missing trigger.
+ */
+static void macb_tx_stall_watchdog(struct work_struct *work)
+{
+ struct macb_queue *queue = container_of(to_delayed_work(work),
+ struct macb_queue,
+ tx_stall_watchdog_work);
+ struct macb *bp = queue->bp;
+ unsigned int cur_tail, cur_head;
+ bool stalled = false;
+ unsigned long flags;
+
+ if (!netif_running(bp->dev))
+ return;
+
+ spin_lock_irqsave(&queue->tx_ptr_lock, flags);
+ cur_tail = queue->tx_tail;
+ cur_head = queue->tx_head;
+ if (cur_head != cur_tail &&
+ cur_tail == queue->tx_stall_last_tail)
+ stalled = true;
+ else
+ queue->tx_stall_last_tail = cur_tail;
+ spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
+
+ if (stalled) {
+ netdev_warn_once(bp->dev,
+ "TX stall detected on queue %u (tail=%u head=%u); re-kicking TSTART\n",
+ (unsigned int)(queue - bp->queues),
+ cur_tail, cur_head);
+ macb_tx_restart(queue);
+ }
+
+ schedule_delayed_work(&queue->tx_stall_watchdog_work,
+ msecs_to_jiffies(MACB_TX_STALL_INTERVAL_MS));
+}
+
static void macb_hresp_error_task(struct work_struct *work)
{
struct macb *bp = from_work(bp, work, hresp_err_bh_work);
@@ -3190,6 +3243,9 @@ static int macb_open(struct net_device *dev)
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
napi_enable(&queue->napi_rx);
napi_enable(&queue->napi_tx);
+ queue->tx_stall_last_tail = queue->tx_tail;
+ schedule_delayed_work(&queue->tx_stall_watchdog_work,
+ msecs_to_jiffies(MACB_TX_STALL_INTERVAL_MS));
}
macb_init_hw(bp);
@@ -3240,6 +3296,7 @@ static int macb_close(struct net_device *dev)
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
napi_disable(&queue->napi_rx);
napi_disable(&queue->napi_tx);
+ cancel_delayed_work_sync(&queue->tx_stall_watchdog_work);
netdev_tx_reset_queue(netdev_get_tx_queue(dev, q));
}
@@ -4802,6 +4859,8 @@ static int macb_init_dflt(struct platform_device *pdev)
}
INIT_WORK(&queue->tx_error_task, macb_tx_error_task);
+ INIT_DELAYED_WORK(&queue->tx_stall_watchdog_work,
+ macb_tx_stall_watchdog);
q++;
}
--
2.53.0
^ permalink raw reply related
* [RFC PATCH net-next 2/3] net: macb: re-check ISR after IER re-enable in macb_tx_poll
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
macb_tx_poll() runs with TCOMP masked, drains the TX ring, then
calls napi_complete_done() and re-enables TCOMP via IER. An
existing comment in the function notes:
/* Packet completions only seem to propagate to raise
* interrupts when interrupts are enabled at the time, so if
* packets were sent while interrupts were disabled,
* they will not cause another interrupt to be generated when
* interrupts are re-enabled.
*/
and mitigates this by calling macb_tx_complete_pending(), which
inspects driver-visible ring state (descriptor->ctrl, after rmb())
and reschedules NAPI if a completion is observable in memory.
On PCIe-attached parts (BCM2712 + RP1 on Raspberry Pi 5 is the
setup we have in front of us), the descriptor DMA write that sets
TX_USED may not have retired to system memory at the point
macb_tx_complete_pending() runs. The rmb() synchronises the CPU
view of earlier CPU writes; it is not sufficient to retire an
in-flight peripheral DMA write. Under that ordering the in-memory
descriptor can still read TX_USED=0 when the hardware has in fact
completed the frame; the check returns false; NAPI exits; the
quirk above prevents the re-enabled IER from re-firing; the ring
goes quiescent.
Add an explicit ISR read after the IER write. The MMIO read
serves two independent purposes:
(1) It is an architected PCIe read barrier for earlier
peripheral-originated DMA writes on the same path, so a
subsequent macb_tx_complete_pending() observes any TX_USED
write that was in flight at the time of the barrier.
(2) It samples the hardware ISR directly, so a TCOMP bit that
the hardware set while TCOMP was masked is visible here,
independently of whether the descriptor DMA has retired.
If either signal indicates pending work, reschedule NAPI via the
same path as the existing check.
This patch addresses one of three candidate races for the silent
TX stall described in the cover letter. Whether it is sufficient
by itself, or whether it requires the PCIe posted-write flush in
patch 1/3 to cover the observed behaviour, we have not yet
verified at runtime.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb_main.c | 28 +++++++++++++++---------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index b6cca55ad..ea231b1c5 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1973,17 +1973,25 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
if (work_done < budget && napi_complete_done(napi, work_done)) {
queue_writel(queue, IER, MACB_BIT(TCOMP));
- /* Packet completions only seem to propagate to raise
- * interrupts when interrupts are enabled at the time, so if
- * packets were sent while interrupts were disabled,
- * they will not cause another interrupt to be generated when
- * interrupts are re-enabled.
- * Check for this case here to avoid losing a wakeup. This can
- * potentially race with the interrupt handler doing the same
- * actions if an interrupt is raised just after enabling them,
- * but this should be harmless.
+ /*
+ * TCOMP events that fire while the interrupt is masked do
+ * not re-fire when IER is re-enabled. Catch this two ways
+ * to avoid losing a wakeup:
+ *
+ * (1) Read ISR -- catches completions the hardware flagged
+ * but that we did not see as an interrupt. The MMIO
+ * read doubles as a PCIe read barrier, flushing any
+ * in-flight descriptor TX_USED DMA writes into memory.
+ * (2) macb_tx_complete_pending() inspects the ring after
+ * that flush, catching a descriptor whose TX_USED is
+ * now visible as a result of the barrier.
+ *
+ * This can race with the interrupt handler taking the same
+ * path if an interrupt fires just after the IER write;
+ * rescheduling NAPI in that case is harmless.
*/
- if (macb_tx_complete_pending(queue)) {
+ if ((queue_readl(queue, ISR) & MACB_BIT(TCOMP)) ||
+ macb_tx_complete_pending(queue)) {
queue_writel(queue, IDR, MACB_BIT(TCOMP));
macb_queue_isr_clear(bp, queue, MACB_BIT(TCOMP));
netdev_vdbg(bp->dev, "TX poll: packets pending, reschedule\n");
--
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