* [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the users throughout the renesas device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---
.../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso | 3 ++-
.../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso | 3 ++-
.../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso | 3 ++-
.../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso | 3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
index 3acaf714cf24..b816382bba0a 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
+++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
@@ -12,6 +12,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
&{/} {
clk_cam_j1: clk-cam-j1 {
@@ -44,7 +45,7 @@ cam@10 {
VDIG-supply = <®_cam_j1>;
VDDL-supply = <®_cam_j1>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
index a19bc0840392..4019b80a88b7 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
+++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
@@ -12,6 +12,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
&{/} {
clk_cam_j1: clk-cam-j1 {
@@ -46,7 +47,7 @@ cam@1a {
vdda-supply = <®_cam_j1>;
vddd-supply = <®_cam_j1>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
index 512810b861aa..fea1ef4a1178 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
+++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
@@ -12,6 +12,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
&{/} {
clk_cam_j2: clk-cam-j2 {
@@ -44,7 +45,7 @@ cam@10 {
VDIG-supply = <®_cam_j2>;
VDDL-supply = <®_cam_j2>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
index a31524b59834..177201a8a6d2 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
+++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
@@ -12,6 +12,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
&{/} {
clk_cam_j2: clk-cam-j2 {
@@ -46,7 +47,7 @@ cam@1a {
vdda-supply = <®_cam_j2>;
vddd-supply = <®_cam_j2>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 8/8] arm64: dts: rockchip: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the users throughout the rockchip device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi | 3 ++-
arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso | 3 ++-
arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++--
.../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 3 ++-
.../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 3 ++-
5 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
index 192791993f05..d58d6ee6241e 100644
--- a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
@@ -6,6 +6,7 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include "px30.dtsi"
@@ -413,7 +414,7 @@ camera@36 {
dvdd-supply = <&vcc_cam_dvdd>;
dovdd-supply = <&vcc_cam_dovdd>;
lens-focus = <&focus>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
pinctrl-names = "default";
pinctrl-0 = <&cif_clkout_m0 &cam_pwdn>;
reset-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
index 760d5139f95d..2168db9168a5 100644
--- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
+++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
@@ -16,6 +16,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
&{/} {
@@ -185,7 +186,7 @@ camera@36 {
dvdd-supply = <&cam_dvdd_1v2>;
dovdd-supply = <&cam_dovdd_1v8>;
lens-focus = <&focus>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
pinctrl-names = "default";
pinctrl-0 = <&cif_clkout_m0>;
reset-gpios = <&pca9670 6 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 8d26bd9b7500..6608c777f185 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -13,6 +13,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include "rk3399-s.dtsi"
/ {
@@ -455,7 +456,7 @@ wcam: camera@1a {
reg = <0x1a>;
clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK0, derived from CIF_CLKO */
lens-focus = <&wcam_lens>;
- orientation = <1>; /* V4L2_CAMERA_ORIENTATION_BACK */
+ orientation = <MEDIA_ORIENTATION_BACK>;
pinctrl-names = "default";
pinctrl-0 = <&camera_rst_l>;
reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;
@@ -487,7 +488,7 @@ ucam: camera@36 {
clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK1, derived from CIF_CLK0 */
clock-names = "xvclk";
dovdd-supply = <&vcc1v8_dvp>;
- orientation = <0>; /* V4L2_CAMERA_ORIENTATION_FRONT */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
pinctrl-names = "default";
pinctrl-0 = <&camera2_rst_l &dvp_pdn0_h>;
powerdown-gpios = <&gpio2 RK_PB4 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
index ee9ecf68a886..8c9a4a1181e4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
@@ -9,6 +9,7 @@
#include <dt-bindings/clock/rockchip,rk3588-cru.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
&{/} {
@@ -50,7 +51,7 @@ imx415: camera-sensor@1a {
avdd-supply = <&savdd_cam0>;
clocks = <&cru CLK_MIPI_CAMARAOUT_M3>;
dvdd-supply = <&sdvdd_cam0>;
- orientation = <2>; /* External */
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
ovdd-supply = <&siovdd_cam0>;
pinctrl-names = "default";
pinctrl-0 = <&cam0_rstn &mipim0_camera3_clk>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
index 8a4cf3fdbf8e..0cc3d6a34cef 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
@@ -9,6 +9,7 @@
#include <dt-bindings/clock/rockchip,rk3588-cru.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
&{/} {
@@ -50,7 +51,7 @@ cam1_imx415: camera-sensor@1a {
avdd-supply = <&savdd_cam1>;
clocks = <&cru CLK_MIPI_CAMARAOUT_M4>;
dvdd-supply = <&sdvdd_cam1>;
- orientation = <2>; /* External */
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
ovdd-supply = <&siovdd_cam1>;
pinctrl-names = "default";
pinctrl-0 = <&cam1_rstn &mipim0_camera4_clk>;
--
2.52.0
^ permalink raw reply related
* [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the users throughout the qualcomm device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 3 ++-
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 ++-
arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 04cb9230d29f..d79be22108c8 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -13,6 +13,7 @@
#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
#include <dt-bindings/leds/common.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/sound/qcom,q6asm.h>
@@ -701,7 +702,7 @@ camera@10 {
pinctrl-0 = <&cam_mclk3_default>;
pinctrl-names = "default";
- orientation = <0>; /* Front facing */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
rotation = <270>;
port {
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index abd9c5a67b9f..543fc691fd3c 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -11,6 +11,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sc8280xp.dtsi"
@@ -682,7 +683,7 @@ camera@10 {
clocks = <&camcc CAMCC_MCLK3_CLK>;
- orientation = <0>; /* Front facing */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
avdd-supply = <&vreg_l6q>;
dvdd-supply = <&vreg_l2q>;
diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
index 0f57b915186b..375b3c0edea7 100644
--- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
@@ -9,6 +9,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include "sdm670.dtsi"
@@ -460,7 +461,7 @@ camera@1a {
pinctrl-names = "default";
rotation = <270>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
cam_front_endpoint: endpoint {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 5/8] arm64: dts: freescale: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the users throughout the freescale/NXP device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
.../boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso | 3 ++-
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
index e5a2b3780215..7b44ae0f19b2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
@@ -9,6 +9,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include "imx8mp-pinfunc.h"
@@ -47,7 +48,7 @@ camera@10 {
VANA-supply = <®_cam>;
VDIG-supply = <®_cam>;
VDDL-supply = <®_cam>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index f5d529c5baf3..178cfad93483 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -8,6 +8,7 @@
#include "dt-bindings/input/input.h"
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include "dt-bindings/pwm/pwm.h"
#include "dt-bindings/usb/pd.h"
#include "imx8mq.dtsi"
@@ -1116,7 +1117,7 @@ camera_front: camera@20 {
vddd-supply = <®_vcam_1v2>;
vddio-supply = <®_csi_1v8>;
rotation = <90>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
camera1_ep: endpoint {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the users throughout the nvidia device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
index 892d718294dd..a7fdd194300c 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
@@ -3,6 +3,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/power/summit,smb347-charger.h>
#include <dt-bindings/thermal/thermal.h>
@@ -991,7 +992,7 @@ front-camera@48 {
vdd-supply = <&vddio_cam>;
vaa-supply = <&avdd_cam1>;
- orientation = <0>; /* Front camera */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
<&tegra_car TEGRA30_CLK_CSUS>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
index bf1c3a31d406..76286e15684c 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
@@ -3,6 +3,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/thermal/thermal.h>
#include "tegra30.dtsi"
@@ -1262,7 +1263,7 @@ front-camera@48 {
vdd-supply = <&vdd_1v8_cam>;
vaa-supply = <&avdd_2v85_fcam>;
- orientation = <0>; /* Front camera */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
<&tegra_car TEGRA30_CLK_CSUS>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
index 896639599c12..28680063bcc0 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
+#include <dt-bindings/media/video-interface-devices.h>
+
#include "tegra30-lg-x3.dtsi"
/ {
@@ -132,7 +134,7 @@ front-camera@48 {
vdd-supply = <&vt_1v8_front>;
vaa-supply = <&vt_2v8_front>;
- orientation = <0>; /* Front camera */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
<&tegra_car TEGRA30_CLK_CSUS>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
index 60e8a19aa70e..c58e3026a115 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/mfd/max77620.h>
#include <dt-bindings/thermal/thermal.h>
@@ -1216,7 +1217,7 @@ rear-camera@10 {
dvdd-supply = <&vdd_1v2_rear>;
avdd-supply = <&vdd_2v7_rear>;
- orientation = <1>; /* Rear camera */
+ orientation = <MEDIA_ORIENTATION_REAR>;
rotation = <90>;
nvmem = <&m24c08>;
--
2.52.0
^ permalink raw reply related
* [PATCH v2 3/8] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the existing examples throughout the bindings documentation for
camera sensors.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
12 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
index 1a57f2aa1982..b7bc6ba26e6e 100644
--- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
@@ -86,6 +86,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -102,7 +103,7 @@ examples:
vddio-supply = <®_camera_vddio>;
reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
index 6f2017c75125..b9c61395b24f 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
@@ -69,6 +69,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -84,7 +85,7 @@ examples:
avdd-supply = <&ov08d10_vdda_2v8>;
dvdd-supply = <&ov08d10_vddd_1v2>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
index d96199031b66..fcd617848ce3 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
@@ -96,6 +96,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -114,7 +115,7 @@ examples:
powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
index ad07204057f9..6df62fd0c0c0 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
@@ -85,6 +85,7 @@ examples:
- |
#include <dt-bindings/clock/px30-cru.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
i2c {
@@ -108,7 +109,7 @@ examples:
dovdd-supply = <&vcc_2v8>;
rotation = <90>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
ucam_out: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
index 3368b3bd8ef2..5732657e1484 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
@@ -103,6 +103,7 @@ examples:
- |
#include <dt-bindings/clock/px30-cru.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
i2c {
@@ -126,7 +127,7 @@ examples:
dovdd-supply = <&vcc_2v8>;
rotation = <90>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
ucam_out: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
index 2b6143aff391..24787c9aa155 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
@@ -72,6 +72,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -87,7 +88,7 @@ examples:
powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
rotation = <180>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
port {
endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
index 20f48d5e9b2d..56fb5f18f07b 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
@@ -69,6 +69,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -84,7 +85,7 @@ examples:
dvdd-supply = <&camera_vddd_1v2>;
avdd-supply = <&camera_vdda_2v7>;
- orientation = <1>;
+ orientation = <MEDIA_ORIENTATION_BACK>;
rotation = <90>;
nvmem = <&eeprom>;
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
index 6050d7e7dcfe..b4a88eaa7ef2 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
@@ -74,6 +74,7 @@ examples:
- |
#include <dt-bindings/clock/qcom,camcc-sdm845.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -98,7 +99,7 @@ examples:
pinctrl-0 = <&cam_front_default>;
rotation = <270>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
cam_front_endpoint: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
index 7c11e871dca6..69a37ff68db3 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
@@ -86,6 +86,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -98,7 +99,7 @@ examples:
clocks = <&clock_cam>;
dvdd-supply = <&vcc1v1_cam>;
lens-focus = <&vcm>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
ovdd-supply = <&vcc1v8_cam>;
reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
rotation = <180>;
diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
index 060ac6829b66..db9f0c15576c 100644
--- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
@@ -105,6 +105,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -123,7 +124,7 @@ examples:
reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
st,leds = <2>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
index c6673b8539db..48db22ca4a7e 100644
--- a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
@@ -107,6 +107,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -125,7 +126,7 @@ examples:
reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
st,leds = <6>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
index bc339a7374b2..4a66cb711372 100644
--- a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
@@ -173,6 +173,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -196,7 +197,7 @@ examples:
vddgpio-0-supply = <&vsys_v4p2>;
vddgpio-1-supply = <&vsys_v4p2>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
rotation = <0>;
sensors {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
Expand the documentation of the video-interface-devices orientation to
reference the include/dt-bindings/media/video-interface-devices.h header
which provides human readable defines for the orientation enum, to help
avoid hardcoding values in dts.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
.../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
index a81d2a155fe6..c9c3f4f16719 100644
--- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -392,17 +392,22 @@ properties:
The orientation of a device (typically an image sensor or a flash LED)
describing its mounting position relative to the usage orientation of the
system where the device is installed on.
+ See include/dt-bindings/media/video-interface-devices.h.
+
$ref: /schemas/types.yaml#/definitions/uint32
enum:
- # Front. The device is mounted on the front facing side of the system. For
- # mobile devices such as smartphones, tablets and laptops the front side
- # is the user facing side.
+ # MEDIA_ORIENTATION_FRONT
+ # The device is mounted on the front facing side of the system. For
+ # mobile devices such as smartphones, tablets and laptops the front
+ # side is the user facing side.
- 0
- # Back. The device is mounted on the back side of the system, which is
+ # MEDIA_ORIENTATION_BACK
+ # The device is mounted on the back side of the system, which is
# defined as the opposite side of the front facing one.
- 1
- # External. The device is not attached directly to the system but is
- # attached in a way that allows it to move freely.
+ # MEDIA_ORIENTATION_EXTERNAL
+ # The device is not attached directly to the system but is attached in
+ # a way that allows it to move freely.
- 2
additionalProperties: true
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Conor Dooley, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
Add a new dt-bindings/media/video-interface-devices.h header that
defines macros corresponding to the orientation enumeration types from
media/video-interface-devices.yaml.
This allows avoiding hardcoded constants in device tree sources.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/dt-bindings/media/video-interface-devices.h b/include/dt-bindings/media/video-interface-devices.h
new file mode 100644
index 000000000000..d2340b457292
--- /dev/null
+++ b/include/dt-bindings/media/video-interface-devices.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
+/*
+ * Copyright (C) 2026 Kieran Bingham <kieran.bingham@ideasonboard.com>
+ */
+
+#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
+#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
+
+#define MEDIA_ORIENTATION_FRONT 0
+#define MEDIA_ORIENTATION_BACK 1
+#define MEDIA_ORIENTATION_EXTERNAL 2
+
+#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__ */
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/8] dt-bindings: Orientation defines
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Conor Dooley, Kieran Bingham, Kieran Bingham
Add a new dt-bindings/media/video-interface-devices.h header that
initially supports the Orientation types and convert existing users
throughout the code base.
v2:
- Now expands from the original v1 "dt-bindings: media: Add macros for
video interface devices" to update
Documentation/devicetree/bindings/media/video-interface-devices.yaml
and extend to actually change all users to the new types.
---
Kieran Bingham (8):
dt-bindings: media: Add macros for video interface devices
media: dt-bindings: video-interface-devices: add video-interface-devices.h references
dt-bindings: media: i2c: Utilise video-interface-devices enums
ARM: tegra: Convert to new media orientation definitions
arm64: dts: freescale: Convert to new media orientation definitions
arm64: dts: qcom: Convert to new media orientation definitions
arm64: dts: renesas: Convert to new media orientation definitions
arm64: dts: rockchip: Convert to new media orientation definitions
.../devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
.../devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
.../devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
.../devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
.../devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
.../devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
.../devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
.../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
.../dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
.../dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
.../imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso | 3 ++-
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 3 ++-
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 3 ++-
.../boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 ++-
arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso | 3 ++-
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi | 3 ++-
.../dts/rockchip/px30-ringneck-haikou-video-demo.dtso | 3 ++-
arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++--
.../rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 3 ++-
.../rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 3 ++-
include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
32 files changed, 86 insertions(+), 37 deletions(-)
---
base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
change-id: 20260608-kbingham-orientation-20afc0fb6957
Best regards,
--
--
Kieran
^ permalink raw reply
* [PATCH] fix: clk/samsung: exynos_clkout_probe: success path leaks parent clock references from of_clk_get_by_name
From: WenTao Liang @ 2026-06-26 12:01 UTC (permalink / raw)
To: krzk, s.nawrocki, cw00.choi, mturquette, sboyd
Cc: alim.akhtar, bmasney, linux-samsung-soc, linux-clk,
linux-arm-kernel, linux-kernel, WenTao Liang, stable
of_clk_get_by_name() acquires clock references stored in the local
parents[] array. All error paths correctly release these via the clks_put
label, but the success path returns 0 without releasing the parent
references. The references were only needed to obtain clock names for
registration and are permanently leaked after probe completes.
Cc: stable@vger.kernel.org
Fixes: 9484f2cb8332 ("clk: samsung: exynos-clkout: convert to module driver")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
---
drivers/clk/samsung/clk-exynos-clkout.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos-clkout.c b/drivers/clk/samsung/clk-exynos-clkout.c
index 5b21025338bd..ee3048d36040 100644
--- a/drivers/clk/samsung/clk-exynos-clkout.c
+++ b/drivers/clk/samsung/clk-exynos-clkout.c
@@ -190,6 +190,10 @@ static int exynos_clkout_probe(struct platform_device *pdev)
if (ret)
goto err_clk_unreg;
+ for (i = 0; i < EXYNOS_CLKOUT_PARENTS; ++i)
+ if (!IS_ERR(parents[i]))
+ clk_put(parents[i]);
+
return 0;
err_clk_unreg:
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Re: [PATCH 15/37] drm/display: bridge-connector: allocate the connector dynamically
From: Maxime Ripard @ 2026-06-26 11:44 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJI0YM93PKAM.TMLLL1394R5D@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 3157 bytes --]
On Thu, Jun 25, 2026 at 11:32:32AM +0200, Luca Ceresoli wrote:
> On Wed Jun 24, 2026 at 5:34 PM CEST, Luca Ceresoli wrote:
> > Hi Maxime,
> >
> > thanks for the feedback.
> >
> > On Wed Jun 24, 2026 at 1:48 PM CEST, Maxime Ripard wrote:
> >> On Fri, Jun 12, 2026 at 02:44:43PM +0200, Luca Ceresoli wrote:
> >>> On Mon Jun 8, 2026 at 1:46 PM CEST, Maxime Ripard wrote:
> >>> > On Tue, May 19, 2026 at 12:37:32PM +0200, Luca Ceresoli wrote:
> >>> >> Currently the drm_bridge_connector has an embedded drm_connector, so their
> >>> >> allocation lifetimes are tied to each other. This is insufficient to
> >>> >> support DRM bridge hotplugging, which requires the connector to be added
> >>> >> and removed dynamically at runtime multiple times based on hotplug/unplug
> >>> >> events while the drm_bridge_connector is persistent.
> >>> >>
> >>> >> Moreover the drm_connector is exposed to user space and thus an ongoing
> >>> >> operation (e.g. an ioctl) might last for an arbitrarily long time even
> >>> >> after the hardware gets removed. This means a new connector might have to
> >>> >> be added when the previous one is still referenced by user space.
> >>> >>
> >>> >> In preparation to handle hotplug, allocate the drm-connector dynamically,
> >>> >> to allow:
> >>> >>
> >>> >> * creating and destroying a connector multiple times during a single
> >>> >> drm_bridge_connector lifetime
> >>> >> * creating a new connector even though the previous one is still in use
> >>> >> and thus still refcounted and not yet freed
> >>> >>
> >>> >> This commit does not introduce the actions in the two bullets (it will
> >>> >> happen in a later commit), it only moves to dynamic APIs for connector
> >>> >> allocation and init.
> >>> >>
> >>> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >>> >
> >>> > I think this patch should be split in half, with the switch to using
> >>> > destroy first, and then the actual move to the dynamically allocated
> >>> > connector API.
> >>>
> >>> Is it doable? drm_connector_dynamic_init() mandates a .destroy callback,
> >>> drm_connector_init() forbids it.
> >>
> >> drmm_connector_init forbids it. drm_connector_init mandates it.
> >
> > Something bogus in my reply, sorry. :)
> >
> > So you mean splitting in:
> >
> > * first patch: move from drmm_connector[_hdmi]_init() to
> > drm_connector[_hdmi]_init() and add a .destroy
> > * second patch: move from drm_connector[_hdmi]_init() to
> > drm_connector[_hdmi]_dynamic_init() +
> > drm_connector_dynamic_register/unregister()
>
> Ah, no, there's an annoyance here. drm_connector_hdmi_init() does not
> exist, so it'd have to be created just for the sake of splitting this
> patch, sitting unused after the second patch.
>
> I don't think it's worth implementing (and maybe deleting) it just for
> that, so I'm leaving this patch as is unless you have counteraguments.
If it's just to ease the transition, you can have two different set of
drm_connector_funcs for HDMI vs !HDMI, one with destroy and the other
using drmm while you rework the init function
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Gavin Shan @ 2026-06-26 11:43 UTC (permalink / raw)
To: Suzuki K Poulose, Lorenzo Pieralisi
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Marc Zyngier,
Will Deacon, James Morse, Oliver Upton, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <9482dfbc-4d96-47ba-a615-f4ba0bda833f@arm.com>
On 6/26/26 6:47 PM, Suzuki K Poulose wrote:
> On 26/06/2026 08:43, Gavin Shan wrote:
>> On 6/26/26 1:58 AM, Suzuki K Poulose wrote:
>>> On 25/06/2026 14:53, Gavin Shan wrote:
>>>> On 6/6/26 12:35 AM, Lorenzo Pieralisi wrote:
>>>>> On Fri, Jun 05, 2026 at 06:11:11PM +1000, Gavin Shan wrote:
>>>>>> On 6/5/26 5:28 PM, Lorenzo Pieralisi wrote:
>>>>>>> On Fri, Jun 05, 2026 at 04:23:15PM +1000, Gavin Shan wrote:
>>
>> [...]
>>
>>>>>>
>>>>>> I tried to rebase Jean's latest QEMU series [1] to upstream QEMU, and found
>>>>>> that memory slots backed by THP are broken. With THP disabled on the host and
>>>>>> other fixes (mentioned in my prevous replies) applied on the top of this (v14)
>>>>>> series, I'm able to boot a realm guest with rebased QEMU series [2], plus more
>>>>>> fxies on the top.
>>>>>>
>>>>>> [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/ latest)
>>>>>> [2] https://git.qemu.org/git/qemu.git (branch: cca/ gavin)
>>>>>>
>>>>>> Lorenzo, You may be saying there is someone making QEMU to support ARM/CCA?
>>>>>
>>>>> Mathieu and I are working on that yes and with Steven/Suzuki to fix the THP
>>>>> issues you pointed out above.
>>>>>
>>>>>> If so, I'm not sure if there is a QEMU repository for me to try?
>>>>>
>>>>> We should be able to submit patches by end of June - we shall let you know
>>>>> whether we can make something available earlier.
>>>>>
>>>>
>>>> Not sure if there are other known issues in this series. It seems the stage2
>>>> page fault handling on the shared space isn't working well. In my test, the
>>>> vring (struct vring_desc) of virtio-net-pci is updated by the guest, and the
>>>> data isn't seen by QEMU, I'm suspecting if the host-page-frame-number is properly
>>>> resolved in the s2 page fault handler for shared (unprotected) space.
>>>>
>>>> - I rebased Jean's latest qemu branch to the upstream qemu;
>>>>
>>>> - On the host, which is emulated by qemu/tcg, the THP (transparent huge page) is
>>>> disabled.
>>>>
>>>> - On the guest, I can see the virtio vring (struct vring_desc) is updated. The
>>>> S1 page-table entry looks correct because the corresponding physical address
>>>> 0x10046880000 is a sane shared (unprotected) space address.
>>>>
>>>> [ 52.094143] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
>>>> [ 52.289746] virtqueue_add_desc_split: desc[0]@0xffff000006880000, [00000100b983f000 00000640 0002 0001]
>>>> [ 52.432150] PTE 0x00e8010046880707 at address 0xffff000006880000
>>>>
>>>> - On the host, the s2 page-table-entry is unmapped due to attribute transition (private -> shared).
>>>> A subsequent S2 page fault is raised against the adress and the s2 page-table-entry is built.
>>>>
>>>> [ 109.259077] ====> realm_unmap_shared_range: tracked_unprot_addr=0x10046880000
>>>> [ 109.260249] realm_unmap_shared_range: unmapped shared range at 0x10046880000
>>>> [ 109.317786] realm_unmap_shared_range: unmapped shared range at 0x10046880000
>>>> [ 109.629939] ====> kvm_handle_guest_abort: fault_ipa=0x10046880000, esr=0x92000007
>>>> [ 109.630245] realm_map_non_secure: ipa=0x10046880000, pfn=0xb8b59, size=0x1000, prot=0xf
>>>> [ 109.630331] realm_map_non_secure: ipa=0x10046880000, ipa_top=0x10046881000, flags=0x1e0001, range_desc=0xb8b59004
>>>
>>> Are you able to correlate the order of the transitions and the Guest
>>> access with RMM log ? We haven't seen this from our end. We are aware
>>> of permission fault issues with Unprotected IPA when backing the memslot
>>> with MAP_PRIVATE areas. But this looks different.
>>>
>>> Lorenzo, have you run into this ?
>>>
>>
>> It's hard to correlate the order since the logs are collected from two separate
>> consoles. For the write permission, I add code to the host where the permission
>> is always added for all s2 page faults in the shared space. Otherwise, qemu can
>> be killed by -EFAULT or similar error.
>
> This is the problem. We can't add WRITE permission by default. I believe
> you may have MAP_PRIVATE mapping and it has to be mapped as READ only
> and on a permission fault, we replace it with a writable page. By
> overriding the WRITE permission, you let the guest write to a page
> that may not be seen by the VMM.
>
> We identified this as a bug in the KVM driver in this series (reported
> by Lorenzo) and there is a corresponding tf-RMM change that is required
> to get this working. So, please could you wait until the next series
> when this will be addressed ? Or you could switch to using MAP_SHARED
> for the "shared" memory in the memslot.
>
Exactly. the syntax for MAP_PRIVATE is broken if the write permission is
enforced for a read fault in the shared space. In my case, the host page can
be the zero page and eventually multiple s2 page-table entries (for multiple
unprotected or shared pages) point to the zero page. It's why clearing the
3rd queue (Ctrl queue) also clears the first queue (Rx queue) in my case.
Yes, this issue can be avoid by using a shared memory backend in qemu, something
like below. With this, I'm able to see virtio-net-pci starts to work...
-object memory-backend-ram,id=mem0,size=2G,share=yes
Thanks,
Gavin
>
> Suzuki
>
>
>>
>> There are more findings after more experiments: this virtio-net-pci device has 3
>> queues or vrings (Rx/Tx/Ctrl). The Rx/Tx/Ctrl queue are populated in order one after
>> one. In the guest kernel, I intentionally write fixed data (0x0123456789abcdef) to
>> the first 8 bytes of the queue when it gets populated, and stop the guest at random
>> points to see if the data is gone. I found that the data written to Rx/ Tx queue are
>> lost after Ctrl queue is allocated.
>>
>> The data written to Rx/Tx queue is lost if the guest stops (B). The data written to
>> Rx/Tx queue isn't lost if the guest stops at (A). I can see the pattern (0x0123...cdef)
>> by dumping the physcial memory through 'pmemsave' command in qemu.
>>
>> DMA allocation
>> ==============
>> dma_alloc_coherent
>> dma_alloc_attrs
>> dma_direct_alloc
>> __dma_direct_alloc_pages
>> dma_set_decrypted // (A) No data lost if being stopped here for the Ctrl queue
>> memset(ret, 0, size) // (B) Data lost after being stopped after memset() for the Ctrl queue
>>
>> The memset() on the Ctrl queue should trigger a stage2 page fault. It seems the page
>> fault enforces the shared pages for Rx/Tx queue to be dropped? I need to add more
>> debugging code and track it down.
>>
>>> Suzuki
>>>
>>>
>>>>
>>>> - On QEMU, the updated vring (struct vring_desc) at GPA 0x46880000 isn't seen. All the
>>>> data in that adress are zeros.
>>>>
>>>> ====> virtqueue_split_pop: vdev=<virtio-net>, sz=0x38, queue_index=0x0, vq->vring.num=0x100
>>>> virtqueue_split_pop: last_avail_idx=0x0, head=0x0
>>>> address_space_read_cached_slow: cache@0xffff1c036440, addr=0x0, buf=0xffffeee34880, len=0x10
>>>> address_space_read_cached_slow: cache: ptr=0x0, xlat=0x10046880000, len=0x1000, mrs=<realm-dma-region>, is_write=no
>>>> address_space_read_cached_slow: translated to mr=<mach-virt.ram>, mr_addr=0x6880000, l=0x10
>>>> flatview_read_continue_step: mr=<mach-virt.ram>, host=0xffff23e00000, mr_addr=0x6880000, ram_ptr=0xffff2a680000
>>>> virtqueue_split_pop: desc: 0000000000000000 - 00000000 - 00000000 - 00000000
>>>> qemu-system-aarch64: virtio: zero sized buffers are not allowed
>>>>
>>>>
>> Thanks,
>> Gavin
>>
>
^ permalink raw reply
* Re: [PATCH 0/6] arm64: ti: Use syscon for the Control Module
From: Tomi Valkeinen @ 2026-06-26 11:42 UTC (permalink / raw)
To: Andrew Davis, Krzysztof Kozlowski
Cc: linux-arm-kernel, devicetree, linux-kernel, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring, Conor Dooley,
Abraham I, Roger Quadros, Devarsh Thakkar, Swamil Jain
In-Reply-To: <29c9bd27-df32-4c56-8df2-987722d02b9a@ti.com>
Hi Andrew, Krzysztof,
On 29/05/2026 01:59, Andrew Davis wrote:
> On 5/28/26 7:53 AM, Tomi Valkeinen wrote:
>> I have been trying to get BeagleY-AI display support to upstream:
>>
>> 20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com
>>
>> One difficulty has been the handling of the Control Module region, as
>> we need access to a single in that region, surrounded by registers for
>> other subsystems. In my series I made the related node a syscon, thus
>> allowing versatile access to the registers:
>>
>> https://lore.kernel.org/all/20260513-beagley-ai-display-
>> v2-14-9e9bcefde6bc@ideasonboard.com/
>>
>> However, that's not a correct way to handle it. I realized we already
>> have ti,j721e-system-controller.yaml binding for older SoCs, which has
>> syscon but it's not used for the newer TI SoCs. This series takes the
>> same binding into use for the newer SoCs.
>>
>
> We moved away from this system-controller thing because it was always
> a hack to allow us to poke into random control registers from nodes
> throughout the DT. This was a mess and also caused issues with multiple
> mappings to the same registers (some sub nodes inside the control space
> also make their own mappings). If you need access to registers then make
> a node with those registers in the `reg` property.
>
> The only reason we didn't get rid of `ti,j721e-system-controller.yaml`
> completely from the older SoCs was we were told it would be an ABI
> break to correct those DT files. Let's not spread that problem to
> new SoCs.
I'm still stuck on this issue.
So, to summarize, we have the big control module memory region from
which various drivers need "random" registers. In my particular case,
the display subsystem (DSS) driver needs to access a single register
from the control module, but as the control module contains a lot of
registers, there are other similar cases too (I've seen at least one
other series, trying to add access to control module registers).
Taking AM62 SoC as an example, we have this in upstream:
https://github.com/torvalds/linux/blob/4edcdefd4083ae04b1a5656f4be6cd83ae919ef4/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#L44
"main_conf" (simple-bus) node representing the control module, and nodes
under that representing either small things like clocks or, in
dss_oldi_io_ctrl case, a syscon.
I'm aware of three options on how to handle this.
1) Adding small syscon nodes under the main_conf, similar to the
existing dss_oldi_io_ctrl.
I did this in the earlier series:
https://lore.kernel.org/all/20260420-beagley-ai-display-v1-3-f628543dfd14%40ideasonboard.com/
2) Making the whole control module a syscon, as I do in this series.
3) Adding the required registers as a new 'reg' block under the dss' DT
node.
Both 1) and 2) have been nacked or at least very strongly questioned. 3)
doesn't feel right, the register is not a register for the IP but an
external SoC integration register.
Is there an option 4)? In your opinion, is one of the above the one
clear choice?
Tomi
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-26 11:25 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <4f0878a0-2ab1-490d-b251-c6d68c4ee241@oss.qualcomm.com>
On 6/25/2026 2:17 PM, Konrad Dybcio wrote:
> On 6/19/26 12:54 PM, Bibek Kumar Patro wrote:
>>
>>
>> On 6/18/2026 2:58 PM, Konrad Dybcio wrote:
>>> On 6/17/26 4:26 PM, Bibek Kumar Patro wrote:
>>>>
>>>>
>>>> On 6/16/2026 5:51 AM, Dmitry Baryshkov wrote:
>>>>> On Mon, Jun 15, 2026 at 06:36:51PM +0530, Bibek Kumar Patro wrote:
>>>>>>
>>>>>>
>>>>>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>>>>>> On some SoCs the SMMU registers require an active interconnect
>>>>>>>> bandwidth vote to be accessible. While other clients typically
>>>>>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>>>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>>>>>> vote, causing intermittent register access failures.
>>>>>>>>
>>>>>>>> Add support for an optional interconnect path to the arm-smmu
>>>>>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>>>>>> is acquired from DT if present and ignored otherwise.
>>>>>>>>
>>>>>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>>>>>> during probe and runtime resume, and released during runtime
>>>>>>>> suspend and on error paths.
>>>>>>>>
>>>>>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>>>>>> expected to have an active vote whenever the adreno_smmu block is
>>>>>>>> powered on. In most common use cases, this requirement is implicitly
>>>>>>>> satisfied because other GPU-related clients (for example, the GMU
>>>>>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>>>>>
>>>>>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>>>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>>>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>>>>>> vote is missing, it can lead to the observed failures. Because of the
>>>>>>>> precise ordering involved, this scenario is difficult to reproduce
>>>>>>>> consistently.
>>>>>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>>>>>
>>>>>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>>>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>>> @@ -53,6 +53,11 @@
>>>>>>>> #define MSI_IOVA_BASE 0x8000000
>>>>>>>> #define MSI_IOVA_LENGTH 0x100000
>>>>>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>>>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>>>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>>>>>
>>>>>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>>>>>
>>>>>>
>>>>>> Ideally, any non-zero value would be enough to keep the path active.
>>>>>
>>>>> This is true for Qualcomm devices. However, you are adding this to a
>>>>> generic code.
>>>>>
>>>>>> Here 1 Would be enough to keep the path active, but might be too small to
>>>>>> reliably keep the bus active.
>>>>>> Other is UINT_MAX, which will reliably keep the bus active but might cause a
>>>>>> power penalty.
>>>>>>
>>>>>> #define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
>>>>>>
>>>>>> seems to be suitable here to reliably keep the bus active by BCM
>>>>>> for both Qualcomm and non-Qualcomm platforms (with some power penalty).
>>>>>>
>>>>>> LMK, if you feel otherwise.
>>>>>
>>>>> Shift it to the qcom instance or provide platform-specific values? (My
>>>>> preference would be towards the first solution).
>>>>>
>>>>
>>>>
>>>> To support platform-specific values, we may need to introduce a LUT-based approach in the driver. (Bandwidth voting values cannot be placed in device-tree property IIRC ?)
>>>>
>>>> Currently, all Qualcomm platforms use 0x1000 for SMMU ICC voting. I
>>>
>>> (you used decimal 1000)
>>>
>>
>> It's my bad, i meant 1000 only
>> (I'll check on the icc_bw calculation to get clarity on the values)
>>
>>>> can evaluate if this could be moved to a Qualcomm-specific
>>>> implementation.
>>>
>>> Add a vendor hook to arm_smmu_runtime_suspend/resume and handle it within
>>> the QC driver
>>>
>>
>> Just curious, wouldn't this apply for all the arm-smmu users in addition to Qualcomm devices as i mentioned here [1].
>> Vendor hook would make it Qualcomm specific.
>
> You're proposing to use a Qualcomm-specific bandwidth value so that
> fits
>
Got it, It seems valid. Will be sharing the new implementation post
testing in next revision.
Thanks & regards,
Bibek
> Konrad
>
>>
>> [1]: https://lore.kernel.org/all/984ff9c7-3eef-463c-a330-bf7acd063667@oss.qualcomm.com/
>>
>> Thanks & regards,
>> Bibek
>>
>>> Konrad
>>
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Rong Zhang @ 2026-06-26 11:19 UTC (permalink / raw)
To: Chris Lu (陸稚泓),
patchwork-bot+bluetooth@kernel.org, luiz.dentz@gmail.com
Cc: marcel@holtmann.org, AngeloGioacchino Del Regno,
SS Wu (巫憲欣), linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <3f9c376a5dbfc9d737e2a7f83c5db8e591fb8793.camel@mediatek.com>
Hi Chris,
于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com> 写道：
>Hi Luiz,
>
>Could we revert this change?
Please don't. The fundamental goal of the patch is to make MT7922/MT7925 *usable* on affected platforms.
Moreover, almost all recent AMD platforms ship with MT7922/MT7925, reverting this patch affects quite a lot of users. Almost every AMD platform I've met suffers from the issue, and there are plenty of bug reports.
Intel platforms never ship with MTK WLAN NICs, so I can't tell if the issue is reproducible on them.
>
>Sorry, MediaTek wasn't aware someone submitted this change and it had
>already been merged.
>
>MTK believes this issue is strongly related to the platform's USB hub
>behavior,
Still, I believe that there are some interoperability issues in MT7922/MT7925's hardware or firmware, as reinitializing the XHCI root hub (by logically removing it from the PCI bus and probing it again) doesn't make it recover at all.
> The product lines MTK directly support haven't reported such
>issue.
...or did you mean none of the existing AMD platforms are supported by MTK?
>
>Disable wake capability would severely impact wake on Bluetooth on
>MTK's official product lines.
Could you kindly explain "MTK's official product lines"?
> Furthermore, this patch looks like a
>workaround. There should be a better way to handle this issue. We hope
>this change can be reverted.
The issue is severe on affected platforms by making the Bluetooth interface completely gone. IMHO, we must figure out the "better way" before reverting it, or else it's more like burying your head into sand by shouting "works fine on our platforms" (TM).
That being said, I think we can narrow the range of the quirk down to AMD platforms only. Does it make sense to you? If so, I will submit a patch for this.
Thanks,
Rong
>
>
>On Wed, 2026-06-03 at 17:50 +0000, patchwork-bot+bluetooth@kernel.org
>wrote:
>> Hello:
>>
>> This patch was applied to bluetooth/bluetooth-next.git (master)
>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>>
>> On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
>> > These NICs are often reported to lose their Bluetooth interfaces,
>> > i.e,
>> > their USB interfaces suddenly become completely unresponsive,
>> > causing
>> > the USB core to reset them, only to find that they are no longer
>> > accessible. A power cycle is required to make the Bluetooth
>> > interfaces
>> > recover.
>> >
>> > After some investigations, I found that their USB autosuspend
>> > remote
>> > wakeup capabilities are so broken that they are precisely the
>> > culprit
>> > behind the issue:
>> >
>> > [...]
>>
>> Here is the summary with links:
>> - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
>> https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789
>>
>> You are awesome, thank you!
>
>
>Best Regards,
>Chris Lu
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: mm: protect show_pte() in do_DataAbort() fallback path
From: Xie Yuanbin @ 2026-06-26 10:16 UTC (permalink / raw)
To: xiqi2, linux
Cc: akpm, linux-arm-kernel, linux-kernel, sunnanyong, xieyuanbin1
In-Reply-To: <20260626073048.3595106-3-xiqi2@huawei.com>
On Fri, 26 Jun 2026 15:30:48 +0800, Qi Xi wrote:
> @@ -638,7 +638,10 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
> pr_alert("8<--- cut here ---\n");
> pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n",
> inf->name, fsr, addr);
> - show_pte(KERN_ALERT, current->mm, addr);
> + if (mmap_read_trylock(current->mm)) {
> + show_pte(KERN_ALERT, current->mm, addr);
> + mmap_read_unlock(current->mm);
> + }
For kernel faults, `current->mm` maybe NULL, and
`mmap_read_trylock(current->mm)` may cause a panic.
Also, interrupts may be disabled here.
I suggest that waiting for this patch to be merged first:
https://lore.kernel.org/20260625122612.43501-1-xieyuanbin1@huawei.com
which make sure that interrupts are enabled here.
Then, something like:
```c
if (user_mode(regs))
mmap_read_lock(current->mm);
show_pte(KERN_ALERT, current->mm, addr);
if (user_mode(regs))
mmap_read_unlock(current->mm);
```
^ permalink raw reply
* [PATCH] ARM: dts: ti: Fix typos in comments
From: Vidhu Sarwal @ 2026-06-26 11:17 UTC (permalink / raw)
To: Bartosz Golaszewski, Tony Lindgren, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-omap,
linux-arm-kernel, devicetree, linux-kernel, skhan, Vidhu Sarwal
Fix comment typos found with codespell across DaVinci and OMAP
board files:
limitaion -> limitation
swithes -> switches
converstion -> conversion
differnet -> different
Signed-off-by: Vidhu Sarwal <vidhu.linux@gmail.com>
---
arch/arm/boot/dts/ti/davinci/da850-lcdk.dts | 2 +-
arch/arm/boot/dts/ti/omap/am3517-evm.dts | 2 +-
arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts | 2 +-
arch/arm/boot/dts/ti/omap/omap4-panda-es.dts | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts b/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts
index 8390d71b000a..e70edd5274fe 100644
--- a/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts
+++ b/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts
@@ -366,7 +366,7 @@ nand@2000000,0 {
* to NAND block 1 (NAND block 0 is not used by default)".
* The same doc mentions that for ROM "Silicon Revision 2.1",
* "Updated NAND boot mode to offer boot from block 0 or block 1".
- * However the limitaion is left here by default for compatibility
+ * However the limitation is left here by default for compatibility
* with older silicon and because it needs new boot pin settings
* not possible in stock LCDK.
*/
diff --git a/arch/arm/boot/dts/ti/omap/am3517-evm.dts b/arch/arm/boot/dts/ti/omap/am3517-evm.dts
index 40f15da81043..a4357fa9f006 100644
--- a/arch/arm/boot/dts/ti/omap/am3517-evm.dts
+++ b/arch/arm/boot/dts/ti/omap/am3517-evm.dts
@@ -213,7 +213,7 @@ &i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins>;
clock-frequency = <400000>;
- /* User DIP swithes [1:8] / User LEDS [1:2] */
+ /* User DIP switches [1:8] / User LEDS [1:2] */
tca6416: gpio@21 {
compatible = "ti,tca6416";
reg = <0x21>;
diff --git a/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts b/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts
index 43cf4ade950b..76bfb364777e 100644
--- a/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts
+++ b/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts
@@ -420,7 +420,7 @@ stmpe811@41 {
st,mod-12b = <1>; /* 12-bit ADC */
st,ref-sel = <0>; /* internal ADC reference */
st,adc-freq = <1>; /* 3.25 MHz ADC clock speed */
- st,sample-time = <4>; /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>; /* ADC conversion time: 80 clocks */
stmpe_adc {
compatible = "st,stmpe-adc";
diff --git a/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts b/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts
index a933fe560834..70c609811d11 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts
@@ -12,7 +12,7 @@ / {
compatible = "ti,omap4-panda-es", "ti,omap4-panda", "ti,omap4460", "ti,omap4430", "ti,omap4";
};
-/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
+/* Audio routing is different between PandaBoard4430 and PandaBoardES */
&sound {
ti,model = "PandaBoardES";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Xu Yang @ 2026-06-26 11:15 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang,
Andy Yan, Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-2-kernel@airkyi.com>
On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> The HPD function of Type-C DP is implemented through
> drm_connector_oob_hotplug_event(). For embedded DP, it is required
> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>
> To describe the relationship between the DP controller and the Type-C
> port device, we usually using drm_bridge to build a bridge chain.
>
> Now several USB-C controller drivers have already implemented the DP
> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
> HPD bridge on USB-C connector port device.
>
> But this requires the USB-C controller driver to manually register the
> HPD bridge. If the driver does not implement this feature, the bridge
> will not be create.
>
> So this patch implements a generic DP HPD bridge based on
> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
> Type-C port device containing the DP svid is registered, it will
> create an HPD bridge for it without the need for the USB-C controller
> driver to implement it.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
>
> (no changes since v14)
>
> Changes in v13:
> - Only register drm dp hpd bridge for typec port altmode device.
>
> (no changes since v12)
>
> Changes in v11:
> - Switch to using typec bus notifiers.
>
> (no changes since v10)
>
> Changes in v9:
> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
> - Add more commit comment about problem background.
>
> Changes in v8:
> - Merge generic DP HPD bridge into one module.
> ---
>
> drivers/gpu/drm/bridge/Kconfig | 10 ++++
> drivers/gpu/drm/bridge/Makefile | 1 +
> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
> 3 files changed, 60 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index a250afd8d662..559487aa09a9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
> Simple bridge that terminates the bridge chain and provides HPD
> support.
>
> +if DRM_AUX_HPD_BRIDGE
> +config DRM_AUX_HPD_TYPEC_BRIDGE
> + tristate
> + depends on TYPEC || !TYPEC
> + default TYPEC
> + help
> + Simple bridge that terminates the bridge chain and provides HPD
> + support. It build bridge on each USB-C connector device node.
> +endif
> +
Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
manually.
$ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Barry Song @ 2026-06-26 11:09 UTC (permalink / raw)
To: Dev Jain
Cc: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, urezki, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang,
Ard Biesheuvel
In-Reply-To: <a6e410bd-7413-45f0-9033-a60cd5386512@arm.com>
On Thu, Jun 25, 2026 at 2:37 PM Dev Jain <dev.jain@arm.com> wrote:
>
>
>
> On 18/06/26 2:17 pm, Wen Jiang wrote:
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous. Two techniques are used:
> >
> > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> > segments
> > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> > layers
> >
> > Besides accelerating the mapping path, this also enables large
> > mappings (PMD and cont-PTE) for vmap, which are currently not
> > supported.
> >
> > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > CONT-PTE regions instead of just one.
> >
> > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> >
> > Patch 4 extends the page table walk path to support page shifts other
> > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > to vmap_pages_range_noflush_walk().
> >
> > Patches 5-6 add huge vmap support for contiguous pages, including
> > support for non-compound pages with pfn alignment verification.
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> > VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
> >
> > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
> >
>
> I am still a little nervous about doing vmap-huge by default.
>
> We can play set_memory_* games on a vmap huge mapping partially, thus
> forcing a pgtable split, and not all arches can handle a kernel pgtable
> split.
>
> For arm64, we can handle that with BBML2_NOABORT, but interestingly, in
> change_memory_common, arch/arm64/mm/pageattr.c:
>
> area = find_vm_area((void *)addr);
> if (!area ||
> ((unsigned long)kasan_reset_tag((void *)end) >
> (unsigned long)kasan_reset_tag(area->addr) + area->size) ||
> ((area->flags & (VM_ALLOC | VM_ALLOW_HUGE_VMAP)) != VM_ALLOC))
> return -EINVAL;
>
> Even before my change fcf8dda8cc48, we were bailing out on
>
> !(area->flags & VM_ALLOC))
>
> So on arm64 we haven't been supporting set_memory_* for vmap memory at all, because
> it has VM_MAP set and not VM_ALLOC. Although we have a contradictory comment above
> this code so not sure if this was intentional:
>
> "Let's restrict ourselves to mappings created by vmalloc (or vmap)."
>
>
> So either there is no user in the kernel doing vmap + set_memory_* (looks like it
> by doing an LLM scan), or it is not fatal for set_memory_* to fail.
Hi Dev,
The primary purpose of vmap() is to provide the CPU with a
virtual mapping to access memory used by device drivers,
followed by the appropriate cache synchronization with the
device when necessary.
Given that, I think it's technically quite questionable to use
set_memory_xxx() to change the page table attributes of a vmap
area, especially for only part of an existing vmap mapping.
>
> But even if no one does it now, technically the API allows it.
In case we ever run into the rather subtle case where someone
calls set_memory_xxx() on a vmap() mapping, are you
suggesting that VM_ALLOW_HUGE_VMAP should also apply to
vmap(), rather than only vmalloc()?
something like the concept below?
index 14e5a6f6cc76..204770474c60 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3559,13 +3559,15 @@ static inline unsigned int vm_shift(pgprot_t
prot, unsigned long size)
}
static inline int get_vmap_batch_order(struct page **pages,
- pgprot_t prot, unsigned int max_steps, unsigned int idx)
+ unsigned long flags, pgprot_t prot, unsigned int
max_steps, unsigned int idx)
{
unsigned int nr_contig;
int order;
if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
return 0;
+ if (!(flags & VM_ALLOW_HUGE_VMAP))
+ return 0;
nr_contig = num_pages_contiguous(&pages[idx], max_steps);
if (nr_contig < 2)
@@ -3583,7 +3585,7 @@ static inline int get_vmap_batch_order(struct
page **pages,
}
static int vmap_batched(unsigned long addr, unsigned long end,
- pgprot_t prot, struct page **pages)
+ unsigned long flags, pgprot_t prot, struct page **pages)
{
unsigned int count = (end - addr) >> PAGE_SHIFT;
unsigned int prev_shift = 0, idx = 0;
@@ -3597,7 +3599,7 @@ static int vmap_batched(unsigned long addr,
unsigned long end,
for (unsigned int i = 0; i < count; ) {
unsigned int shift = PAGE_SHIFT +
- get_vmap_batch_order(pages, prot, count - i, i);
+ get_vmap_batch_order(pages, flags, prot, count - i, i);
if (!i)
prev_shift = shift;
@@ -3711,7 +3713,7 @@ void *vmap(struct page **pages, unsigned int count,
return NULL;
addr = (unsigned long)area->addr;
- if (vmap_batched(addr, addr + size, pgprot_nx(prot),
+ if (vmap_batched(addr, addr + size, flags, pgprot_nx(prot),
pages) < 0) {
vunmap(area->addr);
return NULL;
I feel it's unnecessary, given that kvmalloc() already
always uses VM_ALLOW_HUGE_VMAP which will fail
set_memory_xxx() as you mentioned.
kvmalloc() is already a generic memory allocation API.
/*
* kvmalloc() can always use VM_ALLOW_HUGE_VMAP,
* since the callers already cannot assume anything
* about the resulting pointer, and cannot play
* protection games.
*/
return __vmalloc_node_range_noprof(size, align, VMALLOC_START,
VMALLOC_END,
flags, PAGE_KERNEL, allow_block ? VM_ALLOW_HUGE_VMAP:0,
node, __builtin_return_address(0));
Best Regards
Barry
^ permalink raw reply related
* RE: [PATCH v2 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms
From: Kameron Carr @ 2026-06-26 11:08 UTC (permalink / raw)
To: 'Michael Kelley', kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch
In-Reply-To: <SN6PR02MB4157D5F94B5C5F35020FF047D4EC2@SN6PR02MB4157.namprd02.prod.outlook.com>
On Thursday, June 25, 2026 11:59 AM, Michael Kelley wrote:
> From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Thursday,
> June 25, 2026 10:35 AM
> > We need to round up the memory allocated for the input/output pages to
> > the nearest PAGE_SIZE, since set_memory_decrypted() requires the size to
> > be a multiple of PAGE_SIZE. This only has an effect on ARM VMs that are
> > using PAGE_SIZE larger than 4K.
>
> I think this change resulted from a Sashiko comment. My understanding is
> that the ARM CCA architecture only supports CCA guests with 4 KiB page
> size. Is that still the case, or has that restriction been lifted in a
later version
> of the architecture? I'm in favor of handling the larger page sizes, if
only for
> future proofing. But I wondered whether your intent is to always support
> > 4 KiB page sizes even if CCA doesn't support them now. Another way to
> put it: In reviewing code, should I flag issues related to page sizes > 4
KiB?
I think you might be right. I'm looking at RMM spec 2.0 beta 2, and the RMI
can have granule size 4KB, 16KB, 64KB, but the RSI is restricted to granule
size
4KB.
I'm open to suggestion on best way to move forward.
> > @@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu)
> > }
> >
> > if (!ms_hyperv.paravisor_present &&
> > - (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
> > - ret = set_memory_decrypted((unsigned long)mem,
> pgcount);
> > + (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
> > + hv_isolation_type_cca())) {
> > + ret = set_memory_decrypted((unsigned
> long)kasan_reset_tag(mem),
> > + alloc_size >> PAGE_SHIFT);
>
> I don't know enough about KASAN or the tag situation on ARM64
> to comment on this change. But this same sequence of allocating
> memory and then decrypting it occurs in other places in Hyper-V
> code. It seems like those places would also need the same
> kasan_reset_tag() call.
I'm not sure of the exact behavior of PAGE_END when there are
KASAN tags, but it looks like tags could mess with the address
comparison.
I do see that __virt_to_phys_nodebug() and virt_addr_valid() in
arch/arm64/include/asm/memory.h both reset tags before calling
__is_lm_address().
If there are many calls that follow this pattern, it may be better to
add the tag reset in __set_memory_enc_dec().
I can undo this change.
Regards,
Kameron
^ permalink raw reply
* Re: [PATCH 0/6] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Sang-Heon Jeon @ 2026-06-26 10:59 UTC (permalink / raw)
To: Mike Rapoport
Cc: Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Muchun Song, Oscar Salvador, Palmer Dabbelt,
Paul Walmsley, Will Deacon, Alexander Potapenko, Alexandre Ghiti,
Andrey Konovalov, David Hildenbrand, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, linux-mm, linux-riscv, loongarch,
Vincenzo Frascino, WANG Xuerui
In-Reply-To: <aj426bA-YiOKt06m@kernel.org>
On Fri, Jun 26, 2026 at 5:23 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Sun, Jun 21, 2026 at 11:59:10PM +0900, Sang-Heon Jeon wrote:
> > The memblock API guarantees that for_each_mem_range() and
> > for_each_mem_pfn_range() never return an invalid range, meaning start is
> > always less than end.
> >
> > Several memblock callers still have unnecessary invalid range checks in
> > their loop bodies, so remove them.
> >
> > Sang-Heon Jeon (6):
> > arm64: mm: remove unreachable invalid range check in
> > kasan_init_shadow()
> > LoongArch: remove unreachable invalid range check in kasan_init()
> > riscv: remove unreachable invalid range check in
> > create_linear_mapping_page_table()
> > riscv: remove unreachable invalid range check in kasan_init()
> > mm: remove unnecessary empty range check in
> > early_calculate_totalpages()
> > mm/hugetlb: remove unnecessary empty range check in
> > hugetlb_bootmem_set_nodes()
>
> I queued this for inclusion into memblock tree.
Thank you, Mike.
Could you please review and queue this patch [1] as well? It does the
same kind of clean up, I just missed it at the time.
[1] https://lore.kernel.org/all/20260626032902.703944-1-ekffu200098@gmail.com/
> > arch/arm64/mm/kasan_init.c | 3 ---
> > arch/loongarch/mm/kasan_init.c | 3 ---
> > arch/riscv/mm/init.c | 2 --
> > arch/riscv/mm/kasan_init.c | 3 ---
> > mm/hugetlb.c | 3 +--
> > mm/mm_init.c | 3 +--
> > 6 files changed, 2 insertions(+), 15 deletions(-)
> >
> > --
> > 2.43.0
> >
>
> --
> Sincerely yours,
> Mike.
Best Regards,
Sang-Heon Jeon
^ permalink raw reply
* [GIT PULL] arm64 fixes for -rc1
From: Will Deacon @ 2026-06-26 10:59 UTC (permalink / raw)
To: torvalds; +Cc: catalin.marinas, linux-arm-kernel, linux-kernel, kernel-team
Hi Linus,
Please pull this small crop of arm64 fixes for -rc1. We've got a build
fix for a new randconfig permutation, a fix for a long-standing
truncation issue with hardware watchpoints and a KVM initialisation fix
for the newly merged remapping of the kernel data and bss sections.
There will be more to come, but this is the solid stuff for now.
Cheers,
Will
--->8
The following changes since commit 61c19a9feb1d87156e46e38d7759f3ad23710e24:
Merge branch 'for-next/sysregs' into for-next/core (2026-06-14 12:18:27 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
for you to fetch changes up to 36fa5ffa60344bcc59fb3f50b33af8187e6b8753:
arm64: mm: Defer read-only remap of data/bss linear alias (2026-06-24 14:52:14 +0100)
----------------------------------------------------------------
arm64 fixes for -rc1
- Fix randconfig build failure due to missing include of asm/insn.h.
- Reject unaligned hardware watchpoints which were silently being
truncated.
- Fix crash in KVM initialisation by deferring the read-only remapping
of the kernel data and bss sections.
----------------------------------------------------------------
Ard Biesheuvel (1):
arm64: mm: Defer read-only remap of data/bss linear alias
Arnd Bergmann (1):
arm64: static_call: include asm/insns.h
Breno Leitao (1):
arm64/hw_breakpoint: reject unaligned watchpoints that would truncate BAS
arch/arm64/kernel/hw_breakpoint.c | 9 +++++++++
arch/arm64/kernel/static_call.c | 1 +
arch/arm64/mm/mmu.c | 11 ++++++-----
3 files changed, 16 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
From: Krzysztof Kozlowski @ 2026-06-26 10:58 UTC (permalink / raw)
To: Christian Marangi
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Ryder Lee, Michael Turquette,
Stephen Boyd, Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Jianjun Wang, linux-pci, devicetree,
linux-kernel, linux-mediatek, linux-clk, linux-arm-kernel
In-Reply-To: <20260625215741.3253212-2-ansuelsmth@gmail.com>
On Thu, Jun 25, 2026 at 11:57:34PM +0200, Christian Marangi wrote:
> Add additional reset to control PCIe PERSTOUT reset line for each of the 3
> PCIe lines.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> include/dt-bindings/reset/airoha,en7581-reset.h | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 7/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
From: Will Deacon @ 2026-06-26 10:55 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <aj5FZBO7FJ4r219O@google.com>
On Fri, Jun 26, 2026 at 09:24:52AM +0000, Sebastian Ene wrote:
> On Fri, Jun 26, 2026 at 10:11:14AM +0100, Will Deacon wrote:
> > On Fri, Jun 26, 2026 at 07:45:45AM +0000, Sebastian Ene wrote:
> > > Introduce a helper method ffa_check_unused_args_sbz to enforce strict
> > > arguments checking when the hypervisor acts as a relayer between the
> > > host and Trustzone.
> > >
> > > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > > Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 96 ++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 95 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index 712811e89435..bd50ddc5b61c 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -74,6 +74,21 @@ static u32 hyp_ffa_version;
> > > static bool has_version_negotiated;
> > > static hyp_spinlock_t version_lock;
> > >
> > > +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> > > +{
> > > + DECLARE_REG(u32, func_id, ctxt, 0);
> > > + int reg, end_reg = 7;
> > > +
> > > + if (FFA_MINOR_VERSION(hyp_ffa_version) >= 2)
> > > + end_reg = ARM_SMCCC_IS_64(func_id) ? 17 : 7;
> >
> > This looks like an accident waiting to happen if we don't check the major
> > number as well.
> >
> > I think you should just check:
> >
> > if (hyp_ffa_version >= FFA_VERSION_1_2)
> >
> > instead.
> >
> > You should also add a comment.
>
> We restrict hyp_ffa_version major to 1.0 here
> https://elixir.bootlin.com/linux/v7.1.1/source/arch/arm64/kvm/hyp/nvhe/ffa.c#L962
> but since this is an easy fix I will include it.
Thanks, Seb. I'm just certain that if/when we update that check, we'll
forget to update this bit at the same time (I know I would!). So doing
it now is the simplest thing.
With that change:
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* [PATCH] ARM: dma-mapping: Fix wrong free function in __iommu_alloc_simple() error path
From: lirongqing @ 2026-06-26 10:11 UTC (permalink / raw)
To: Russell King, Marek Szyprowski, Leon Romanovsky, Danilo Krummrich,
Matthew Wilcox, Jason Gunthorpe, Li RongQing, Kees Cook,
Douglas Anderson, Gregory CLEMENT, linux-arm-kernel, linux-kernel
From: Li RongQing <lirongqing@baidu.com>
In __iommu_alloc_simple(), when IOMMU mapping creation fails, the error
path unconditionally called __free_from_pool() regardless of the
allocation path taken.
For the COHERENT case, memory is allocated via __alloc_simple_buffer(),
which does not use the atomic pool. Calling __free_from_pool() on such
memory silently returns without freeing, causing a page memory leak.
Fix this by matching the free function to the allocation path:
- COHERENT: use __dma_free_buffer(virt_to_page(addr), size)
- non-COHERENT: use __free_from_pool(addr, size)
Fixes: 565068221b905 ("ARM: 8561/4: dma-mapping: Fix the coherent case when iommu is used")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
arch/arm/mm/dma-mapping.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f9bc53b..55d3d3b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1056,7 +1056,10 @@ static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
return addr;
err_mapping:
- __free_from_pool(addr, size);
+ if (coherent_flag == COHERENT)
+ __dma_free_buffer(virt_to_page(addr), size);
+ else
+ __free_from_pool(addr, size);
return NULL;
}
--
2.9.4
^ 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