* Re: [PATCH v3 55/78] drm/meson: encoder_dsi: Switch to atomic_create_state
From: Martin Blumenstingl @ 2026-06-23 20:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Kevin Hilman, Jerome Brunet, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20260619-drm-no-more-bridge-reset-v3-55-ff399263111b@kernel.org>
On Fri, Jun 19, 2026 at 2:27 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH v3 54/78] drm/meson: encoder_cvbs: Switch to atomic_create_state
From: Martin Blumenstingl @ 2026-06-23 20:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Kevin Hilman, Jerome Brunet, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20260619-drm-no-more-bridge-reset-v3-54-ff399263111b@kernel.org>
On Fri, Jun 19, 2026 at 2:27 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH v5] i2c: imx: mark I2C adapter when hardware is powered down
From: Andi Shyti @ 2026-06-23 20:10 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: o.rempel, kernel, s.hauer, festevam, carlos.song, haibo.chen,
linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260525030400.3182911-1-carlos.song@oss.nxp.com>
Hi Oleksij,
Any chance you can give this a review?
Thanks,
Andi
On Mon, May 25, 2026 at 11:04:00AM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> On some i.MX platforms, certain I2C client drivers keep a periodic
> workqueue which continues to trigger I2C transfers.
>
> During system suspend/resume, there exists a time window between:
> - suspend_noirq and the system entering suspend
> - the system starting to resume and resume_noirq
>
> In this window, the I2C controller resources such as clock and pinctrl
> may already be disabled or not yet restored.
>
> If a workqueue triggers an I2C transfer in this period, the driver
> attempts to access I2C registers while the hardware resources are
> unavailable, which may lead to system hang.
>
> Mark the I2C adapter as suspended during noirq suspend and block new
> transfers until resume, ensuring that I2C transfers are only issued
> when hardware resources are available.
>
> Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
> Change for v5:
> - Remake commit log including the issue detail from Mukesh's
> suggestion.
> Change for v4:
> - Restore hrtimer when pm_runtime_force_suspend failed when slave mode
> enabled.
> Change for v3:
> - Add hrtimer_cancel in i2c_imx_suspend_noirq to cancel slave_timer for
> safe suspend in i2c slave mode.
> Change for v2:
> - Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
> to prevent potential deadlock if a transfer is active during suspend.
> - Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
> fails.
> ---
> drivers/i2c/busses/i2c-imx.c | 45 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 28313d0fad37..73317ddd5f02 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1922,6 +1922,47 @@ static int i2c_imx_runtime_resume(struct device *dev)
> return 0;
> }
>
> +static int __maybe_unused i2c_imx_suspend_noirq(struct device *dev)
> +{
> + struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
> + int ret;
> +
> + i2c_mark_adapter_suspended(&i2c_imx->adapter);
> +
> + /*
> + * Cancel the slave timer before powering down to prevent
> + * i2c_imx_slave_timeout() from accessing hardware registers
> + * while the clock is disabled.
> + */
> + hrtimer_cancel(&i2c_imx->slave_timer);
> +
> + ret = pm_runtime_force_suspend(dev);
> + if (ret) {
> + i2c_mark_adapter_resumed(&i2c_imx->adapter);
> + if (i2c_imx->slave) {
> + hrtimer_forward_now(&i2c_imx->slave_timer, I2C_IMX_CHECK_DELAY);
> + hrtimer_restart(&i2c_imx->slave_timer);
> + }
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __maybe_unused i2c_imx_resume_noirq(struct device *dev)
> +{
> + struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = pm_runtime_force_resume(dev);
> + if (ret)
> + return ret;
> +
> + i2c_mark_adapter_resumed(&i2c_imx->adapter);
> +
> + return 0;
> +}
> +
> static int i2c_imx_suspend(struct device *dev)
> {
> /*
> @@ -1955,8 +1996,8 @@ static int i2c_imx_resume(struct device *dev)
> }
>
> static const struct dev_pm_ops i2c_imx_pm_ops = {
> - NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> + NOIRQ_SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend_noirq,
> + i2c_imx_resume_noirq)
> SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend, i2c_imx_resume)
> RUNTIME_PM_OPS(i2c_imx_runtime_suspend, i2c_imx_runtime_resume, NULL)
> };
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH 5/5] arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display 10.1" LVDS
From: Leonardo Costa @ 2026-06-23 19:57 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
From: Leonardo Costa <leonardo.costa@toradex.com>
Add a device tree overlay enabling the Toradex Capacitive Touch Display
10.1" LVDS V2 on the Verdin Development Board with Verdin AM62 Mezzanine
expansion board. The panel connects via the AM62 OLDI0 on the Mezzanine
LVDS interface (J10). The panel is an Opto Logic SCX1001511GGC49 10.1" WXGA
TFT LCD LVDS and the touch input is provided by an ILITEK ILI251x
capacitive touch controller.
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +
...zanine-panel-cap-touch-10inch-lvds-v2.dtso | 109 ++++++++++++++++++
2 files changed, 114 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 8b90fef11cb32..d9e0b1b80b28d 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-tqma62xx-mba62xx.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dev-mezzanine-can.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dev-nau8822-btl.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-hdmi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
@@ -240,6 +241,9 @@ k3-am625-verdin-wifi-dev-mezzanine-can-dtbs := k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-wifi-dev-mezzanine-panel-cap-touch-10inch-lvds-dtbs := \
k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds.dtbo
+k3-am625-verdin-wifi-dev-mezzanine-panel-cap-touch-10inch-lvds-v2-dtbs := \
+ k3-am625-verdin-wifi-dev.dtb \
+ k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtbo
k3-am625-verdin-wifi-dev-nau8822-btl-dtbs := k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dev-nau8822-btl.dtbo
k3-am625-verdin-wifi-dev-ov5640-24mhz-dtbs := k3-am625-verdin-wifi-dev.dtb \
@@ -362,6 +366,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-verdin-wifi-dev-dsi-to-lvds-v2-panel-cap-touch-10inch.dtb \
k3-am625-verdin-wifi-dev-mezzanine-can.dtb \
k3-am625-verdin-wifi-dev-mezzanine-panel-cap-touch-10inch-lvds.dtb \
+ k3-am625-verdin-wifi-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtb \
k3-am625-verdin-wifi-dev-nau8822-btl.dtb \
k3-am625-verdin-wifi-dev-ov5640-24mhz.dtb \
k3-am625-verdin-wifi-dev-ov5640.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtso
new file mode 100644
index 0000000000000..26f6715463986
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtso
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex Capacitive Touch Display 10.1" LVDS V2 on the Verdin AM62 Mezzanine
+ * LVDS interface (J10), used with the Verdin Development Board.
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
+ * https://www.toradex.com/accessories/capacitive-touch-display-10.1-inch-lvds
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+&{/} {
+ backlight_pwm2: backlight-pwm2 {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ /* Verdin GPIO_4 (SODIMM 212) - LVDS_BKL_EN */
+ enable-gpios = <&mcu_gpio0 4 GPIO_ACTIVE_HIGH>;
+ /* Verdin PWM_2 (SODIMM 16) - LVDS_PWM */
+ pwms = <&epwm0 1 6666667 0>;
+ };
+
+ panel-lvds-native {
+ compatible = "optologic,scx1001511ggc49", "panel-lvds";
+ backlight = <&backlight_pwm2>;
+ data-mapping = "vesa-24";
+ height-mm = <136>;
+ width-mm = <217>;
+
+ panel-timing {
+ clock-frequency = <64500000>;
+ hactive = <1280>;
+ hback-porch = <20>;
+ hfront-porch = <20>;
+ hsync-len = <2>;
+ vactive = <800>;
+ vback-porch = <5>;
+ vfront-porch = <5>;
+ vsync-len = <3>;
+ de-active = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pixelclk-active = <0>;
+ };
+
+ port {
+ panel_lvds_native_in: endpoint {
+ remote-endpoint = <&oldi0_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* DSS VP1: internal DPI output to OLDIx */
+ port@0 {
+ reg = <0>;
+
+ dss0_out: endpoint {
+ remote-endpoint = <&oldi0_in>;
+ };
+ };
+};
+
+/* Verdin I2C_2_DSI */
+&main_i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili251x";
+ reg = <0x41>;
+ /* Verdin GPIO_3 (SODIMM 210) - LVDS_TOUCH_INT# */
+ interrupt-parent = <&mcu_gpio0>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ /* Verdin GPIO_2 (SODIMM 208) - LVDS_TOUCH_RST# */
+ reset-gpios = <&mcu_gpio0 2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&oldi0 {
+ status = "okay";
+};
+
+&oldi0_port0 {
+ oldi0_in: endpoint {
+ remote-endpoint = <&dss0_out>;
+ };
+};
+
+&oldi0_port1 {
+ oldi0_out: endpoint {
+ remote-endpoint = <&panel_lvds_native_in>;
+ };
+};
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with the 10.1" V2 display
From: Leonardo Costa @ 2026-06-23 19:57 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
From: Leonardo Costa <leonardo.costa@toradex.com>
Add a device tree overlay for the Toradex DSI to LVDS Adapter with the
Toradex Capacitive Touch Display 10.1" LVDS V2. The adapter connects to the
Verdin DSI_1 interface. It is based on the Texas Instruments SN65DSI84
DSI-to-LVDS bridge and drives an Opto Logic SCX1001511GGC49 10.1" WXGA TFT
LCD LVDS panel. Touch input is provided by an ILITEK ILI251x capacitive
touch controller.
Link: https://developer.toradex.com/hardware/accessories/add-ons/dsi-lvds-adapter
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +
...dsi-to-lvds-v2-panel-cap-touch-10inch.dtso | 143 ++++++++++++++++++
2 files changed, 148 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 61ae9039e561d..8b90fef11cb32 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lv
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dev-nau8822-btl.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-hdmi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia-dsi-to-hdmi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia-panel-cap-touch-10inch-dsi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia.dtb
@@ -231,6 +232,9 @@ k3-am625-sk-hdmi-audio-dtbs := k3-am625-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch-dtbs := \
k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
+k3-am625-verdin-wifi-dev-dsi-to-lvds-v2-panel-cap-touch-10inch-dtbs := \
+ k3-am625-verdin-wifi-dev.dtb \
+ k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtbo
k3-am625-verdin-wifi-dev-mezzanine-can-dtbs := k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dev-mezzanine-can.dtbo
k3-am625-verdin-wifi-dev-mezzanine-panel-cap-touch-10inch-lvds-dtbs := \
@@ -355,6 +359,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-sk-csi2-tevi-ov5640.dtb \
k3-am625-sk-hdmi-audio.dtb \
k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch.dtb \
+ k3-am625-verdin-wifi-dev-dsi-to-lvds-v2-panel-cap-touch-10inch.dtb \
k3-am625-verdin-wifi-dev-mezzanine-can.dtb \
k3-am625-verdin-wifi-dev-mezzanine-panel-cap-touch-10inch-lvds.dtb \
k3-am625-verdin-wifi-dev-nau8822-btl.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtso
new file mode 100644
index 0000000000000..dba0b6b9f02db
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtso
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex DSI to LVDS Adapter on Verdin DSI_1 with Capacitive Touch Display 10.1"
+ * Used on Dahlia (X17) and Development Board (X48) that expose DSI_1 via an
+ * Samtec LSS-130 connector.
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
+ * https://www.toradex.com/accessories/capacitive-touch-display-10.1-inch-lvds
+ * https://developer.toradex.com/hardware/accessories/add-ons/dsi-lvds-adapter
+ * https://www.toradex.com/accessories/verdin-dsi-to-lvds-adapter
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+&{/} {
+ backlight_pwm3: backlight-pwm3 {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_2_d_out_gpio>;
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ /* Verdin I2S_2_D_OUT as GPIO (SODIMM 46) */
+ enable-gpios = <&main_gpio0 34 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3v3>;
+ /* Verdin PWM_3_DSI (SODIMM 19) */
+ pwms = <&epwm1 0 6666667 0>;
+ };
+
+ panel-lvds-bridge {
+ compatible = "optologic,scx1001511ggc49", "panel-lvds";
+ backlight = <&backlight_pwm3>;
+ data-mapping = "vesa-24";
+ height-mm = <136>;
+ width-mm = <217>;
+
+ /*
+ * The timings here are different from the nominal ones for the
+ * SCX1001511GGC49 display. They are adjusted to ensure that
+ * the Horizontal Front Porch is long enough for the Verdin
+ * AM62 DPI->DSI bridge (Toshiba TC358768) to enter/exit LP
+ * mode. This is required for the display pipeline to work
+ * correctly.
+ */
+ panel-timing {
+ clock-frequency = <69500000>;
+ hactive = <1280>;
+ hback-porch = <20>;
+ hfront-porch = <100>;
+ hsync-len = <24>;
+ vactive = <800>;
+ vback-porch = <5>;
+ vfront-porch = <5>;
+ vsync-len = <3>;
+ de-active = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pixelclk-active = <0>;
+ };
+
+ port {
+ panel_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_out>;
+ };
+ };
+ };
+};
+
+&dsi_bridge {
+ status = "okay";
+};
+
+&dsi_bridge_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dsi_bridge_out: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_in>;
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+/* Verdin I2C_1 */
+&main_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2c {
+ compatible = "ti,sn65dsi84";
+ reg = <0x2c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_bkl_en>;
+ /* Verdin GPIO_10_DSI (SODIMM 21) - DSI_1_BKL_EN */
+ enable-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_bridge_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dsi_lvds_bridge_out: endpoint {
+ remote-endpoint = <&panel_lvds_bridge_in>;
+ };
+ };
+ };
+ };
+
+ touchscreen@41 {
+ compatible = "ilitek,ili251x";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_int>, <&pinctrl_i2s_2_bclk_gpio>;
+ /* Verdin GPIO_9_DSI (SODIMM 17) - TOUCH_INT# */
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_RISING>;
+ /* Verdin I2S_2_BCLK (SODIMM 42) - TOUCH_RESET# */
+ reset-gpios = <&main_gpio0 35 GPIO_ACTIVE_LOW>;
+ };
+};
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS V2
From: Leonardo Costa @ 2026-06-23 19:57 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
From: Leonardo Costa <leonardo.costa@toradex.com>
Add a device tree overlay for the Toradex Capacitive Touch Display 10.1"
LVDS V2 connected via Verdin AM62 OLDI on carrier boards exposing LVDS
interface (e.g., Mallow). The panel is an Opto Logic SCX1001511GGC49 10.1"
WXGA TFT LCD and the touch input is provided by an ILITEK ILI251x
capacitive touch controller.
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +
...verdin-panel-cap-touch-10inch-lvds-v2.dtso | 129 ++++++++++++++++++
2 files changed, 134 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 371f9a043fe52..61ae9039e561d 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -47,6 +47,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-ov5640-24mhz.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-ov5640.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-dsi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-7inch-dsi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-uart4-mcu.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia-dsi-to-hdmi.dtb
@@ -249,6 +250,9 @@ k3-am625-verdin-wifi-dev-uart4-mcu-dtbs := k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds-dtbs := \
k3-am625-verdin-wifi-mallow.dtb \
k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
+k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds-v2-dtbs := \
+ k3-am625-verdin-wifi-mallow.dtb \
+ k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtbo
k3-am62-lp-sk-hdmi-audio-dtbs := k3-am62-lp-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
k3-am62-lp-sk-nand-dtbs := k3-am62-lp-sk.dtb k3-am62-lp-sk-nand.dtbo
k3-am62a7-phyboard-lyra-disable-eth-phy-dtbs := k3-am62a7-phyboard-lyra-rdk.dtb \
@@ -359,6 +363,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-verdin-wifi-dev-panel-cap-touch-7inch-dsi.dtb \
k3-am625-verdin-wifi-dev-uart4-mcu.dtb \
k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds.dtb \
+ k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds-v2.dtb \
k3-am62-lp-sk-hdmi-audio.dtb \
k3-am62-lp-sk-nand.dtb \
k3-am62a7-phyboard-lyra-disable-eth-phy.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtso
new file mode 100644
index 0000000000000..3ea8ccb8bff99
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtso
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex Capacitive Touch Display 10.1" V2 connected via Verdin AM62 OLDI
+ * on carrier boards with a Toradex standard LVDS display connector
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
+ * https://www.toradex.com/accessories/capacitive-touch-display-10.1-inch-lvds
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ backlight_pwm2: backlight-pwm2 {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_2_d_out_gpio>;
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ /* Verdin I2S_2_D_OUT as GPIO (SODIMM 46) */
+ enable-gpios = <&main_gpio0 34 GPIO_ACTIVE_HIGH>;
+ /* Verdin PWM_2 (SODIMM 16) */
+ pwms = <&epwm0 1 6666667 0>;
+ };
+
+ panel-lvds-native {
+ compatible = "optologic,scx1001511ggc49", "panel-lvds";
+ backlight = <&backlight_pwm2>;
+ data-mapping = "vesa-24";
+ height-mm = <136>;
+ width-mm = <217>;
+
+ panel-timing {
+ clock-frequency = <64500000>;
+ hactive = <1280>;
+ hback-porch = <20>;
+ hfront-porch = <20>;
+ hsync-len = <2>;
+ vactive = <800>;
+ vback-porch = <5>;
+ vfront-porch = <5>;
+ vsync-len = <3>;
+ de-active = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pixelclk-active = <0>;
+ };
+
+ port {
+ panel_lvds_native_in: endpoint {
+ remote-endpoint = <&oldi0_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* DSS VP1: internal DPI output to OLDIx */
+ port@0 {
+ reg = <0>;
+
+ dss0_out: endpoint {
+ remote-endpoint = <&oldi0_in>;
+ };
+ };
+};
+
+/* Verdin I2C_2_DSI */
+&main_i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili251x";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_2_d_in_gpio>,
+ <&pinctrl_i2s_2_sync_gpio>;
+ /* Verdin I2S_2_SYNC as GPIO (SODIMM 44) */
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <37 IRQ_TYPE_EDGE_RISING>;
+ /* Verdin I2S_2_D_IN as GPIO(SODIMM 48) */
+ reset-gpios = <&main_gpio0 33 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&main_pmx0 {
+ pinctrl_i2s_2_d_in_gpio: main-gpio0-33-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0088, PIN_INPUT, 7) /* (L24) GPMC0_OEn_REn.GPIO0_33 */ /* SODIMM 48 */
+ >;
+ };
+
+ pinctrl_i2s_2_sync_gpio: main-gpio0-37-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0098, PIN_INPUT, 7) /* (U23) GPMC0_WAIT0.GPIO0_37 */ /* SODIMM 44 */
+ >;
+ };
+};
+
+&oldi0 {
+ status = "okay";
+};
+
+&oldi0_port0 {
+ oldi0_in: endpoint {
+ remote-endpoint = <&dss0_out>;
+ };
+};
+
+&oldi0_port1 {
+ oldi0_out: endpoint {
+ remote-endpoint = <&panel_lvds_native_in>;
+ };
+};
^ permalink raw reply related
* [PATCH 2/5] dt-bindings: display: panel-lvds: Add compatible for Opto Logic SCX1001511GGC49
From: Leonardo Costa @ 2026-06-23 19:57 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
From: Leonardo Costa <leonardo.costa@toradex.com>
The Opto Logic SCX1001511GGC49 is a 10.1" WXGA (1280x800) TFT LCD LVDS
panel.
Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com>
---
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index b89f86bc06837..8382d4920bfd6 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -58,6 +58,8 @@ properties:
- hydis,hv070wx2-1e0
# Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
- jenson,bl-jt60050-01a
+ # Opto Logic SCX1001511GGC49 10.1" WXGA (1280x800) TFT LCD LVDS panel
+ - optologic,scx1001511ggc49
# Riverdi RVT101HVLNWC00 10.1" WXGA (1280x800) TFT LCD LVDS panel
- riverdi,rvt101hvlnwc00
# Riverdi RVT70HSLNWCA0 7.0" WSVGA (1024x600) TFT LCD LVDS panel
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: vendor-prefixes: Add Opto Logic
From: Leonardo Costa @ 2026-06-23 19:57 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
From: Leonardo Costa <leonardo.costa@toradex.com>
Add vendor prefix for Opto Logic, a Swiss display solutions provider and
printing systems manufacturer.
Link: https://optologic.ch/
Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index dd94c50e97f9c..ce0607afc1f4b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1247,6 +1247,8 @@ patternProperties:
description: OpenWrt
"^option,.*":
description: Option NV
+ "^optologic,.*":
+ description: Opto Logic S.A.
"^oranth,.*":
description: Shenzhen Oranth Technology Co., Ltd.
"^ORCL,.*":
^ permalink raw reply related
* [PATCH 0/5] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS
From: Leonardo Costa @ 2026-06-23 19:57 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
From: Leonardo Costa <leonardo.costa@toradex.com>
This series adds device tree overlays for Toradex Capacitive
Touch Display 10.1" LVDS V2 on Verdin AM62.
The display addition covers two interface types:
- Native OLDI (LVDS)
- DSI-to-LVDS adapter based on the SN65DSI84
The Opto Logic vendor prefix and panel binding for the SCX1001511GGC49 is
also added.
Leonardo Costa (5):
dt-bindings: vendor-prefixes: Add Opto Logic
dt-bindings: display: panel-lvds: Add compatible for Opto Logic
SCX1001511GGC49
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
10.1" LVDS V2
arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with
the 10.1" V2 display
arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display
10.1" LVDS
.../bindings/display/panel/panel-lvds.yaml | 2 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/ti/Makefile | 15 ++
...zanine-panel-cap-touch-10inch-lvds-v2.dtso | 109 +++++++++++++
...dsi-to-lvds-v2-panel-cap-touch-10inch.dtso | 143 ++++++++++++++++++
...verdin-panel-cap-touch-10inch-lvds-v2.dtso | 129 ++++++++++++++++
6 files changed, 400 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds-v2.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-v2-panel-cap-touch-10inch.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds-v2.dtso
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 19:56 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <95A8722F-D486-4030-BA51-9117434C6E63@grrlz.net>
On June 23, 2026 7:51:05 PM GMT+01:00, Bradley Morgan <include@grrlz.net>
wrote:
>On June 23, 2026 6:13:48 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
>wrote:
>>On Tue, 23 Jun 2026 18:04:07 +0100,
>>Bradley Morgan <include@grrlz.net> wrote:
>>>
>>> I'll go and do V3 with another sashiko suggestion. I'll fix your path
>>too.
>>
>>Before you do that, please verify that whatever Sashiko spits out
>>makes any sense. I'm not convinced by its reply on v1 at all.
>>
>> M.
>>
>>
>
>Marc,
>
>hi, I have verified sashikos concern.
>
>I am out right now. So I will give a very short result.
>
>
>Sashiko is being bit dramatic with the whole "Critical" rating, but it
>is real in another way
>
>
>I'll explain it in the code in about 30-40 mins.
>
>Thanks!
hey, I'm back now. Let me explain
For the dirty logging report, I agree the bot's wording was not the
greatest..
The issue is not best described as a *guaranteed* -ENOMEM guest abort.
The actual failure path seems to be:
user_mem_abort() skips topup_mmu_memcache() for permission faults,
unless dirty logging is active and
kvm_is_write_fault() is true.
For an instruction permission fault, kvm_is_write_fault() is false.
Dirty logging makes kvm_s2_resolve_vma_size() force max_map_size to
PAGE_SIZE.
If the existing stage 2 entry is *still* a PMD, then kvm_s2_fault_map()
has mapping_size == PAGE_SIZE but perm_fault_granule == PMD_SIZE, so
it calls kvm_pgtable_stage2_map() instead of relax_perms().
The generic stage 2 walker then needs a page table page to split the
PMD in stage2_map_walk_leaf().
So the real issue is that this path can enter the split path without
having topped up the memcache. Eager splitting does not make it
impossible....
since it is best effort and the default split chunk size is 0.
About the V3, I won't send the V3 yet. Until more people review / or
it's been a few days
Thanks!
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 18:51 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <86pl1hqiwj.wl-maz@kernel.org>
On June 23, 2026 6:13:48 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>On Tue, 23 Jun 2026 18:04:07 +0100,
>Bradley Morgan <include@grrlz.net> wrote:
>>
>> I'll go and do V3 with another sashiko suggestion. I'll fix your path
>too.
>
>Before you do that, please verify that whatever Sashiko spits out
>makes any sense. I'm not convinced by its reply on v1 at all.
>
> M.
>
>
Marc,
hi, I have verified sashikos concern.
I am out right now. So I will give a very short result.
Sashiko is being bit dramatic with the whole "Critical" rating, but it
is real in another way
I'll explain it in the code in about 30-40 mins.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 05/12] nvmem: microchip-otpc: add tag-based packet lookup
From: Andy Shevchenko @ 2026-06-23 18:31 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-6-varshini.rajendran@microchip.com>
On Tue, Jun 23, 2026 at 04:29:37PM +0530, Varshini Rajendran wrote:
> Add support for accessing OTP packets by their 4-byte ASCII tag while
> preserving backward compatibility with the existing ID-based lookup.
>
> The OTP memory layout can vary across devices and may change over time,
> making the packet ID approach unreliable when the memory map is not
> known in advance. The packet tag provides a reliable way to identify
> and access packets without prior knowledge of the OTP memory layout.
>
> Two offset encoding are now supported:
> 1. Legacy ID-based: offset = OTP_PKT(id) = id * 4
> Used in DT as: reg = <OTP_PKT(1) 76>;
> 2. TAG-based: offset = 4-byte ASCII packet tag
> Used in DT as: reg = <0x41435354 0x4c>; (tag "ACST")
>
> The driver resolves offsets matching valid legacy selectors (multiples
> of 4 within the packet count) through ID lookup, falling back to tag
> lookup for other values. This ensures existing device trees continue
> to work while enabling new tag-based access.
>
> During probe, packet meta data including the tag is read and cached.
> The driver also validates OTP memory accessibility and emulation mode
> status. When the boot packet is not configured, emulation mode allows
> access to the other packets. When both are not available an
> informational message is logged.
>
> The stride of the nvmem memory is set to 1 in order to support tag based
> offsets, comment in the header file is updated accordingly.
...
> #define MCHP_OTPC_SIZE (11 * 1024)
Side note: At some point maybe (11 * SZ_1K) with help of sizes.h?
...
> +/**
> + * mchp_otpc_resolve_packet() - resolve offset to packet
> + * @otpc: OTPC private data
> + * @off: NVMEM offset (legacy ID-based or TAG-based)
> + *
> + * Legacy offsets (multiples of 4 within valid ID range) are resolved
> + * through ID lookup. Other offsets are treated as 4-byte ASCII tags.
> + *
> + * Return: pointer to packet if found, NULL otherwise
> + */
> +static struct mchp_otpc_packet *mchp_otpc_resolve_packet(struct mchp_otpc *otpc,
> + u32 off)
> +{
> + /*
> + * Legacy id based packet access: offset = id * 4
> + * Inside the driver we use continuous unsigned integer numbers
> + * for packet id, thus divide off by 4 before passing it to
> + * mchp_otpc_id_to_packet().
> + */
> +
> + if (!(off % 4) && (off / 4) < otpc->npackets)
> + return mchp_otpc_id_to_packet(otpc, off / 4);
Hmm... I was thinking about something like temporary variables for these two.
Note, in some cases the compiler may issue a single instruction when it sees
both together. That's why in many GPIO drivers we use something like
unsigned int offset = foo / 8;
unsigned int shift = foo % 8;
or similar.
> + /*
> + * TAG-based packet access: offset is a 4-byte ASCII tag
> + */
> + return mchp_otpc_tag_to_packet(otpc, off);
> +}
...
> {
> struct nvmem_device *nvmem;
> struct mchp_otpc *otpc;
> - u32 size;
> + u32 size, tmp;
> int ret;
> + bool emul_enable;
Perhaps keep the reversed xmas tree order?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 03/12] iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
From: Andy Shevchenko @ 2026-06-23 18:22 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-4-varshini.rajendran@microchip.com>
On Tue, Jun 23, 2026 at 04:29:35PM +0530, Varshini Rajendran wrote:
> Add support for sama7d65 ADC. The differences are highlighted with the
> compatible. The calibration data layout is the main difference.
Do you need to update a Kconfig help text?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/12] iio: adc: at91-sama5d2_adc: rework temp calibration layout handling
From: Andy Shevchenko @ 2026-06-23 18:15 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-3-varshini.rajendran@microchip.com>
On Tue, Jun 23, 2026 at 04:29:34PM +0530, Varshini Rajendran wrote:
> Extend support to handle different temperature calibration layouts.
>
> Add a temperature calibration data layout structure to describe indexes
> of the factors P1, P4, P6, tag, minimum length of the packet and the
> scaling factors for P1 (mul, div) which are SoC-specific instead of the
> older non scalable id structure. This helps handle the differences in the
> same function flow and prepare the calibration data to be applied. Add
> additional condition to validate the calibration data read from the
> NVMEM cell using the TAG of the packet.
>
> Use cleanup helpers for NVMEM data buffer wherever applicable.
> +#define AT91_TEMP_CALIB_TAG_ACST 0x41435354
This seems like FourCC that can be represented in ASCII (I suppose "ACST").
Can you add a short comment on top to decode that?
/* ...blablabla... in ASCII "ACST" */
...
> struct at91_adc_platform {
> const struct at91_adc_reg_layout *layout;
> @@ -481,6 +504,7 @@ struct at91_adc_platform {
> unsigned int chan_realbits;
> unsigned int temp_chan;
> bool temp_sensor;
> + const struct at91_adc_temp_calib_layout *temp_calib_layout;
> };
Is this the best placement in accordance with `pahole` tool?
...
> - u32 *buf;
> + u32 *buf __free(kfree) = NULL;
This looks like a separate change. Why is it in this patch?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 6/8] iommu/qcom: Add NULL ctx check in TLB invalidation paths
From: Robin Murphy @ 2026-06-23 17:08 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623122034.1166295-7-mukesh.ojha@oss.qualcomm.com>
On 23/06/2026 1:20 pm, Mukesh Ojha wrote:
> to_ctx() returns qcom_iommu->ctxs[asid], which can be NULL if the
> corresponding context bank failed to probe or was already removed.
> qcom_iommu_tlb_sync(), qcom_iommu_tlb_inv_context(), and
> qcom_iommu_tlb_inv_range_nosync() all dereference the returned pointer
> directly, risking a NULL pointer dereference.
But if there's no context bank, then how has a domain been allocated in
order to permit io-pgtable operations that would eventually call into
qcom_flush_ops at all? Can you please clarify whether you've actually
observed a real-world issue here, and if so how?
Thanks,
Robin.
> Add WARN_ON(!ctx) guards with continue so TLB operations skip
> broken context banks without crashing.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index 40fb0408dc07..51b60b296bb8 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -121,6 +121,9 @@ static void qcom_iommu_tlb_sync(void *cookie)
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> unsigned int val, ret;
>
> + if (WARN_ON(!ctx))
> + continue;
> +
> iommu_writel(ctx, ARM_SMMU_CB_TLBSYNC, 0);
>
> ret = readl_poll_timeout(ctx->base + ARM_SMMU_CB_TLBSTATUS, val,
> @@ -138,6 +141,10 @@ static void qcom_iommu_tlb_inv_context(void *cookie)
>
> for (i = 0; i < fwspec->num_ids; i++) {
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> +
> + if (WARN_ON(!ctx))
> + continue;
> +
> iommu_writel(ctx, ARM_SMMU_CB_S1_TLBIASID, ctx->asid);
> }
>
> @@ -157,6 +164,9 @@ static void qcom_iommu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> size_t s = size;
>
> + if (WARN_ON(!ctx))
> + continue;
> +
> iova = (iova >> 12) << 12;
> iova |= ctx->asid;
> do {
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 17:42 UTC (permalink / raw)
To: Daniele Briguglio, Diederik de Haas, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260623140958.4181297-1-hello@superkali.me>
Hi,
On Tue Jun 23, 2026 at 4:10 PM CEST, Daniele Briguglio wrote:
>> So IIUC that means I'd be testing both variants.
>
> Right, that covers both: the mux path and the consumer path. Looking
> forward to the results.
Analog audio works on both. Plus with _TO_IO and LTS without in their
respective DTS's. So I guess CLK_IGNORE_UNUSED works.
Whether it's a good/right fix, I'll leave up to others.
Cheers,
Diederik
^ permalink raw reply
* Re: [PATCH v2 04/12] dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example
From: Conor Dooley @ 2026-06-23 17:28 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-5-varshini.rajendran@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
On Tue, Jun 23, 2026 at 04:29:36PM +0530, Varshini Rajendran wrote:
> Add support for sama7d65 and a dt node example that shows tag can be used
> to reference a packet stored in the OTP memory.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> ---
> .../nvmem/microchip,sama7g5-otpc.yaml | 28 +++++++++++++++++--
> 1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> index cc25f2927682..3cc16b0044a6 100644
> --- a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> @@ -20,9 +20,15 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: microchip,sama7g5-otpc
> - - const: syscon
> + oneOf:
> + - items:
> + - const: microchip,sama7g5-otpc
> + - const: syscon
> + - items:
> + - enum:
> + - microchip,sama7d65-otpc
> + - const: microchip,sama7g5-otpc
> + - const: syscon
>
> reg:
> maxItems: 1
> @@ -48,4 +54,20 @@ examples:
> };
> };
>
> + - |
> + otp_controller: efuse@e8c00000 {
Drop the unused label since you have to respin the series.
With it gone
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> + compatible = "microchip,sama7d65-otpc", "microchip,sama7g5-otpc", "syscon";
> + reg = <0xe8c00000 0x100>;
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + temp_calib: calib@41435354 {
> + reg = <0x41435354 0x2c>; /* Temp calib data packet TAG */
> + };
> + };
> + };
> +
> ...
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: iio: adc: at91-sama5d2: document sama7d65
From: Conor Dooley @ 2026-06-23 17:26 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260623105944.128840-2-varshini.rajendran@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
On Tue, Jun 23, 2026 at 04:29:33PM +0530, Varshini Rajendran wrote:
> Add dt-binding documentation for sama7d65 ADC.
Commit message is missing an explanation of why a fallback is not
suitable.
pw-bot: changes-requested
Thanks,
Conor
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> index 4817b840977a..e8a65fdcd018 100644
> --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> @@ -15,6 +15,7 @@ properties:
> - atmel,sama5d2-adc
> - microchip,sam9x60-adc
> - microchip,sama7g5-adc
> + - microchip,sama7d65-adc
>
> reg:
> maxItems: 1
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Mathieu Poirier @ 2026-06-23 17:21 UTC (permalink / raw)
To: Tanmay Shah
Cc: michal.simek, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <20260619163854.410392-1-tanmay.shah@amd.com>
On Fri, Jun 19, 2026 at 09:38:54AM -0700, Tanmay Shah wrote:
> Current _start and _stop ops are implemented using various APIs from the
> platform management firmware driver. Instead provide respective RPU
> start and stop API in the firmware driver and move the logic to interact
> with the PM firmware in the firmware driver. The remoteproc driver doesn't
> need to know actual logic, but only the final result i.e. RPU start/stop
> was success or not. This refactor keeps the remoteproc driver simple and
> moves firmware interaction logic to the firmware driver.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
> 3 files changed, 110 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index af838b2dc327..f9a3a95b0638 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>
> +/**
> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + * @bootaddr: Boot address of elf
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + enum rpu_boot_mem bootmem;
> + int ret;
> +
> + /*
> + * The exception vector pointers (EVP) refer to the base-address of
> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> + * starts at the base-address and subsequent vectors are on 4-byte
> + * boundaries.
> + *
> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> + *
> + * Usually firmware will put Exception vectors at LOVEC.
> + *
> + * It is not recommend that you change the exception vector.
> + * Changing the EVP to HIVEC will result in increased interrupt latency
> + * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> + * is non-secured, then the Cortex-R5F processor cannot access the
> + * HIVEC exception vectors in the OCM.
> + */
> + bootmem = (bootaddr >= 0xFFFC0000) ?
> + PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> +
> + pr_debug("RPU boot addr 0x%llx from %s.", bootaddr,
> + bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> +
> + /* Request node before starting RPU core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_REQUEST_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_request_node(node,
> + ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> + ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret < 0) {
> + pr_err("failed to request 0x%x", node);
> + return ret;
> + }
> + }
> +
> + ret = zynqmp_pm_request_wake(node, true,
> + bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + if (ret)
> + pr_err("failed to start RPU = 0x%x\n", node);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_start_rpu);
> +
> +/**
> + * zynqmp_pm_stop_rpu - Stop Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + int ret;
> +
> + /* Use release node API to stop core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_RELEASE_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_release_node(node);
> + if (ret)
> + pr_err("failed to stop remoteproc RPU %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Check expected version of EEMI call before calling it. This avoids
> + * any error or warning prints from firmware as it is expected that fw
> + * doesn't support it.
> + */
> + if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != PM_API_VERSION_1) {
> + pr_debug("EEMI interface %d ver 1 not supported\n",
> + PM_FORCE_POWERDOWN);
> + return -EOPNOTSUPP;
> + }
> +
> + /* maintain force pwr down for backward compatibility */
> + ret = zynqmp_pm_force_pwrdwn(node, ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret)
> + pr_err("core force power down failed\n");
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_stop_rpu);
> +
> /**
> * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
> * @node: Node ID of the slave
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 3349d1877751..dcd8a93f031c 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -364,49 +364,12 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
> static int zynqmp_r5_rproc_start(struct rproc *rproc)
> {
> struct zynqmp_r5_core *r5_core = rproc->priv;
> - enum rpu_boot_mem bootmem;
> int ret;
>
> - /*
> - * The exception vector pointers (EVP) refer to the base-address of
> - * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> - * starts at the base-address and subsequent vectors are on 4-byte
> - * boundaries.
> - *
> - * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> - * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> - *
> - * Usually firmware will put Exception vectors at LOVEC.
> - *
> - * It is not recommend that you change the exception vector.
> - * Changing the EVP to HIVEC will result in increased interrupt latency
> - * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> - * is non-secured, then the Cortex-R5F processor cannot access the
> - * HIVEC exception vectors in the OCM.
> - */
> - bootmem = (rproc->bootaddr >= 0xFFFC0000) ?
> - PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> -
> - dev_dbg(r5_core->dev, "RPU boot addr 0x%llx from %s.", rproc->bootaddr,
> - bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> -
> - /* Request node before starting RPU core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_REQUEST_NODE) > 1) {
> - ret = zynqmp_pm_request_node(r5_core->pm_domain_id,
> - ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> - if (ret < 0) {
> - dev_err(r5_core->dev, "failed to request 0x%x",
> - r5_core->pm_domain_id);
> - return ret;
> - }
> - }
> -
> - ret = zynqmp_pm_request_wake(r5_core->pm_domain_id, 1,
> - bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + ret = zynqmp_pm_start_rpu(r5_core->pm_domain_id, rproc->bootaddr);
> if (ret)
> - dev_err(r5_core->dev,
> - "failed to start RPU = 0x%x\n", r5_core->pm_domain_id);
> + dev_err(&rproc->dev, "failed to start RPU\n");
> +
> return ret;
> }
>
> @@ -423,30 +386,9 @@ static int zynqmp_r5_rproc_stop(struct rproc *rproc)
> struct zynqmp_r5_core *r5_core = rproc->priv;
> int ret;
>
> - /* Use release node API to stop core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_RELEASE_NODE) > 1) {
> - ret = zynqmp_pm_release_node(r5_core->pm_domain_id);
> - if (ret)
> - dev_err(r5_core->dev, "failed to stop remoteproc RPU %d\n", ret);
> - return ret;
> - }
> -
> - /*
> - * Check expected version of EEMI call before calling it. This avoids
> - * any error or warning prints from firmware as it is expected that fw
> - * doesn't support it.
> - */
> - if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != 1) {
> - dev_dbg(r5_core->dev, "EEMI interface %d ver 1 not supported\n",
> - PM_FORCE_POWERDOWN);
> - return -EOPNOTSUPP;
> - }
> -
> - /* maintain force pwr down for backward compatibility */
> - ret = zynqmp_pm_force_pwrdwn(r5_core->pm_domain_id,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + ret = zynqmp_pm_stop_rpu(r5_core->pm_domain_id);
> if (ret)
> - dev_err(r5_core->dev, "core force power down failed\n");
> + dev_err(&rproc->dev, "failed to stop RPU\n");
>
> return ret;
> }
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index 7e27b0f7bf7e..347df66ee176 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -644,6 +644,8 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr);
> +int zynqmp_pm_stop_rpu(const u32 node);
> int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
> int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
> u32 value);
> @@ -960,6 +962,16 @@ static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const statu
> return -ENODEV;
> }
>
> +static inline int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + return -ENODEV;
> +}
> +
> static inline int zynqmp_pm_set_sd_config(u32 node,
> enum pm_sd_config_type config,
> u32 value)
>
> base-commit: 721396afea31eac476d88f5db10ba111ba4b8382
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Marc Zyngier @ 2026-06-23 17:13 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <5925B41F-0F57-4BCB-9F93-7600878ECA27@grrlz.net>
On Tue, 23 Jun 2026 18:04:07 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> I'll go and do V3 with another sashiko suggestion. I'll fix your path too.
Before you do that, please verify that whatever Sashiko spits out
makes any sense. I'm not convinced by its reply on v1 at all.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-23 17:11 UTC (permalink / raw)
To: Dev Jain
Cc: Harry Yoo, ryabinin.a.a, akpm, corbet, glider, andreyknvl,
dvyukov, vincenzo.frascino, kasan-dev, linux-mm, linux-kernel,
skhan, workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <78d97371-b477-4230-8690-ac870a7bab3b@arm.com>
On Tue, Jun 23, 2026 at 10:32:16AM +0530, Dev Jain wrote:
> On 22/06/26 10:43 pm, Catalin Marinas wrote:
> > On Mon, Jun 22, 2026 at 09:42:10PM +0900, Harry Yoo wrote:
> >> On 6/19/26 10:19 PM, Catalin Marinas wrote:
> >>> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
> >>>> On 6/12/26 1:44 PM, Dev Jain wrote:
> >>>>> Now, when a memory object will be freed, it will retain the random tag it
> >>>>> had at allocation time. This compromises on catching UAF bugs, till the
> >>>>> time the object is not reallocated, at which point it will have a new
> >>>>> random tag.
> >>>>>
> >>>>> Hence, not catching "use-after-free-before-reallocation" and not catching
> >>>>> "double-free" will be the compromise for reduced KASAN overhead.
> >>>>
> >>>> I doubt users who care about security enough to enable HW_TAGS KASAN
> >>>> are willing to compromise on security just to save a few instructions
> >>>> to store tags in the free path.
> >>>>
> >>>> To me, it looks like too much of a compromise on security for little
> >>>> performance gain.
> >>>
> >>> I don't think there's much compromise on security for use-after-free.
> >>
> >> I think it depends... OH, WAIT! I see what you mean.
> >>
> >> You mean use-after-free before reallocation does not lead to much
> >> compromise on security because objects are initialized after allocation?
> >>
> >> You're probably right.
> >>
> >> Hmm, but stores to e.g.) free pointer, fields initialized by
> >> constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
> >> will be undiscovered if they happen before reallocation.
> >
> > Even with SLAB_TYPESAFE_BY_RCU, the object isn't tagged on free either
> > (or realloc, only if the actual slab page ends up freed). But we don't
> > get type confusion for such slab.
> >
> > However, without tagging on free, one could argue that it reduces
> > security for cases where the page is re-allocated as untagged - e.g. all
> > user pages mapped without PROT_MTE. Currently we have a deterministic
> > tag check fault if the page is coloured as KASAN_TAG_INVALID. I think
>
> So you are saying that a stale kernel pointer can continue to use the
> reallocated page, because for non-PROT_MTE case the page does not get
> a new tag. Makes sense.
Yes.
> > for this patch, it might be better to only do such skip on free in
> > kasan_poison_slab() rather than kasan_poison(). Freed pages would then
> > be tagged.
>
> I think you mean to say, "skip tag on free when freeing pages into buddy"?
No, I meant always poison via kasan_poison_pages(), as we currently do
with KASAN_PAGE_FREE being set.
> So that would mean, kasan_poison() will do the poisoning also in the
> case of value == KASAN_PAGE_FREE.
>
> > An alternative would be tagging on free only with a new tag and skipping
> > it on re-alloc. But we'd need to track when it's a completely new
> > allocation or a reused object (I haven't looked I'm pretty sure it's
> > doable).
>
> That was our original approach, and IIRC we had concluded there was no
> security compromise. However it is difficult to implement - it has cases
> like, what happens when two differently tagged pages are coalesced by
> buddy and someone gets that large page as an allocation.
Yeah, it's fairly complex.
I think the more problematic case is when we can't detect
use-after-reallocation and this happens when a page is reused untagged
(probabilistically, also when the page is reused with the old tag). As
an optimisation, it might be sufficient to skip poisoning when freeing
an object into the slab but keep the poisoning when freeing a slab page
into the buddy allocator. That's where the page may end up in a place
untagged.
Also for your optimisation to only tag on reallocation, do you have any
code to read the current tag and avoid reusing it? That's useful for
kmalloc caches or other merged kmem caches where we can have type
confusion.
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 17:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <86qzlxqjf3.wl-maz@kernel.org>
On June 23, 2026 6:02:40 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>Bradley,
>
>Just a few things to keep in mind for your next contributions:
>
>- If you are sending more than a single patch, add a cover letter.
>
>- Don't send a v2 in reply to a v1. It messes the threading we are
> relying on, and makes it hard to ignore replies to an older version.
> Always send new series standalone.
>
>- Don't immediately send a V2, even if (especially if!) a bot is
> pestering you. 34 minutes between versions is way too short (at
> least a few days is the norm).
>
>On Tue, 23 Jun 2026 17:37:55 +0100,
>Bradley Morgan <include@grrlz.net> wrote:
>>
>> pKVM keeps its own mapping list for stage 2 operations. Its flush path
>> uses that list directly, so it lost the PTE attribute check done by the
>> generic stage 2 walker.
>>
>> Record whether a mapping is cacheable and skip cache maintenance for
>> mappings that are not cacheable.
>>
>> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
>> Cc: stable@vger.kernel.org
>
>What device memory gets mapped in an upstream pKVM guest that would
>require a backport to stable?
>
>> Signed-off-by: Bradley Morgan <include@grrlz.net>
>> ---
>> Changes in v2:
>> - Add patch 2 for the pKVM permission fault mapping cache bug.
>
>This is the sort of information that goes in the cover letter.
>
>>
>> arch/arm64/include/asm/kvm_pkvm.h | 1 +
>> arch/arm64/kvm/pkvm.c | 8 +++++++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_pkvm.h
>b/arch/arm64/include/asm/kvm_pkvm.h
>> index 74fedd9c5ff0..d9dd8239910d 100644
>> --- a/arch/arm64/include/asm/kvm_pkvm.h
>> +++ b/arch/arm64/include/asm/kvm_pkvm.h
>> @@ -196,6 +196,7 @@ struct pkvm_mapping {
>> u64 gfn;
>> u64 pfn;
>> u64 nr_pages;
>> + bool cacheable;
>
>Errr, no. That's a terrible idea.
>
>This thing is already big enough, let's not add a bool right in the
>middle (use pahole to find out why this is bad). Given that nr_pages
>is for a range, and that the minimum page size uses 12 bits, the
>largest number of pages you can have here is 56-12=48 bit wide. That's
>another 16 bits worth of flags you can use.
>
>Thanks,
>
> M.
>
>
thanks.
I'll go and do V3 with another sashiko suggestion. I'll fix your path too.
I'll park V3 for a bit.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Marc Zyngier @ 2026-06-23 17:02 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260623163756.4591-1-include@grrlz.net>
Bradley,
Just a few things to keep in mind for your next contributions:
- If you are sending more than a single patch, add a cover letter.
- Don't send a v2 in reply to a v1. It messes the threading we are
relying on, and makes it hard to ignore replies to an older version.
Always send new series standalone.
- Don't immediately send a V2, even if (especially if!) a bot is
pestering you. 34 minutes between versions is way too short (at
least a few days is the norm).
On Tue, 23 Jun 2026 17:37:55 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> pKVM keeps its own mapping list for stage 2 operations. Its flush path
> uses that list directly, so it lost the PTE attribute check done by the
> generic stage 2 walker.
>
> Record whether a mapping is cacheable and skip cache maintenance for
> mappings that are not cacheable.
>
> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> Cc: stable@vger.kernel.org
What device memory gets mapped in an upstream pKVM guest that would
require a backport to stable?
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
> Changes in v2:
> - Add patch 2 for the pKVM permission fault mapping cache bug.
This is the sort of information that goes in the cover letter.
>
> arch/arm64/include/asm/kvm_pkvm.h | 1 +
> arch/arm64/kvm/pkvm.c | 8 +++++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
> index 74fedd9c5ff0..d9dd8239910d 100644
> --- a/arch/arm64/include/asm/kvm_pkvm.h
> +++ b/arch/arm64/include/asm/kvm_pkvm.h
> @@ -196,6 +196,7 @@ struct pkvm_mapping {
> u64 gfn;
> u64 pfn;
> u64 nr_pages;
> + bool cacheable;
Errr, no. That's a terrible idea.
This thing is already big enough, let's not add a bool right in the
middle (use pahole to find out why this is bad). Given that nr_pages
is for a range, and that the minimum page size uses 12 bits, the
largest number of pages you can have here is 56-12=48 bit wide. That's
another 16 bits worth of flags you can use.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: stmmac: dwmac-spacemit: Fix wrong irq definition
From: Maxime Chevallier @ 2026-06-23 16:54 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260623074637.503864-3-inochiama@gmail.com>
Hi,
On 6/23/26 09:46, Inochi Amaoto wrote:
> The current irq definition of the wake irq and the lpi irq
> is wrong, replace them with the right number and name.
>
> Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> index 3bfb6d49be6c..322bdf167a4a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> @@ -22,8 +22,8 @@
> #define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
> #define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
> #define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
> -#define CTRL_WAKE_IRQ_EN BIT(9)
> -#define CTRL_PHY_IRQ_EN BIT(12)
> +#define CTRL_LPI_IRQ_EN BIT(9)
> +#define CTRL_WAKE_IRQ_EN BIT(12)
>
> /* dline register bits */
> #define RGMII_RX_DLINE_EN BIT(0)
^ permalink raw reply
* Re: [PATCH net v2 1/2] net: stmmac: dwmac-spacemit: Fix wrong phy interface definition
From: Maxime Chevallier @ 2026-06-23 16:53 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260623074637.503864-2-inochiama@gmail.com>
Hello,
On 6/23/26 09:46, Inochi Amaoto wrote:
> The current MII interface register definition from the vendor is wrong,
> use the right number for the macro. Also, correct the interface mask
> in spacemit_set_phy_intf_sel() so it can update the register with the
> right number
>
> Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> index 223754cc5c79..3bfb6d49be6c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> @@ -18,8 +18,10 @@
> #include "stmmac_platform.h"
>
> /* ctrl register bits */
> -#define CTRL_PHY_INTF_RGMII BIT(3)
> -#define CTRL_PHY_INTF_MII BIT(4)
> +#define CTRL_PHY_INTF_MODE GENMASK(4, 3)
> +#define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
> +#define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
> +#define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
> #define CTRL_WAKE_IRQ_EN BIT(9)
> #define CTRL_PHY_IRQ_EN BIT(12)
>
> @@ -118,7 +120,7 @@ static void spacemit_get_interfaces(struct stmmac_priv *priv, void *bsp_priv,
>
> static int spacemit_set_phy_intf_sel(void *bsp_priv, u8 phy_intf_sel)
> {
> - unsigned int mask = CTRL_PHY_INTF_MII | CTRL_PHY_INTF_RGMII;
> + unsigned int mask = CTRL_PHY_INTF_MODE;
> struct spacmit_dwmac *dwmac = bsp_priv;
> unsigned int val = 0;
>
> @@ -128,6 +130,7 @@ static int spacemit_set_phy_intf_sel(void *bsp_priv, u8 phy_intf_sel)
> break;
>
> case PHY_INTF_SEL_RMII:
> + val = CTRL_PHY_INTF_RMII;
This isn't strictly-speaking necessary as this is 0 and val is already 0, maybe
compilers can figure it out and this leaves us with more self-documenting code ?
So I'm ok with that personally,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
> break;
>
> case PHY_INTF_SEL_RGMII:
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox