* [PATCH v6 06/10] clk: realtek: Add support for mux clock
From: Yu-Chun Lin @ 2026-04-02 7:39 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260402073957.2742459-1-eleanor.lin@realtek.com>
From: Cheng-Yu Lee <cylee12@realtek.com>
Add a simple regmap-based clk_ops implementation for Realtek mux clocks.
The implementation supports parent selection and rate determination through
regmap-backed register access.
Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v6:
- Add the headers used in c file to follow the "Include What You Use" principle.
---
drivers/clk/realtek/Makefile | 1 +
drivers/clk/realtek/clk-regmap-mux.c | 48 ++++++++++++++++++++++++++++
drivers/clk/realtek/clk-regmap-mux.h | 43 +++++++++++++++++++++++++
3 files changed, 92 insertions(+)
create mode 100644 drivers/clk/realtek/clk-regmap-mux.c
create mode 100644 drivers/clk/realtek/clk-regmap-mux.h
diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
index 74375f8127ac..f90dc57fcfdb 100644
--- a/drivers/clk/realtek/Makefile
+++ b/drivers/clk/realtek/Makefile
@@ -5,4 +5,5 @@ clk-rtk-y += common.o
clk-rtk-y += clk-pll.o
clk-rtk-y += clk-regmap-gate.o
+clk-rtk-y += clk-regmap-mux.o
clk-rtk-y += freq_table.o
diff --git a/drivers/clk/realtek/clk-regmap-mux.c b/drivers/clk/realtek/clk-regmap-mux.c
new file mode 100644
index 000000000000..068b056d61f0
--- /dev/null
+++ b/drivers/clk/realtek/clk-regmap-mux.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2017 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#include <linux/regmap.h>
+#include <linux/clk-provider.h>
+#include "clk-regmap-mux.h"
+
+static u8 clk_regmap_mux_get_parent(struct clk_hw *hw)
+{
+ struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
+ int num_parents = clk_hw_get_num_parents(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(clkm->clkr.regmap, clkm->mux_ofs, &val);
+ if (ret)
+ return 0;
+
+ val = val >> clkm->shift & clkm->mask;
+
+ if (val >= num_parents)
+ return 0;
+
+ return val;
+}
+
+static int clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
+
+ return regmap_update_bits(clkm->clkr.regmap, clkm->mux_ofs,
+ clkm->mask << clkm->shift, index << clkm->shift);
+}
+
+const struct clk_ops rtk_clk_regmap_mux_ops = {
+ .set_parent = clk_regmap_mux_set_parent,
+ .get_parent = clk_regmap_mux_get_parent,
+ .determine_rate = __clk_mux_determine_rate,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ops, "REALTEK_CLK");
+
+const struct clk_ops rtk_clk_regmap_mux_ro_ops = {
+ .get_parent = clk_regmap_mux_get_parent,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ro_ops, "REALTEK_CLK");
diff --git a/drivers/clk/realtek/clk-regmap-mux.h b/drivers/clk/realtek/clk-regmap-mux.h
new file mode 100644
index 000000000000..cf7ab6a0604c
--- /dev/null
+++ b/drivers/clk/realtek/clk-regmap-mux.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2017 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#ifndef __CLK_REALTEK_CLK_REGMAP_MUX_H
+#define __CLK_REALTEK_CLK_REGMAP_MUX_H
+
+#include "common.h"
+
+struct clk_regmap_mux {
+ struct clk_regmap clkr;
+ int mux_ofs;
+ unsigned int mask;
+ unsigned int shift;
+};
+
+#define __clk_regmap_mux_hw(_p) __clk_regmap_hw(&(_p)->clkr)
+
+#define __CLK_REGMAP_MUX(_name, _parents, _ops, _flags, _ofs, _sft, _mask) \
+ struct clk_regmap_mux _name = { \
+ .clkr.hw.init = \
+ CLK_HW_INIT_PARENTS(#_name, _parents, _ops, _flags), \
+ .mux_ofs = _ofs, \
+ .shift = _sft, \
+ .mask = _mask, \
+ }
+
+#define CLK_REGMAP_MUX(_name, _parents, _flags, _ofs, _sft, _mask) \
+ __CLK_REGMAP_MUX(_name, _parents, &rtk_clk_regmap_mux_ops, _flags, _ofs, \
+ _sft, _mask)
+
+static inline struct clk_regmap_mux *to_clk_regmap_mux(struct clk_hw *hw)
+{
+ struct clk_regmap *clkr = to_clk_regmap(hw);
+
+ return container_of(clkr, struct clk_regmap_mux, clkr);
+}
+
+extern const struct clk_ops rtk_clk_regmap_mux_ops;
+
+#endif /* __CLK_REALTEK_CLK_REGMAP_MUX_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v6 10/10] arm64: dts: realtek: Add clock support for RTD1625
From: Yu-Chun Lin @ 2026-04-02 7:39 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260402073957.2742459-1-eleanor.lin@realtek.com>
Add the clock controller nodes and osc27m fixed clock for the
Realtek RTD1625 SoC.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
arch/arm64/boot/dts/realtek/kent.dtsi | 33 +++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index ae006ce24420..4722337a143d 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -26,6 +26,15 @@ timer {
<GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
+ clocks {
+ osc27m: osc {
+ compatible = "fixed-clock";
+ clock-frequency = <27000000>;
+ clock-output-names = "osc27m";
+ #clock-cells = <0>;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -141,6 +150,14 @@ rbus: bus@98000000 {
#address-cells = <1>;
#size-cells = <1>;
+ cc: clock-controller@0 {
+ compatible = "realtek,rtd1625-crt-clk";
+ reg = <0x0 0x900>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
uart0: serial@7800 {
compatible = "snps,dw-apb-uart";
reg = <0x7800 0x100>;
@@ -150,6 +167,22 @@ uart0: serial@7800 {
reg-shift = <2>;
status = "disabled";
};
+
+ ic: clock-controller@7088 {
+ compatible = "realtek,rtd1625-iso-clk";
+ reg = <0x7088 0x8>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ iso_s_cc: clock-controller@146310 {
+ compatible = "realtek,rtd1625-iso-s-clk";
+ reg = <0x146310 0x8>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
};
gic: interrupt-controller@ff100000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Krzysztof Kozlowski @ 2026-04-02 8:11 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-2-ca5ffdff99d4@linaro.org>
On Thu, Apr 02, 2026 at 03:20:15AM +0100, Alexey Klimov wrote:
> Exynos850-based platforms support ACPM and has similar workflow
> of communicating with ACPM via mailbox, however mailbox controller
> registers are located at different offsets and writes/reads could be
> different. To distinguish between such different behaviours,
> the registers offsets for Exynos850 and the platform-specific data
> structs are introduced and configuration is described in such structs
> for gs101 and exynos850 based SoCs. Probe routine now selects the
> corresponding platform-specific data via device_get_match_data().
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Florijan Plohl @ 2026-04-02 7:08 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, upstream
Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
---
arch/arm64/boot/dts/freescale/Makefile | 4 +
.../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
.../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
3 files changed, 288 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index bae24b53bce6..8f5b3996b678 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -437,17 +437,21 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-kontron-bl-osm-s.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin.dtb
+imx91-phyboard-segin-peb-av-18-dtbs += imx91-phyboard-segin.dtb imx91-phyboard-segin-peb-av-18.dtbo
imx93-phyboard-nash-jtag-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-jtag.dtbo
imx93-phyboard-nash-peb-wlbt-07-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-peb-wlbt-07.dtbo
imx93-phyboard-nash-pwm-fan-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-pwm-fan.dtbo
imx93-phyboard-segin-peb-av-02-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-av-18-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-18.dtbo
imx93-phyboard-segin-peb-eval-01-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-eval-01.dtbo
imx93-phyboard-segin-peb-wlbt-05-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-wlbt-05.dtbo
imx93-phycore-rpmsg-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-segin.dtb imx93-phycore-rpmsg.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin-peb-av-18.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-jtag.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-peb-wlbt-07.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-pwm-fan.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-02.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-18.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-eval-01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-wlbt-05.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phycore-rpmsg.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..ec6ef2e5a11a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include <dt-bindings/clock/imx93-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "imx91-pinfunc.h"
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <®_vcc_3v3_con>;
+ pwms = <&pwm7 0 5000000 0>;
+ };
+
+ panel {
+ compatible = "powertip,ph800480t032-zhc19";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel>;
+
+ backlight = <&backlight>;
+ enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_vcc_3v3_con>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+
+ pwm7: pwm-7 {
+ compatible = "pwm-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ #pwm-cells = <3>;
+ };
+
+ reg_vcc_3v3_con: regulator-vcc-3v3-con {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_CON";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+};
+
+&dpi_bridge {
+ status = "okay";
+};
+
+&dpi_to_panel {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-rates = <27272728>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2130";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x50e
+ MX91_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x50e
+ MX91_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x50e
+ MX91_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x50e
+ MX91_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA0 0x50e
+ MX91_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA1 0x50e
+ MX91_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA2 0x50e
+ MX91_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA3 0x50e
+ MX91_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA4 0x50e
+ MX91_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA5 0x51e
+ MX91_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA6 0x50e
+ MX91_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA7 0x50e
+ MX91_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA8 0x50e
+ MX91_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA9 0x50e
+ MX91_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x50e
+ MX91_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x50e
+ MX91_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x506
+ MX91_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x506
+ MX91_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x506
+ MX91_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x506
+ MX91_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x506
+ MX91_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x506
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDIO__GPIO4_IO1 0x11e
+ MX91_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..189b0f0472d2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include <dt-bindings/clock/imx93-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "imx93-pinfunc.h"
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <®_vcc_3v3_con>;
+ pwms = <&pwm7 0 5000000 0>;
+ };
+
+ panel {
+ compatible = "powertip,ph800480t032-zhc19";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel>;
+
+ backlight = <&backlight>;
+ enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_vcc_3v3_con>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+
+ pwm7: pwm-7 {
+ compatible = "pwm-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ #pwm-cells = <3>;
+ };
+
+ reg_vcc_3v3_con: regulator-vcc-3v3-con {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_CON";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+};
+
+&dpi_bridge {
+ status = "okay";
+};
+
+&dpi_to_panel {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-rates = <27272728>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2130";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x50e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x50e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x50e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x50e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x50e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x50e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x50e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x50e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x50e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x51e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x50e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x50e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x50e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x50e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x50e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x50e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x506
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x506
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x506
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x506
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x506
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x506
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x11e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Krzysztof Kozlowski @ 2026-04-02 8:01 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-3-ca5ffdff99d4@linaro.org>
On Thu, Apr 02, 2026 at 03:20:16AM +0100, Alexey Klimov wrote:
> Add mailbox node that describes AP-to-APM mailbox, that can be
> used for communicating with APM co-processor on Exynos850 SoCs.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
What DTS is doing in the middle of the patchset? If there is going to be
resend, then fix the order. If the order is intended, then most likely
NAK but I need somewhere explanation (but I really do not see the need
for it).
Please read submitting patches (both documents).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-02 7:57 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <0a951e34b7030e514091d6c0922c5982ae349221.1775090165.git.daniel@makrotopia.org>
On Thu, Apr 02, 2026 at 01:37:02AM +0100, Daniel Golle wrote:
> Add compatible strings for MediaTek SoCs where the hardware random number
> generator is accessed via a vendor-defined Secure Monitor Call (SMC)
> rather than direct MMIO register access:
>
> - mediatek,mt7981-rng
> - mediatek,mt7987-rng
> - mediatek,mt7988-rng
>
> These variants require no reg, clocks, or clock-names properties since
> the RNG hardware is managed by ARM Trusted Firmware-A.
>
> Relax the $nodename pattern to also allow 'rng' in addition to the
> existing 'rng@...' pattern.
>
> Add a second example showing the minimal SMC variant binding.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v2: express compatibilities with fallback
>
> .../devicetree/bindings/rng/mtk-rng.yaml | 28 ++++++++++++++++---
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> index 7e8dc62e5d3a6..34648b53d14c6 100644
> --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> @@ -11,12 +11,13 @@ maintainers:
>
> properties:
> $nodename:
> - pattern: "^rng@[0-9a-f]+$"
> + pattern: "^rng(@[0-9a-f]+)?$"
>
> compatible:
> oneOf:
> - enum:
> - mediatek,mt7623-rng
> + - mediatek,mt7981-rng
> - items:
> - enum:
> - mediatek,mt7622-rng
> @@ -25,6 +26,11 @@ properties:
> - mediatek,mt8365-rng
> - mediatek,mt8516-rng
> - const: mediatek,mt7623-rng
> + - items:
> + - enum:
> + - mediatek,mt7987-rng
> + - mediatek,mt7988-rng
> + - const: mediatek,mt7981-rng
>
> reg:
> maxItems: 1
> @@ -38,9 +44,19 @@ properties:
>
> required:
> - compatible
> - - reg
> - - clocks
> - - clock-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + not:
As requested last time - drop
> + contains:
> + const: mediatek,mt7981-rng
> + then:
missing constraints for mediatek,mt7981-rng. So does it have IO space
and clocks or not?
> + required:
> + - reg
> + - clocks
> + - clock-names
>
> additionalProperties: false
>
> @@ -53,3 +69,7 @@ examples:
> clocks = <&infracfg CLK_INFRA_TRNG>;
> clock-names = "rng";
> };
> + - |
> + rng {
> + compatible = "mediatek,mt7981-rng";
No improvements.
Also, make the example complete since binding claims you have clocks and
reg.
I am not sure it should be even same file, but if you are making it same
file, then make it correct.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Alex Bereza @ 2026-04-02 7:46 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza,
Suraj Gupta, Frank Li
In-Reply-To: <20260402-fix-atomic-poll-timeout-regression-v4-0-f30d6a6c13cb@bereza.email>
Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a
condition that is never fulfilled, the CPU busy-waits for prolonged time
and the timeout triggers only with a massive delay causing a CPU stall.
This happens due to a huge underestimation of wall clock time in
poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use
timekeeping in read_poll_timeout_atomic()") changed the behavior to no
longer use ktime_get at the expense of underestimation of wall clock
time which appears to be very large for delay_us=0. Instead of timing
out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout
takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for
loop in poll_timeout_us_atomic takes) which is in the range of several
minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero
value for delay_us. Use delay_us=10 to keep the delay in the hot path of
starting DMA transfers minimal but still avoid CPU stalls in case of
unexpected hardware failures.
One-off measurement with delay_us=0 causes the cpu to busy wait around 7
minutes in the timeout case. After applying this patch with delay_us=10
the measured timeout was 1053428 microseconds which is roughly
equivalent to the expected 1000000 microseconds specified in
XILINX_DMA_LOOP_COUNT.
Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's")
Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Bereza <alex@bereza.email>
---
drivers/dma/xilinx/xilinx_dma.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 02a05f215614..345a738bab2c 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -167,6 +167,8 @@
/* Delay loop counter to prevent hardware failure */
#define XILINX_DMA_LOOP_COUNT 1000000
+/* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
+#define XILINX_DMA_POLL_DELAY_US 10
/* AXI DMA Specific Registers/Offsets */
#define XILINX_DMA_REG_SRCDSTADDR 0x18
@@ -1332,7 +1334,8 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
/* Wait for the hardware to halt */
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
- val & XILINX_DMA_DMASR_HALTED, 0,
+ val & XILINX_DMA_DMASR_HALTED,
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
}
@@ -1347,7 +1350,8 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
u32 val;
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
- val & XILINX_DMA_DMASR_IDLE, 0,
+ val & XILINX_DMA_DMASR_IDLE,
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
}
@@ -1364,7 +1368,8 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
/* Wait for the hardware to start */
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
- !(val & XILINX_DMA_DMASR_HALTED), 0,
+ !(val & XILINX_DMA_DMASR_HALTED),
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
if (err) {
@@ -1780,7 +1785,8 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
/* Wait for the hardware to finish reset */
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
- !(tmp & XILINX_DMA_DMACR_RESET), 0,
+ !(tmp & XILINX_DMA_DMACR_RESET),
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
if (err) {
--
2.53.0
^ permalink raw reply related
* RE: Re: [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-02 7:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260402-axiomatic-ludicrous-panther-7a96d2@quoll>
> On Wed, Apr 01, 2026 at 06:19:12PM +0800, Guangliu Ding wrote:
> > The GPU instance used on NXP i.MX952 is the Mali‑G310, document
> > support for this variant.
> >
> > A hardware GPU auto clock‑gating mechanism has been introduced,
> > enabling GPUMIX to automatically manage the GPU clock. This improves
> > overall response time.
> >
> > Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > ---
> > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> Why are you sending next version when the discussion is happening?
>
I will drop this thread and raise v3 version with final fix. Sorry for inconvenience.
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v4 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Alex Bereza @ 2026-04-02 7:46 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza,
Suraj Gupta, Frank Li
Signed-off-by: Alex Bereza <alex@bereza.email>
---
Changes in v4:
- patch 1/2: nothing
- patch 2/2:
- Fix commit message: reword as suggested by Frank Li
<Frank.Li@nxp.com> - thanks!
- Link to v3: https://patch.msgid.link/20260401-fix-atomic-poll-timeout-regression-v3-0-85508f0aedde@bereza.email
Changes in v3:
- patch 1/2:
- Fix commit message: remove blank line between tags
- patch 2/2: nothing
- Link to v2: https://patch.msgid.link/20260401-fix-atomic-poll-timeout-regression-v2-0-68a265e3770f@bereza.email
Changes in v2:
- Fixed the Fixes: tags as suggested by Geert Uytterhoeven
<geert+renesas@glider.be> - thanks!
- Split the renaming of XILINX_DMA_LOOP_COUNT into separate commit
- Link to v1: https://patch.msgid.link/20260331-fix-atomic-poll-timeout-regression-v1-1-5b7bd96eaca0@bereza.email
---
Alex Bereza (2):
dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
drivers/dma/xilinx/xilinx_dma.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
---
base-commit: b7560798466a07d9c3fb011698e92c335ab28baf
change-id: 20260330-fix-atomic-poll-timeout-regression-4f4e3baf3fd7
Best regards,
--
Alex Bereza <alex@bereza.email>
^ permalink raw reply
* [PATCH v4 2/2] dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
From: Alex Bereza @ 2026-04-02 7:46 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza,
Suraj Gupta
In-Reply-To: <20260402-fix-atomic-poll-timeout-regression-v4-0-f30d6a6c13cb@bereza.email>
Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because it is
a timeout value, not a loop count for polling register in microseconds.
No functional changes.
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Signed-off-by: Alex Bereza <alex@bereza.email>
---
drivers/dma/xilinx/xilinx_dma.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 345a738bab2c..253c27fd1a0e 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -165,8 +165,8 @@
#define XILINX_DMA_FLUSH_MM2S 2
#define XILINX_DMA_FLUSH_BOTH 1
-/* Delay loop counter to prevent hardware failure */
-#define XILINX_DMA_LOOP_COUNT 1000000
+/* Timeout for polling various registers */
+#define XILINX_DMA_POLL_TIMEOUT_US 1000000
/* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
#define XILINX_DMA_POLL_DELAY_US 10
@@ -1336,7 +1336,7 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
val & XILINX_DMA_DMASR_HALTED,
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
}
/**
@@ -1352,7 +1352,7 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
val & XILINX_DMA_DMASR_IDLE,
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
}
/**
@@ -1370,7 +1370,7 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
!(val & XILINX_DMA_DMASR_HALTED),
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
if (err) {
dev_err(chan->dev, "Cannot start channel %p: %x\n",
@@ -1787,7 +1787,7 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
!(tmp & XILINX_DMA_DMACR_RESET),
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
if (err) {
dev_err(chan->dev, "reset timeout, cr %x, sr %x\n",
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/6] dt-bindings: opp: ti-cpu: Add ti,soc-info property
From: Krzysztof Kozlowski @ 2026-04-02 7:39 UTC (permalink / raw)
To: Akashdeep Kaur
Cc: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole, vishalm, sebin.francis, k-willis
In-Reply-To: <20260401105404.1194717-3-a-kaur@ti.com>
On Wed, Apr 01, 2026 at 04:24:00PM +0530, Akashdeep Kaur wrote:
> Add ti,soc-info property to allow OPP tables to reference the SoC info
> device (chipid) for establishing device link dependencies.
>
> This is used on K3 SoCs (AM625, AM62A7, AM62L3, AM62P5) to ensure proper
> probe ordering between ti-cpufreq and k3-socinfo drivers. The ti-cpufreq
Nope, sorry, DT purpose is not to perform probe ordering.
If I change Linux to load k3-socinfo before ti-cpufreq, then the binding
becomes invalid?
Not a DT property, drop.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-02 7:38 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, dri-devel, devicetree,
linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260401-master-v2-1-20d3fbcd19d6@nxp.com>
On Wed, Apr 01, 2026 at 06:19:12PM +0800, Guangliu Ding wrote:
> The GPU instance used on NXP i.MX952 is the Mali‑G310,
> document support for this variant.
>
> A hardware GPU auto clock‑gating mechanism has been introduced,
> enabling GPUMIX to automatically manage the GPU clock. This improves
> overall response time.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> 1 file changed, 1 insertion(+)
Why are you sending next version when the discussion is happening?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:28 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <b9d6a9322ce4f7dc3363dc00d93ab0256e12a8af.1775045279.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:25:21PM +0200, Nora Schiffer wrote:
> The J722S WIZ is mostly identical to the AM64's, but additionally supports
> SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> index 3f16ff14484d2..283e3eedc0f31 100644
> --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> @@ -12,13 +12,19 @@ maintainers:
>
> properties:
> compatible:
> - enum:
> - - ti,j721e-wiz-16g
> - - ti,j721e-wiz-10g
> - - ti,j721s2-wiz-10g
> - - ti,am64-wiz-10g
> - - ti,j7200-wiz-10g
> - - ti,j784s4-wiz-10g
> + oneOf:
> + - items:
Same comments as for netdev patch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:27 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <5ac1c52827a1a246584dddb62335f9ce4715eceb.1775045279.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:25:22PM +0200, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> index be41b4547ec6d..6e12a75100eb8 100644
> --- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> @@ -47,15 +47,21 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - ti,am3352-phy-gmii-sel
> - - ti,dra7xx-phy-gmii-sel
> - - ti,am43xx-phy-gmii-sel
> - - ti,dm814-phy-gmii-sel
> - - ti,am654-phy-gmii-sel
> - - ti,j7200-cpsw5g-phy-gmii-sel
> - - ti,j721e-cpsw9g-phy-gmii-sel
> - - ti,j784s4-cpsw9g-phy-gmii-sel
> + oneOf:
> + - items:
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:26 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux
In-Reply-To: <e7ec1b928357d1240a962a88dc6ac67fd2c92357.1774958552.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:05:42PM +0200, Nora Schiffer wrote:
> The J722S CPSW3G is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
>
> v2: keep ti,am642-cpsw-nuss as a fallback
> v3: resubmission for net-next, no changes
>
> .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> index a959c1d7e643a..70d25f5ff1cfe 100644
> --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> @@ -53,13 +53,19 @@ properties:
> "#size-cells": true
>
> compatible:
> - enum:
> - - ti,am642-cpsw-nuss
> - - ti,am654-cpsw-nuss
> - - ti,j7200-cpswxg-nuss
> - - ti,j721e-cpsw-nuss
> - - ti,j721e-cpswxg-nuss
> - - ti,j784s4-cpswxg-nuss
> + oneOf:
> + - items:
s/items/enum/. No need to make it a list, wasn't list before. It is not
making code more readable.
> + - enum:
> + - ti,am642-cpsw-nuss
> + - ti,am654-cpsw-nuss
> + - ti,j7200-cpswxg-nuss
> + - ti,j721e-cpsw-nuss
> + - ti,j721e-cpswxg-nuss
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:17 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
I forgot:
Filename must match compatible.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:16 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
You just repeated the diff. No need, we can read the diff, but what we
cannot read is the hardware you are here describing.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
So you did not test v1. You did not test v2.
Did you finally test this one before sending?
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
>
> diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> new file mode 100644
> index 000000000000..fa757017d66e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell CN20K DDR performance monitor
> +
> +description:
> + Performance Monitoring Unit (PMU) for the DDR controller
> + in Marvell CN20K SoCs.
> +
> +maintainers:
> + - Geetha sowjanya <gakula@marvell.com>
> +
> +properties:
> + compatible:
> + const: marvell,cn20k-ddr-pmu
There is no such thing as marvell,cn20k in upstream. What's that?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Maulik Shah (mkshah) @ 2026-04-02 7:15 UTC (permalink / raw)
To: Bjorn Andersson, Manivannan Sadhasivam
Cc: mark.rutland, lpieralisi, bjorn.andersson, konrad.dybcio, mani,
linux-arm-kernel, linux-kernel, Konrad Dybcio, Konrad Dybcio,
Sudeep Holla, linux-arm-msm
In-Reply-To: <acrdFfk8al80dynq@baldur>
On 3/31/2026 2:18 AM, Bjorn Andersson wrote:
> On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
>> From: Konrad Dybcio <konradybcio@kernel.org>
>>
>> PSCI specification defines the SYSTEM_SUSPEND feature which enables the
>> firmware to implement the suspend to RAM (S2RAM) functionality by
>> transitioning the system to a deeper low power state. When the system
>> enters such state, the power to the peripheral devices might be removed.
>
> What is the actual extent of "peripheral devices" in this definition?
>
>> So
>> the respective device drivers must prepare for the possible removal of the
>> power by performing actions such as shutting down or resetting the device
>> in their system suspend callbacks.
>>
>
> Our typical interpretation of this state is that IP-blocks might be
> non-functional during this time, but typically some state is retained.
>
> Will the acceptance of this patch result in that we in the Qualcomm case
> should start accepting/writing patches that implement save/restore of
> state that is generally retained throughout the drivers - in the name of
> "power might be removed"?
>
>> The Linux PM framework allows the platform drivers to convey this info to
>> device drivers by calling the pm_set_suspend_via_firmware() and
>> pm_set_resume_via_firmware() APIs.
>>
>> Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
>> mentioned APIs in the psci_system_suspend_begin() and
>> psci_system_suspend_enter() callbacks.
>>
>
> With the right interpretation of what this means for us, I think this
> patch looks good - but as we've discussed, I'm a bit worried about how
> to deal with the alternative interpretations.
>
> Specifically, if we fully adopt "power might be removed", we should to
> take actions which will prevent a typical Qualcomm system from waking up
> from sleep again.
The "power might be removed" not necessarily indicate that devices/ peripherals
should remove the wake up capability of interrupts in order to prevent waking up
from sleep.
The hibernation + suspend-to-ram is one such example, where "power might
be removed" but devices may still leave the wake up interrupts enabled.
Pasting from commit 62c552ccc3ed ("PM / Hibernate: Enable suspend to both for in-kernel hibernation.")
| It is often useful to suspend to memory after hibernation image has been
| written to disk. If the battery runs out or power is otherwise lost, the
| computer will resume from the hibernated image. If not, it will resume
| from memory
Which can be interpreted as wake up interrupt should be able to wake from suspend-to-ram state
"to the point until the power is cut off or battery runs out".
And in order to do so, wake up capable interrupts should be left enabled in HW,
for interrupt controllers like GIC (and PDC in Qualcomm SoC cases) to support wake up.
Adding Cc: linux-arm-msm for better visibility.
Thanks,
Maulik
>
> Regards,
> Bjorn
>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>> [mani: reworded the description to be more elaborative]
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>> ---
>>
>> This patch was part of an old series that didn't make it to mainline due to
>> objections in the binding and exposing CPU_SUSPEND as S2RAM patches:
>> https://lore.kernel.org/all/20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com/
>>
>> But this patch on its own is useful for platforms implementing the S2RAM
>> feature in PSCI firmware. So I picked it up, tested on Qcom X1E T14s and
>> resending it.
>>
>> drivers/firmware/psci/psci.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
>> index 38ca190d4a22..e73bae6cb23a 100644
>> --- a/drivers/firmware/psci/psci.c
>> +++ b/drivers/firmware/psci/psci.c
>> @@ -539,12 +539,22 @@ static int psci_system_suspend(unsigned long unused)
>>
>> static int psci_system_suspend_enter(suspend_state_t state)
>> {
>> + pm_set_resume_via_firmware();
>> +
>> return cpu_suspend(0, psci_system_suspend);
>> }
>>
>> +static int psci_system_suspend_begin(suspend_state_t state)
>> +{
>> + pm_set_suspend_via_firmware();
>> +
>> + return 0;
>> +}
>> +
>> static const struct platform_suspend_ops psci_suspend_ops = {
>> .valid = suspend_valid_only_mem,
>> .enter = psci_system_suspend_enter,
>> + .begin = psci_system_suspend_begin,
>> };
>>
>> static void __init psci_init_system_reset2(void)
>> --
>> 2.48.1
>>
>
^ permalink raw reply
* Re: [PATCH 15/33] rust: rust_is_available: remove warning for 0.66.[01] buggy versions
From: Miguel Ojeda @ 2026-04-02 7:12 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <DHHWO582XLXH.1DU3CO41F1PV7@garyguo.net>
On Wed, Apr 1, 2026 at 4:58 PM Gary Guo <gary@garyguo.net> wrote:
>
> The scripts/rust_is_available.sh change looks correct to me, although I couldn't
> get scripts/rust_is_available_test.py to run on NixOS.
>
> Looks like it filtered out PATH but uses /usr/bin/env to find python binary? For
> obvious reasons that will only work if python is located /usr/bin/python.
Yeah, the script has some assumptions on it (e.g. it also assumes
`dash` behavior vs. `bash` in a couple tests which I should relax
too). Happy to change that.
Thanks for testing it :)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Ankur Arora @ 2026-04-02 7:01 UTC (permalink / raw)
To: Ankur Arora
Cc: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, bpf, arnd,
catalin.marinas, will, peterz, akpm, mark.rutland, harisokn, cl,
ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, joao.m.martins, boris.ostrovsky,
konrad.wilk
In-Reply-To: <20260316013651.3225328-1-ankur.a.arora@oracle.com>
Ankur Arora <ankur.a.arora@oracle.com> writes:
> Hi,
>
> This series adds waited variants of the smp_cond_load() primitives:
> smp_cond_load_relaxed_timeout(), and smp_cond_load_acquire_timeout().
>
> With this version, the main remaining things are:
>
> - Review by PeterZ of the new interface tif_need_resched_relaxed_wait()
> (patch 11, "sched: add need-resched timed wait interface").
>
> - Review of the BPF changes. This version simplifies the rqspinlock
> changes by reusing the original error handling path
> (patches 9, 10 "bpf/rqspinlock: switch check_timeout() to a clock
> interface", "bpf/rqspinlock: Use smp_cond_load_acquire_timeout()").
>
> - Review of WFET handling. (patch 4, "arm64: support WFET in
> smp_cond_load_relaxed_timeout()").
Received Acks/R-bys for the two above.
Will send out an updated v11 which adds a testcase and a comment
mentioning that smp_cond_load_*_timeout on MMIO addresses might
break in interesting platform specific ways.
Thanks
Ankur
> The new interfaces are meant for contexts where you want to wait on a
> condition variable for a finite duration. This is easy enough to do with
> a loop around cpu_relax(). There are, however, architectures (ex. arm64)
> that allow waiting on a cacheline instead.
>
> So, these interfaces handle a mixture of spin/wait with a
> smp_cond_load() thrown in. The interfaces are:
>
> smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, timeout)
> smp_cond_load_acquire_timeout(ptr, cond_expr, time_expr, timeout)
>
> The parameters, time_expr, timeout determine when to bail out.
>
> Also add tif_need_resched_relaxed_wait() which wraps the pattern used
> in poll_idle() and abstracts out details of the interface and those
> of the scheduler.
>
> In addition add atomic_cond_read_*_timeout(), atomic64_cond_read_*_timeout(),
> and atomic_long wrappers to the interfaces.
>
> Finally update poll_idle() and resilient queued spinlocks to use them.
>
> Changelog:
> v9 [9]:
> - s/@cond/@cond_expr/ (Randy Dunlap)
> - Clarify that SMP_TIMEOUT_POLL_COUNT is only around memory
> addresses. (David Laight)
> - Add the missing config ARCH_HAS_CPU_RELAX in arch/arm64/Kconfig.
> (Catalin Marinas).
> - Switch to arch_counter_get_cntvct_stable() (via __delay_cycles())
> in the cmpwait path instead of using arch_timer_read_counter().
> (Catalin Marinas)
>
> v8 [0]:
> - Defer evaluation of @time_expr_ns to when we hit the slowpath.
> (comment from Alexei Starovoitov).
>
> - Mention that cpu_poll_relax() is better than raw CPU polling
> only where ARCH_HAS_CPU_RELAX is defined.
> - also define ARCH_HAS_CPU_RELAX for arm64.
> (Came out of a discussion with Will Deacon.)
>
> - Split out WFET and WFE handling. I was doing both of these
> in a common handler.
> (From Will Deacon and in an earlier revision by Catalin Marinas.)
>
> - Add mentions of atomic_cond_read_{relaxed,acquire}(),
> atomic_cond_read_{relaxed,acquire}_timeout() in
> Documentation/atomic_t.txt.
>
> - Use the BIT() macro to do the checking in tif_bitset_relaxed_wait().
>
> - Cleanup unnecessary assignments, casts etc in poll_idle().
> (From Rafael Wysocki.)
>
> - Fixup warnings from kernel build robot
>
>
> v7 [1]:
> - change the interface to separately provide the timeout. This is
> useful for supporting WFET and similar primitives which can do
> timed waiting (suggested by Arnd Bergmann).
>
> - Adapting rqspinlock code to this changed interface also
> necessitated allowing time_expr to fail.
> - rqspinlock changes to adapt to the new smp_cond_load_acquire_timeout().
>
> - add WFET support (suggested by Arnd Bergmann).
> - add support for atomic-long wrappers.
> - add a new scheduler interface tif_need_resched_relaxed_wait() which
> encapsulates the polling logic used by poll_idle().
> - interface suggested by (Rafael J. Wysocki).
>
>
> v6 [2]:
> - fixup missing timeout parameters in atomic64_cond_read_*_timeout()
> - remove a race between setting of TIF_NEED_RESCHED and the call to
> smp_cond_load_relaxed_timeout(). This would mean that dev->poll_time_limit
> would be set even if we hadn't spent any time waiting.
> (The original check compared against local_clock(), which would have been
> fine, but I was instead using a cheaper check against _TIF_NEED_RESCHED.)
> (Both from meta-CI bot)
>
>
> v5 [3]:
> - use cpu_poll_relax() instead of cpu_relax().
> - instead of defining an arm64 specific
> smp_cond_load_relaxed_timeout(), just define the appropriate
> cpu_poll_relax().
> - re-read the target pointer when we exit due to the time-check.
> - s/SMP_TIMEOUT_SPIN_COUNT/SMP_TIMEOUT_POLL_COUNT/
> (Suggested by Will Deacon)
>
> - add atomic_cond_read_*_timeout() and atomic64_cond_read_*_timeout()
> interfaces.
> - rqspinlock: use atomic_cond_read_acquire_timeout().
> - cpuidle: use smp_cond_load_relaxed_tiemout() for polling.
> (Suggested by Catalin Marinas)
>
> - rqspinlock: define SMP_TIMEOUT_POLL_COUNT to be 16k for non arm64
>
>
> v4 [4]:
> - naming change 's/timewait/timeout/'
> - resilient spinlocks: get rid of res_smp_cond_load_acquire_waiting()
> and fixup use of RES_CHECK_TIMEOUT().
> (Both suggested by Catalin Marinas)
>
> v3 [5]:
> - further interface simplifications (suggested by Catalin Marinas)
>
> v2 [6]:
> - simplified the interface (suggested by Catalin Marinas)
> - get rid of wait_policy, and a multitude of constants
> - adds a slack parameter
> This helped remove a fair amount of duplicated code duplication and in
> hindsight unnecessary constants.
>
> v1 [7]:
> - add wait_policy (coarse and fine)
> - derive spin-count etc at runtime instead of using arbitrary
> constants.
>
> Haris Okanovic tested v4 of this series with poll_idle()/haltpoll patches. [8]
>
> Comments appreciated!
>
> Thanks
> Ankur
>
> [0] https://lore.kernel.org/lkml/20251215044919.460086-1-ankur.a.arora@oracle.com/
> [1] https://lore.kernel.org/lkml/20251028053136.692462-1-ankur.a.arora@oracle.com/
> [2] https://lore.kernel.org/lkml/20250911034655.3916002-1-ankur.a.arora@oracle.com/
> [3] https://lore.kernel.org/lkml/20250911034655.3916002-1-ankur.a.arora@oracle.com/
> [4] https://lore.kernel.org/lkml/20250829080735.3598416-1-ankur.a.arora@oracle.com/
> [5] https://lore.kernel.org/lkml/20250627044805.945491-1-ankur.a.arora@oracle.com/
> [6] https://lore.kernel.org/lkml/20250502085223.1316925-1-ankur.a.arora@oracle.com/
> [7] https://lore.kernel.org/lkml/20250203214911.898276-1-ankur.a.arora@oracle.com/
> [8] https://lore.kernel.org/lkml/2cecbf7fb23ee83a4ce027e1be3f46f97efd585c.camel@amazon.com/
> [9] https://lore.kernel.org/lkml/20260209023153.2661784-1-ankur.a.arora@oracle.com/
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: bpf@vger.kernel.org
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-pm@vger.kernel.org
>
> Ankur Arora (12):
> asm-generic: barrier: Add smp_cond_load_relaxed_timeout()
> arm64: barrier: Support smp_cond_load_relaxed_timeout()
> arm64/delay: move some constants out to a separate header
> arm64: support WFET in smp_cond_load_relaxed_timeout()
> arm64: rqspinlock: Remove private copy of
> smp_cond_load_acquire_timewait()
> asm-generic: barrier: Add smp_cond_load_acquire_timeout()
> atomic: Add atomic_cond_read_*_timeout()
> locking/atomic: scripts: build atomic_long_cond_read_*_timeout()
> bpf/rqspinlock: switch check_timeout() to a clock interface
> bpf/rqspinlock: Use smp_cond_load_acquire_timeout()
> sched: add need-resched timed wait interface
> cpuidle/poll_state: Wait for need-resched via
> tif_need_resched_relaxed_wait()
>
> Documentation/atomic_t.txt | 14 +++--
> arch/arm64/Kconfig | 3 +
> arch/arm64/include/asm/barrier.h | 23 +++++++
> arch/arm64/include/asm/cmpxchg.h | 62 +++++++++++++++----
> arch/arm64/include/asm/delay-const.h | 27 +++++++++
> arch/arm64/include/asm/rqspinlock.h | 85 --------------------------
> arch/arm64/lib/delay.c | 15 ++---
> drivers/cpuidle/poll_state.c | 21 +------
> drivers/soc/qcom/rpmh-rsc.c | 8 +--
> include/asm-generic/barrier.h | 90 ++++++++++++++++++++++++++++
> include/linux/atomic.h | 10 ++++
> include/linux/atomic/atomic-long.h | 18 +++---
> include/linux/sched/idle.h | 29 +++++++++
> kernel/bpf/rqspinlock.c | 77 +++++++++++++++---------
> scripts/atomic/gen-atomic-long.sh | 16 +++--
> 15 files changed, 320 insertions(+), 178 deletions(-)
> create mode 100644 arch/arm64/include/asm/delay-const.h
--
ankur
^ permalink raw reply
* Re: [PATCH v12 0/7] i2c: xiic: use generic device property accessors
From: Abdurrahman Hussain @ 2026-04-02 7:01 UTC (permalink / raw)
To: Andi Shyti, abdurrahman
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Shevchenko, linux-arm-kernel, linux-i2c, linux-kernel,
devicetree, Andrew Lunn, Jonathan Cameron
In-Reply-To: <ac2r9m9mSMZxgHwN@zenone.zhora.eu>
On Wed Apr 1, 2026 at 4:41 PM PDT, Andi Shyti wrote:
>> Abdurrahman Hussain (7):
>> i2c: xiic: switch to devres managed APIs
>> i2c: xiic: remove duplicate error message
>> i2c: xiic: switch to generic device property accessors
>> i2c: xiic: cosmetic cleanup
>> i2c: xiic: cosmetic: use resource format specifier in debug log
>> i2c: xiic: use numbered adapter registration
>> i2c: xiic: skip input clock setup on non-OF systems
>
> Good job Abdurrahman, thanks for following up in all the rounds
> of reviews. I finally merged your patch in i2c/i2c-host.
>
> Thanks,
> Andi
Thank you for merging the changes, Andi. I would also like to express my
appreciation to all reviewers for their valuable feedback and patience
throughout the review process.
Best regards,
Abdurrahman
^ permalink raw reply
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Krzysztof Kozlowski @ 2026-04-02 6:43 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <DHIB5E66SP7A.110YA5R1OOQHS@linaro.org>
On 02/04/2026 04:19, Alexey Klimov wrote:
> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>> Hi all,
>>>
>>> This patch series introduces support for the APM-to-AP mailbox on the
>>> Exynos850 SoC. This mailbox is required for communicating with the APM
>>> co-processor using ACPM.
>>>
>>> The Exynos850 mailbox operates similarly to the existing gs101
>>> implementation, but the register offsets and IRQ mask bits differ.
>>> This series abstracts these differences into platform-specific data
>>> structures matched via the device tree.
>>>
>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>
>>> In theory this can be split into two series with correct dependecies:
>>> device tree node requires clock changes to be merged. The suggestion
>>> is to let this go through Samsung SoC tree with corresponding acks
>>> if it is okay.
>>
>> I don't understand why this cannot be split into two seris
>> *practically*. What is exactly the dependency between mailbox and DTS,
>> that it had to be combined here?
>
> Do you suggest to send 3 single patches with proper dependencies
> description? DT bindings change first, then mailbox change that specifically
> depends on dt-bindings change and then dts update (which will depend on both)?
>
> I thought that mbox driver change depends implicitly on bindings update?
Please don't answer to a question with a question. Actually three
questions. If you cannot give argument why there is a dependency, feels
to me like you send something you do not understand.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 23/27] clk: mediatek: Add MT8196 disp-ao clock support
From: Jason-JH Lin (林睿祥) @ 2026-04-02 6:30 UTC (permalink / raw)
To: sboyd@kernel.org, robh@kernel.org, Laura Nao, krzk+dt@kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
conor+dt@kernel.org, richardcochran@gmail.com,
matthias.bgg@gmail.com, AngeloGioacchino Del Regno
Cc: Guangjie Song (宋光杰), kernel@collabora.com,
Sirius Wang (王皓昱),
Nancy Lin (林欣螢),
linux-kernel@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Paul-pl Chen (陳柏霖),
linux-mediatek@lists.infradead.org,
Jason-JH Lin (林睿祥),
devicetree@vger.kernel.org, Nicolas Prado,
Singo Chang (張興國), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20250829091913.131528-24-laura.nao@collabora.com>
On Fri, 2025-08-29 at 11:19 +0200, Laura Nao wrote:
> Add support for the MT8196 disp-ao clock controller, which provides
> clock gate control for the display system. It is integrated with the
> mtk-mmsys driver, which registers the disp-ao clock driver via
> platform_device_register_data().
>
> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Laura Nao <laura.nao@collabora.com>
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-mt8196-vdisp_ao.c | 80
> ++++++++++++++++++++++
> 2 files changed, 81 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
>
> diff --git a/drivers/clk/mediatek/Makefile
> b/drivers/clk/mediatek/Makefile
> index fe5699411d8b..5b8969ff1985 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -157,7 +157,7 @@ obj-$(CONFIG_COMMON_CLK_MT8196_IMP_IIC_WRAP) +=
> clk-mt8196-imp_iic_wrap.o
> obj-$(CONFIG_COMMON_CLK_MT8196_MCUSYS) += clk-mt8196-mcu.o
> obj-$(CONFIG_COMMON_CLK_MT8196_MDPSYS) += clk-mt8196-mdpsys.o
> obj-$(CONFIG_COMMON_CLK_MT8196_MFGCFG) += clk-mt8196-mfg.o
> -obj-$(CONFIG_COMMON_CLK_MT8196_MMSYS) += clk-mt8196-disp0.o clk-
> mt8196-disp1.o
> +obj-$(CONFIG_COMMON_CLK_MT8196_MMSYS) += clk-mt8196-disp0.o clk-
> mt8196-disp1.o clk-mt8196-vdisp_ao.o
> obj-$(CONFIG_COMMON_CLK_MT8196_PEXTPSYS) += clk-mt8196-pextp.o
> obj-$(CONFIG_COMMON_CLK_MT8196_UFSSYS) += clk-mt8196-ufs_ao.o
> obj-$(CONFIG_COMMON_CLK_MT8365) += clk-mt8365-apmixedsys.o clk-
> mt8365.o
> diff --git a/drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
> b/drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
> new file mode 100644
> index 000000000000..fddb69d1c3eb
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
> @@ -0,0 +1,80 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2025 MediaTek Inc.
> + * Guangjie Song <guangjie.song@mediatek.com>
> + * Copyright (c) 2025 Collabora Ltd.
> + * Laura Nao <laura.nao@collabora.com>
> + */
> +#include <dt-bindings/clock/mediatek,mt8196-clock.h>
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +
> +#include "clk-gate.h"
> +#include "clk-mtk.h"
> +
> +static const struct mtk_gate_regs mm_v_cg_regs = {
> + .set_ofs = 0x104,
> + .clr_ofs = 0x108,
> + .sta_ofs = 0x100,
> +};
> +
> +static const struct mtk_gate_regs mm_v_hwv_regs = {
> + .set_ofs = 0x0030,
> + .clr_ofs = 0x0034,
> + .sta_ofs = 0x2c18,
> +};
> +
> +#define GATE_MM_AO_V(_id, _name, _parent, _shift) { \
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm_v_cg_regs, \
> + .shift = _shift, \
> + .ops = &mtk_clk_gate_ops_setclr, \
> + .flags = CLK_OPS_PARENT_ENABLE | \
> + CLK_IS_CRITICAL, \
> + }
> +
> +#define GATE_HWV_MM_V(_id, _name, _parent, _shift) { \
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm_v_cg_regs, \
> + .hwv_regs = &mm_v_hwv_regs, \
> + .shift = _shift, \
> + .ops = &mtk_clk_gate_hwv_ops_setclr, \
> + .flags = CLK_OPS_PARENT_ENABLE, \
> + }
> +
> +static const struct mtk_gate mm_v_clks[] = {
> + GATE_HWV_MM_V(CLK_MM_V_DISP_VDISP_AO_CONFIG,
> "mm_v_disp_vdisp_ao_config", "disp", 0),
> + GATE_HWV_MM_V(CLK_MM_V_DISP_DPC, "mm_v_disp_dpc", "disp",
> 16),
> + GATE_MM_AO_V(CLK_MM_V_SMI_SUB_SOMM0, "mm_v_smi_sub_somm0",
> "disp", 2),
> +};
> +
> +static const struct mtk_clk_desc mm_v_mcd = {
> + .clks = mm_v_clks,
> + .num_clks = ARRAY_SIZE(mm_v_clks),
> +};
> +
> +static const struct of_device_id of_match_clk_mt8196_vdisp_ao[] = {
> + { .compatible = "mediatek,mt8196-vdisp-ao", .data =
> &mm_v_mcd },
Hi Laura,
We are going to send mtk-mmsys driver for MT8196 recently, but we found
the compatible name is used here.
As your commit message, vdisp-ao is integrated with the mtk-mmsys
driver, which registers the vdisp-ao clock driver via
platform_device_register_data().
Shouldn't this compatible name belong to mmsys driver for MT8196?
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, of_match_clk_mt8196_vdisp_ao);
> +
> +static struct platform_driver clk_mt8196_vdisp_ao_drv = {
> + .probe = mtk_clk_pdev_probe,
> + .remove = mtk_clk_pdev_remove,
> + .driver = {
> + .name = "clk-mt8196-vdisp-ao",
> + .of_match_table = of_match_clk_mt8196_vdisp_ao,
In clk-mt8196-ovl0/ovl1/disp0/disp1.c, they use `.id_table` instead of
`.of_match_table` here. Shouldn't this align to them?
Regards,
Jason-JH Lin
> + },
> +};
> +module_platform_driver(clk_mt8196_vdisp_ao_drv);
> +
> +MODULE_DESCRIPTION("MediaTek MT8196 vdisp_ao clocks driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v20 01/10] power: reset: reboot-mode: Remove devres based allocations
From: Shivendra Pratap @ 2026-04-02 6:15 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lorenzo Pieralisi, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla
Cc: Florian Fainelli, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Kathiravan Thirumoorthy, linux-pm, linux-kernel, linux-arm-kernel,
linux-arm-msm, devicetree, Srinivas Kandagatla
In-Reply-To: <be9db30a-ee64-4457-8722-b9f456911ad3@kernel.org>
On 01-04-2026 20:49, Krzysztof Kozlowski wrote:
> On 04/03/2026 19:03, Shivendra Pratap wrote:
>> Devres APIs are intended for use in drivers, where the managed lifetime
>> of resources is tied directly to the driver attach/detach cycle. In
>> shared subsystem code, there is no guarantee that the subsystem
>> functions will only be called after a driver has been attached, nor that
>> they will not be referenced after the managed resources have been
>> released during driver detach.
>>
>> To ensure correct lifetime handling, avoid using devres-based
>> allocations in the reboot-mode and explicitly handle allocation and
>> cleanup of resources.
>>
>> Fixes: 4fcd504edbf7 ("power: reset: add reboot mode driver")
>
> I don't think this is correct tag.
>
> That commit added code which was a driver, not subsystem level things.
> Using devres, as you pointed out, in platform_driver is correct.
sure. thanks. will remove the Fixes tag.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v5 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
From: Billy Tsai @ 2026-04-02 6:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260401-adept-zebra-of-bloom-5bb68b@quoll>
> > AST2700 consists of two interconnected SoC instances, each with its own
> > System Control Unit (SCU). The SCU0 provides pin control, interrupt
> > controllers, clocks, resets, and address-space mappings for the
> > Secondary and Tertiary Service Processors (SSP and TSP).
> >
> > Describe the SSP/TSP address mappings using the standard
> > memory-region and memory-region-names properties.
> >
> > Disallow legacy child nodes that are not present on AST2700, including
> > p2a-control and smp-memram. The latter is unnecessary as software can
> > access the scratch registers via the SCU syscon.
> >
> > Also allow the AST2700 SoC0 pin controller to be described as a child
> > node of the SCU0, and add an example illustrating the SCU0 layout,
> > including reserved-memory, interrupt controllers, and pinctrl.
> >
> > Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> > ---
> > .../bindings/mfd/aspeed,ast2x00-scu.yaml | 117 +++++++++++++++++++++
> > 1 file changed, 117 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > index a87f31fce019..86d51389689c 100644
> > --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > @@ -46,6 +46,9 @@ properties:
> > '#reset-cells':
> > const: 1
> >
> > + memory-region: true
> > + memory-region-names: true
> Missing constraints. From where did you take such syntax (so I can fix
> it)?
The intention was to constrain these properties conditionally for
AST2700 SCU0 as done further down in the patch.
I can update the binding so that memory-region and memory-region-names
have baseline constraints (e.g. minItems and maxItems), and then refine them in the
conditional branches for AST2700SCU0, AST2700SCU1 and others
memory-region:
minItems: 2
maxItems: 3
memory-region-names:
minItems: 2
maxItems: 3
Best regards,
Billy Tsai
^ 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