* [PATCH V13 11/12] arm64: dts: imx8dxl/qm/qxp: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-16 11:14 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260416111422.183860-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
.../boot/dts/freescale/imx8-ss-hsio.dtsi | 11 ++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 5 +++++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 10 +++++++++
.../boot/dts/freescale/imx8qm-ss-hsio.dtsi | 22 +++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 5 +++++
5 files changed, 53 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi
index 469de8b536b5..009990b2e559 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi
@@ -78,6 +78,17 @@ pcieb: pcie@5f010000 {
power-domains = <&pd IMX_SC_R_PCIE_B>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcieb_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcieb_ep: pcie-ep@5f010000 {
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
index bc62ae5ca812..39108a915f96 100644
--- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
@@ -675,6 +675,7 @@ &pcie0 {
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pcieb>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcieb>;
vpcie3v3aux-supply = <®_pcieb>;
@@ -691,6 +692,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcieb_port0 {
+ reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+};
+
&sai0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai0>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
index 011a89d85961..f706c86137c0 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
@@ -810,6 +810,7 @@ &pciea {
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pciea>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pciea>;
vpcie3v3aux-supply = <®_pciea>;
@@ -817,15 +818,24 @@ &pciea {
status = "okay";
};
+&pciea_port0 {
+ reset-gpios = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
+};
+
&pcieb {
phys = <&hsio_phy 1 PHY_TYPE_PCIE 1>;
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pcieb>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio5 0 GPIO_ACTIVE_LOW>;
status = "disabled";
};
+&pcieb_port0 {
+ reset-gpios = <&lsio_gpio5 0 GPIO_ACTIVE_LOW>;
+};
+
&qm_pwm_lvds0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm_lvds0>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi
index f2c94cdb682b..2e4fbfe0ca16 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi
@@ -41,6 +41,17 @@ pcie0: pciea: pcie@5f000000 {
power-domains = <&pd IMX_SC_R_PCIE_A>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pciea_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pciea_ep: pcie-ep@5f000000 {
@@ -91,6 +102,17 @@ pcie1: pcieb: pcie@5f010000 {
power-domains = <&pd IMX_SC_R_PCIE_B>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcieb_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
sata: sata@5f020000 {
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 623169f7ddb5..489e174df4c4 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -730,6 +730,7 @@ &pcie0 {
phy-names = "pcie-phy";
pinctrl-0 = <&pinctrl_pcieb>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcieb>;
vpcie3v3aux-supply = <®_pcieb>;
@@ -746,6 +747,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcieb_port0 {
+ reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+};
+
&scu_key {
status = "okay";
};
--
2.37.1
^ permalink raw reply related
* [PATCH V13 12/12] arm64: dts: imx95: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-16 11:14 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260416111422.183860-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
.../boot/dts/freescale/imx95-15x15-evk.dts | 5 +++++
.../boot/dts/freescale/imx95-19x19-evk.dts | 10 +++++++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 22 +++++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
index e4649d7f9122..7d820a0f80b2 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
@@ -553,6 +553,7 @@ &netcmix_blk_ctrl {
&pcie0 {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio5 13 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_m2_pwr>;
vpcie3v3aux-supply = <®_m2_pwr>;
@@ -567,6 +568,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+};
+
&sai1 {
assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
<&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index 041fd838fabb..6f193cf04119 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -540,6 +540,7 @@ &netc_timer {
&pcie0 {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcie0>;
vpcie3v3aux-supply = <®_pcie0>;
@@ -554,9 +555,14 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
+};
+
&pcie1 {
pinctrl-0 = <&pinctrl_pcie1>;
pinctrl-names = "default";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_slot_pwr>;
vpcie3v3aux-supply = <®_slot_pwr>;
@@ -570,6 +576,10 @@ &pcie1_ep {
status = "disabled";
};
+&pcie1_port0 {
+ reset-gpios = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
+};
+
&sai1 {
#sound-dai-cells = <0>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 71394871d8dd..0cc6644f98bb 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1890,6 +1890,17 @@ pcie0: pcie@4c300000 {
iommu-map-mask = <0x1ff>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@4c300000 {
@@ -1967,6 +1978,17 @@ pcie1: pcie@4c380000 {
iommu-map-mask = <0x1ff>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie1_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie1_ep: pcie-ep@4c380000 {
--
2.37.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: rtc: ti,bq32k: Add delay on rtc reads
From: Adriana Nicolae @ 2026-04-16 11:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: alexandre.belloni, linux-rtc, devicetree, linux-kernel, robh,
krzk+dt, conor+dt
In-Reply-To: <89bb6063-d473-498e-bca5-0185325608c3@kernel.org>
On Thu, Apr 16, 2026 at 2:00 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/04/2026 11:57, Adriana Stancu wrote:
> > Add a configurable "ti,read-settle-us" property to resolve a limitation
> > where aggressive I2C polling prevents the BQ32000's internal register to
> > update. This ensures the hardware has sufficient idle time to update its
> > buffer, preventing stale data reads on systems where the "interrupts" are
> > not configured.
>
> And why does the value different between each board layouts? Same
> device, different board and you need different value?
>
> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). This buries them deep in the mailbox and might
> interfere with applying entire sets. See also:
> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
>
You are right, the delay should be specific to the RTC chip, not the
board layout. I will drop the dt property and send a v3 that
implements a fixed 2ms delay in the driver.
This will be applied only when an interrupt is not present, because
this is when the userspace will use polling.
Best regards,
Adriana
^ permalink raw reply
* [PATCH] arm64: dts: qcom: purwa-iot-evk: Update TSENS thermal zone
From: Gaurav Kohli @ 2026-04-16 11:34 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, manaf.pallikunhi,
Gaurav Kohli
Purwa IOT boards support a different thermal junction temperature
specification compared to the base Purwa platform due to package
level differences.
Update the passive trip thresholds to 105°C to align with the higher
temperature specification.
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 32 ++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
index ad503beec1d3..261d1e85651d 100644
--- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
@@ -1325,6 +1325,38 @@ right_tweeter: speaker@0,1 {
};
};
+&thermal_gpuss_0 {
+ trips {
+ trip-point0 {
+ temperature = <105000>;
+ };
+ };
+};
+
+&thermal_gpuss_1 {
+ trips {
+ trip-point0 {
+ temperature = <105000>;
+ };
+ };
+};
+
+&thermal_gpuss_2 {
+ trips {
+ trip-point0 {
+ temperature = <105000>;
+ };
+ };
+};
+
+&thermal_gpuss_3 {
+ trips {
+ trip-point0 {
+ temperature = <105000>;
+ };
+ };
+};
+
&tlmm {
edp_reg_en: edp-reg-en-state {
pins = "gpio70";
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260416-purwa_high_tj-5f87b7ed57c9
Best regards,
--
Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Anand Moon @ 2026-04-16 11:37 UTC (permalink / raw)
To: Shuwei Wu
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, linux-pm, linux-kernel, linux-riscv,
spacemit, devicetree
In-Reply-To: <DHUCL24GMX7D.369IWK9DLPZPX@mailbox.org>
Hi Shuwei,
Thanks for sharing the details.
On Thu, 16 Apr 2026 at 11:29, Shuwei Wu <shuwei.wu@mailbox.org> wrote:
>
> On Tue Apr 14, 2026 at 9:25 PM CST, Anand Moon wrote:
> > Hi Shuwei,
> >
> > On Fri, 10 Apr 2026 at 13:30, Shuwei Wu <shuwei.wu@mailbox.org> wrote:
> >>
> >> Add Operating Performance Points (OPP) tables and CPU clock properties
> >> for the two clusters in the SpacemiT K1 SoC.
> >>
> >> Also assign the CPU power supply (cpu-supply) for the Banana Pi BPI-F3
> >> board to fully enable CPU DVFS.
> >>
> >> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> >>
> >> ---
> >> Changes in v2:
> >> - Add k1-opp.dtsi with OPP tables for both CPU clusters
> >> - Assign CPU supplies and include OPP table for Banana Pi BPI-F3
> >> ---
> >> arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
> >> arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
> >> arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
> >> 3 files changed, 147 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> >> index 444c3b1e6f44..3780593f610d 100644
> >> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> >> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> >> @@ -5,6 +5,7 @@
> >>
> >> #include "k1.dtsi"
> >> #include "k1-pinctrl.dtsi"
> >> +#include "k1-opp.dtsi"
> >>
> >> / {
> >> model = "Banana Pi BPI-F3";
> >> @@ -86,6 +87,38 @@ &combo_phy {
> >> status = "okay";
> >> };
> >>
> >> +&cpu_0 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_1 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_2 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_3 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_4 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_5 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_6 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_7 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> &emmc {
> >> bus-width = <8>;
> >> mmc-hs400-1_8v;
> >> @@ -201,7 +234,7 @@ pmic@41 {
> >> dldoin2-supply = <&buck5>;
> >>
> >> regulators {
> >> - buck1 {
> >> + buck1_3v45: buck1 {
> >> regulator-min-microvolt = <500000>;
> >> regulator-max-microvolt = <3450000>;
> >> regulator-ramp-delay = <5000>;
> >> diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> >> new file mode 100644
> >> index 000000000000..768ae390686d
> >> --- /dev/null
> >> +++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> >> @@ -0,0 +1,105 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +
> >> +/ {
> >> + cluster0_opp_table: opp-table-cluster0 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp-614400000 {
> >> + opp-hz = /bits/ 64 <614400000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-819000000 {
> >> + opp-hz = /bits/ 64 <819000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1000000000 {
> >> + opp-hz = /bits/ 64 <1000000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1228800000 {
> >> + opp-hz = /bits/ 64 <1228800000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1600000000 {
> >> + opp-hz = /bits/ 64 <1600000000>;
> >> + opp-microvolt = <1050000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> + };
> >> +
> >> + cluster1_opp_table: opp-table-cluster1 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp-614400000 {
> >> + opp-hz = /bits/ 64 <614400000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-819000000 {
> >> + opp-hz = /bits/ 64 <819000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1000000000 {
> >> + opp-hz = /bits/ 64 <1000000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1228800000 {
> >> + opp-hz = /bits/ 64 <1228800000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1600000000 {
> >> + opp-hz = /bits/ 64 <1600000000>;
> >> + opp-microvolt = <1050000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> + };
> >> +};
> >> +
> >> +&cpu_0 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_1 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_2 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_3 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_4 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> +
> >> +&cpu_5 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> +
> >> +&cpu_6 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> +
> >> +&cpu_7 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> >> index 529ec68e9c23..bdd109b81730 100644
> >> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> >> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> >> @@ -54,6 +54,7 @@ cpu_0: cpu@0 {
> >> compatible = "spacemit,x60", "riscv";
> >> device_type = "cpu";
> >> reg = <0>;
> >> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> >> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> >> riscv,isa-base = "rv64i";
> >> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> >> @@ -84,6 +85,7 @@ cpu_1: cpu@1 {
> >> compatible = "spacemit,x60", "riscv";
> >> device_type = "cpu";
> >> reg = <1>;
> >> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> >
> > Based on the Spacemit kernel source, the k1-x_opp_table.dtsi file
> > defines several additional clocks for the Operating Performance Points
> > (OPP) table:
> >
> > clocks = <&ccu CLK_CPU_C0_ACE>, <&ccu CLK_CPU_C1_ACE>, <&ccu CLK_CPU_C0_TCM>,
> > <&ccu CLK_CCI550>, <&ccu CLK_PLL3>, <&ccu
> > CLK_CPU_C0_HI>, <&ccu CLK_CPU_C1_HI>;
> > clock-names = "ace0","ace1","tcm","cci","pll3", "c0hi", "c1hi";
> >
> > These hardware clocks are also explicitly registered in the APMU clock driver
> > via the k1_ccu_apmu_hws array, confirming their availability for frequency
> > and voltage scaling on the K1-X SoC.
> >
> > static struct clk_hw *k1_ccu_apmu_hws[] = {
> > [CLK_CCI550] = &cci550_clk.common.hw,
> > [CLK_CPU_C0_HI] = &cpu_c0_hi_clk.common.hw,
> > [CLK_CPU_C0_CORE] = &cpu_c0_core_clk.common.hw,
> > [CLK_CPU_C0_ACE] = &cpu_c0_ace_clk.common.hw,
> > [CLK_CPU_C0_TCM] = &cpu_c0_tcm_clk.common.hw,
> > [CLK_CPU_C1_HI] = &cpu_c1_hi_clk.common.hw,
> > [CLK_CPU_C1_CORE] = &cpu_c1_core_clk.common.hw,
> > [CLK_CPU_C1_ACE] = &cpu_c1_ace_clk.common.hw,
> >
> > Yes, it is possible to add these clocks for DVFS to work correctly,
> > provided they are managed by the appropriate driver and declared in
> > the Device Tree (DT).
> >
> > Thanks
> > -Anand
>
> Thanks for your review and for pointing this out.
>
> Regarding the clocks you mentioned, I'd like to clarify their roles based on
> the K1 datasheet. Taking Cluster 0 as an example, c0_core_clk is the primary
> clock for the cluster. c0_ace_clk and c0_tcm_clk are children derived from it,
> defaulting to half the frequency of their parent core clock, while c0_hi_clk
> represents the high-speed path selection.
> Cluster 1 follows the same structure.
>
> Based on the official SpacemiT Bianbu OS source, the spacemit-cpufreq.c driver
> mainly performs the following tasks:
> 1. Sets the CCI550 clock frequency to 614MHz.
> 2. Sets the clock frequencies of c0_ace_clk, c1_ace1_clk, and c0_tcm_clk to half
> the frequency of their parent clock.
> 3. For the 1.6GHz OPP, it sets the PLL3 frequency to 3.2GHz and the
> c0_hi_clk/c1_hi_clk frequencies to 1.6GHz.
>
> I booted with the manufacturer's OpenWRT image and used debugfs to confirm that
> the clock states are exactly as described above.
>
> At 1.6GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> │ └─ cpu_c1_pclk 1,600,000,000 Y cpu0
> │ └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c0_core_clk 1,600,000,000 Y cpu0
> ├─ cpu_c0_tcm_clk 800,000,000 Y deviceless
> └─ cpu_c0_ace_clk 800,000,000 Y deviceless
>
> pll1_2457p6_vco 2,457,600,000 Y deviceless
> └─ pll1_d4 614,400,000 Y deviceless
> └─ pll1_d4_614p4 614,400,000 Y deviceless
> └─ cci550_clk 614,400,000 Y deviceless
>
> At 1.228GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll1_2457p6_vco 2,457,600,000 Y deviceless
> └─ pll1_d2 1,228,800,000 Y deviceless
> └─ pll1_d2_1228p8 1,228,800,000 Y deviceless
> ├─ cpu_c0_core_clk 1,228,800,000 Y cpu0
> │ ├─ cpu_c0_tcm_clk 614,400,000 Y deviceless
> │ └─ cpu_c0_ace_clk 614,400,000 Y deviceless
> └─ cpu_c1_pclk 1,228,800,000 Y cpu0
> └─ cpu_c1_ace_clk 614,400,000 Y deviceless
> └─ pll1_d4 614,400,000 Y deviceless
> └─ pll1_d4_614p4 614,400,000 Y deviceless
> └─ cci550_clk 614,400,000 Y deviceless
>
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> └─ pll3_d3 1,066,666,666 Y deviceless
>
> Regarding the necessity of listing these clocks in the DT, my analysis is as follows:
> 1. For CCI550, I did not find a clear definition of this clock's specific role
> in the SoC datasheet. Although the vendor kernel increases its frequency,
> my benchmarks show that maintaining the mainline default (245.76MHz) has a
> negligible impact on CPU performance.
> 2. For ACE and TCM clocks, they function as synchronous children of the core
> clock with a default divide-by-2 ratio. Since they scale automatically relative
> to c0_core_clk/c1_core_clk and no other peripherals depend on them, they do not
> require manual management in the OPP table.
> 3. For the high-speed path, the underlying clock controller logic already handles
> the parent MUX switching and PLL3 scaling automatically when clk_set_rate()
> is called on the core clock.
>
> I have verified this by checking the hardware state in the mainline kernel.
> The clock tree matches the vendor kernel's configuration:
>
> At 1.6GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> │ └─ cpu_c1_core_clk 1,600,000,000 Y cpu4
> │ └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c0_core_clk 1,600,000,000 Y cpu0
> ├─ cpu_c0_tcm_clk 800,000,000 Y deviceless
> └─ cpu_c0_ace_clk 800,000,000 Y deviceless
>
> pll1 2,457,600,000 Y deviceless
> └─ pll1_d5 491,520,000 Y deviceless
> └─ pll1_d5_491p52 491,520,000 Y deviceless
> └─ cci550_clk 245,760,000 Y deviceless
>
> At 1.228GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll1 2,457,600,000 Y deviceless
> ├─ pll1_d5 491,520,000 Y deviceless
> │ └─ pll1_d5_491p52 491,520,000 Y deviceless
> │ └─ cci550_clk 245,760,000 Y deviceless
> └─ pll1_d2 1,228,800,000 Y deviceless
> └─ pll1_d2_1228p8 1,228,800,000 Y deviceless
> └─ cpu_c0_core_clk 1,228,800,000 Y cpu0
> ├─ cpu_c0_tcm_clk 614,400,000 Y deviceless
> └─ cpu_c0_ace_clk 614,400,000 Y deviceless
>
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> └─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c1_core_clk 1,600,000,000 Y cpu4
> └─ cpu_c1_ace_clk 800,000,000 Y deviceless
>
Thanks, I have verified the clocks are set to Y in
/sys/kernel/debug/clk/clk_summary
> Performance benchmarks also confirm that the current configuration is sufficient:
> Benchmark (AWK computation): time awk 'BEGIN{for(i=0;i<10000000;i++) sum+=i}'
> ----------------------------------------------------------------------------
> Frequency | Mainline Linux (s) | OpenWrt (s)
> (kHz) | Real (Total) | User (CPU) | Real (Total) | User (CPU) )
> -------------+---------------+---------------+---------------+--------------
> 1,600,000 | 1.82s | 1.81s | 1.73s | 1.73s
> 1,228,800 | 2.34s | 2.33s | 2.26s | 2.26s
> 1,000,000 | 2.94s | 2.86s | 2.78s | 2.78s
> 819,000 | 3.54s | 3.53s | 3.39s | 3.39s
> 614,400 | 4.73s | 4.71s | 4.51s | 4.51s
> ----------------------------------------------------------------------------
>
> In summary, because the clock controller correctly handles the internal dividers
> and parent switching, declaring only the primary core clock for each CPU node is
> sufficient for functional DVFS.
>
I have just tested this patch against next-20260415
But, I have observed this log on the Banana Pi F3 dev board with the
Banana PI - R4 heat sink and fan.
[ 5.803445][ T1] In-situ OAM (IOAM) with IPv6
[ 5.809605][ T1] NET: Registered PF_PACKET protocol family
[ 5.819098][ T1] Key type dns_resolver registered
[ 5.853430][ C2] cpu2: scalar unaligned word access speed is
1.60x byte access speed (fast)
[ 5.853431][ C3] cpu3: scalar unaligned word access speed is
1.67x byte access speed (fast)
[ 5.853440][ C7] cpu7: scalar unaligned word access speed is
8.10x byte access speed (fast)
[ 5.853432][ C1] cpu1: scalar unaligned word access speed is
3.98x byte access speed (fast)
[ 5.853431][ T1] cpu0: scalar unaligned word access speed is
2.33x byte access speed (fast)
[ 5.853436][ C5] cpu5: scalar unaligned word access speed is
2.29x byte access speed (fast)
[ 5.853436][ C6] cpu6: scalar unaligned word access speed is
2.58x byte access speed (fast)
[ 5.853431][ C4] cpu4: scalar unaligned word access speed is
2.07x byte access speed (fast)
[ 5.936544][ T92] mmcblk0boot0: mmc0:0001 AJTD4R 4.00 MiB
[ 6.003120][ T92] mmcblk0boot1: mmc0:0001 AJTD4R 4.00 MiB
[ 6.070909][ T92] mmcblk0rpmb: mmc0:0001 AJTD4R 4.00 MiB, chardev (244:0)
[ 6.380324][ T1] registered taskstats version 1
[ 6.407337][ T1] Loading compiled-in X.509 certificates
[ 6.594206][ T1] Loaded X.509 cert 'Build time autogenerated
kernel key: 19b81ec48e45e6ee983623417bad5096df8bbcf1'
[ 7.600343][ T1] Demotion targets for Node 0: null
[ 7.608583][ T1] kmemleak: Kernel memory leak detector
initialized (mem pool available: 1309)
[ 7.608646][ T120] kmemleak: Automatic memory scanning thread started
[ 7.624663][ T1] debug_vm_pgtable: [debug_vm_pgtable ]:
Validating architecture page table helpers
[ 7.636721][ T1] page_owner is disabled
[ 8.213648][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
in 'domains'
[ 8.233502][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
in 'domains'
[ 8.254012][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
in 'domains'
[ 8.319431][ T74] printk: legacy console [ttyS0] disabled
[ 8.345811][ T74] d4017000.serial: ttyS0 at MMIO 0xd4017000 (irq
= 16, base_baud = 921600) is a XScale
[ 8.357331][ T74] printk: legacy console [ttyS0] enabled
[ 8.357331][ T74] printk: legacy console [ttyS0] enabled
[ 8.369971][ T74] printk: legacy bootconsole [uart0] disabled
[ 8.369971][ T74] printk: legacy bootconsole [uart0] disabled
[ 8.427040][ T74] /soc/i2c@d401d800/pmic@41: Fixed dependency
cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5
[ 8.634595][ T74] spacemit-p1-rtc spacemit-p1-rtc.1.auto:
registered as rtc0
[ 8.642732][ T74] spacemit-p1-rtc spacemit-p1-rtc.1.auto: setting
system clock to 2026-04-10T00:03:42 UTC (1775779422)
[ 8.766081][ T74] sdhci-spacemit d4280000.mmc: Got CD GPIO
[ 8.801855][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.806411][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.813413][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.818261][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.818307][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.827239][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.833161][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 8.842546][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 8.848941][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 8.855273][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 8.893720][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.904437][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.908515][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.918057][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 8.924402][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 8.945668][ T74] mmc1: SDHCI controller on d4280000.mmc
[d4280000.mmc] using ADMA
[ 8.976207][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.980156][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.986169][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.995473][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.001603][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.020028][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.024051][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.030122][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.036004][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.036059][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.045003][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.045077][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.058079][ T57] spacemit-k1-pcie ca800000.pcie: host bridge
/soc/pcie-bus/pcie@ca800000 ranges:
[ 9.064716][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.064745][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.064825][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 9.064889][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.065762][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.069924][ T60] spacemit-k1-pcie ca400000.pcie: host bridge
/soc/pcie-bus/pcie@ca400000 ranges:
[ 9.071122][ T60] spacemit-k1-pcie ca400000.pcie: IO
0x009f002000..0x009f101fff -> 0x0000000000
[ 9.073304][ T60] spacemit-k1-pcie ca400000.pcie: MEM
0x0090000000..0x009effffff -> 0x0090000000
[ 9.081407][ T74] at24 2-0050: 256 byte 24c02 EEPROM, read-only
[ 9.083047][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.083509][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.083614][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.083686][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.083845][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 9.083885][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.089945][ T57] spacemit-k1-pcie ca800000.pcie: IO
0x00b7002000..0x00b7101fff -> 0x0000000000
[ 9.092728][ T1] clk: Disabling unused clocks
[ 9.095269][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.096981][ T1] PM: genpd: Disabling unused power domains
[ 9.104949][ T57] spacemit-k1-pcie ca800000.pcie: MEM
0x00a0000000..0x00afffffff -> 0x00a0000000
[ 9.107986][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.108166][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.108246][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.108311][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 9.108356][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.108582][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.113366][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.118144][ T57] spacemit-k1-pcie ca800000.pcie: MEM
0x00b0000000..0x00b6ffffff -> 0x00b0000000
[ 9.130386][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.196246][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.202562][ T60] spacemit-k1-pcie ca400000.pcie: iATU: unroll T,
8 ob, 8 ib, align 4K, limit 4G
[ 9.206998][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.257180][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
After reviewing the Banana Pi F3 schematics, I confirmed that Buck1 and Buck2
Both supply the CORE_0V9 with 0.9V±1% rail. To resolve the restriction errors,
I expanded the voltage range in the DTS to 500,000–950,000 µV.
Additionally, I updated the DTS to map the second CPU cluster (cores 4–7)
to Buck2 to better align with the hardware's power distribution.
[1] https://drive.google.com/file/d/19iLJ5xnCB_oK8VeQjkPGjzAn39WYyylv/view
(page 4)
Can you share your thoughts on the changes below?
$ git diff
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 7e300cca50d8..be53645ba0c6 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -102,19 +102,19 @@ &cpu_3 {
};
&cpu_4 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&cpu_5 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&cpu_6 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&cpu_7 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&emmc {
@@ -234,14 +234,14 @@ pmic@41 {
regulators {
buck1_3v45: buck1 {
regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
+ regulator-max-microvolt = <950000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
- buck2 {
+ buck2_3v45: buck2 {
regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
+ regulator-max-microvolt = <950000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
> --
> Best regards,
> Shuwei Wu
Thanks
-Anand
^ permalink raw reply related
* Re: [PATCH 1/9] dt-bindings: sound: mt2701-afe-pcm: add HDMI audio path clocks
From: Daniel Golle @ 2026-04-16 11:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Nícolas F. R. A. Prado, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260416-qualified-violet-salmon-4bec7e@quoll>
On Thu, Apr 16, 2026 at 11:38:24AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Apr 15, 2026 at 04:23:27PM +0100, Daniel Golle wrote:
> > Document four additional optional clocks feeding the HDMI audio
> > output path on MT2701 and MT7623N: the HADDS2 PLL (root of the
>
> There is no MT7623N compatible in this file, so that's confusing. Does
> mt7622 have it? If not, then it should be restricted per variant. If
> yet, the model name is confusing.
Only MT7623N (which is apparently identical with MT2701) has all the
multimedia features (ie. HDMI, a Mali-450 GPU, ...). Neither MT7623A
nor any of the other MediaTek router SoCs got any of that. So it
should be restricted to that variant. I'll fix this in v2.
Thanks for the review!
Daniel
^ permalink raw reply
* Re: [PATCH] of: unittest: fix use-after-free in of_unittest_changeset()
From: Rob Herring (Arm) @ 2026-04-16 11:49 UTC (permalink / raw)
To: Wentao Liang; +Cc: saravanak, devicetree, stable, linux-kernel
In-Reply-To: <20260409022233.418103-1-vulab@iscas.ac.cn>
On Thu, 09 Apr 2026 02:22:33 +0000, Wentao Liang wrote:
> The variable 'parent' is assigned the value of 'nchangeset' earlier in the
> function, meaning both point to the same struct device_node. The call to
> of_node_put(nchangeset) can decrement the reference count to zero and
> free the node if there are no other holders. After that, the code still
> uses 'parent' to check for the presence of a property and to read a
> string property, leading to a use-after-free.
>
> Fix this by moving the of_node_put() call after the last access to
> 'parent', avoiding the UAF.
>
> Fixes: 1c668ea65506 ("of: unittest: Use of_property_present()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/of/unittest.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] of: unittest: fix use-after-free in testdrv_probe()
From: Rob Herring (Arm) @ 2026-04-16 11:51 UTC (permalink / raw)
To: Wentao Liang; +Cc: linux-kernel, devicetree, stable, saravanak
In-Reply-To: <20260409034859.429071-1-vulab@iscas.ac.cn>
On Thu, 09 Apr 2026 03:48:59 +0000, Wentao Liang wrote:
> The function testdrv_probe() retrieves the device_node from the PCI
> device, applies an overlay, and then immediately calls of_node_put(dn).
> This releases the reference held by the PCI core, potentially freeing
> the node if the reference count drops to zero. Later, the same freed
> pointer 'dn' is passed to of_platform_default_populate(), leading to a
> use-after-free.
>
> The reference to pdev->dev.of_node is owned by the device model and
> should not be released by the driver. Remove the erroneous of_node_put()
> to prevent premature freeing.
>
> Fixes: 26409dd04589 ("of: unittest: Add pci_dt_testdrv pci driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/of/unittest.c | 1 -
> 1 file changed, 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 01/13] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Rob Herring @ 2026-04-16 11:59 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Guenter Roeck,
Philipp Zabel, Eric Biggers, Sakari Ailus, Wolfram Sang,
Miquel Raynal, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-2-akhilrajeev@nvidia.com>
On Thu, Apr 09, 2026 at 04:27:31PM +0530, Akhil R wrote:
> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> Discovery and Configuration Specification [1] to specify which discovery
> method an I3C device supports during bus initialization. The property is
> a bitmap, where a bit value of 1 indicates support for that method, and 0
> indicates lack of support.
> Bit 0: SETDASA CCC (Direct)
> Bit 1: SETAASA CCC (Broadcast)
> Bit 2: Other CCC (vendor / standards extension)
> All other bits are reserved.
>
> It is specifically needed when an I3C device requires SETAASA for the
> address assignment. SETDASA will be supported by default if this property
> is absent, which means for now the property just serves as a flag to
> enable SETAASA, but keep the property as a bitmap to align with the
> specifications.
>
> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
> .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> index e25fa72fd785..1705d90d4d79 100644
> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> @@ -31,10 +31,12 @@ properties:
> described in the device tree, which in turn means we have to describe
> I3C devices.
>
> - Another use case for describing an I3C device in the device tree is when
> - this I3C device has a static I2C address and we want to assign it a
> - specific I3C dynamic address before the DAA takes place (so that other
> - devices on the bus can't take this dynamic address).
> + Other use-cases for describing an I3C device in the device tree are:
> + - When the I3C device has a static I2C address and we want to assign
> + it a specific I3C dynamic address before the DAA takes place (so
> + that other devices on the bus can't take this dynamic address).
> + - When the I3C device requires SETAASA for its discovery and uses a
> + pre-defined static address.
>
> "#size-cells":
> const: 0
> @@ -147,6 +149,26 @@ patternProperties:
> through SETDASA. If static address is not present, this address is assigned
> through SETNEWDA after assigning a temporary address via ENTDAA.
>
> + mipi-i3c-static-method:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0x1
> + maximum: 0xff
Looks like the max is 0x7 currently.
> + default: 1
> + description: |
> + Bitmap describing which methods of Dynamic Address Assignment from a
> + static address are supported by this I3C Target. A bit value of 1
> + indicates support for that method, and 0 indicates lack of support.
blank line here.
> + Bit 0: SETDASA CCC (Direct)
> + Bit 1: SETAASA CCC (Broadcast)
> + Bit 2: Other CCC (vendor / standards extension)
> + All other bits are reserved.
Indent these by 2 more.
> +
> + This property follows the MIPI I3C specification. The primary use
> + of this property is to indicate support for SETAASA, i.e Bit 1, but
> + will allow all values so that it is aligned with the specifications.
> + SETDASA will remain as the default method even if this property is
> + not present.
> +
> required:
> - reg
>
> --
> 2.50.1
>
^ permalink raw reply
* [PATCH v5 00/13] Add explicit clock vote and enable power-domain for QCOM-ICE
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev,
Manivannan Sadhasivam
When the kernel is booted without the 'clk_ignore_unused' and
'pd_ignore_unused' command‑line flags, votes for unused clocks and power
domains are dropped by the kernel post late_init and deferred probe
timeout. Depending on the relative timing between the ICE probe and the
kernel disabling the unused clocks and power domains occasional unclocked
register accesses or 'stuck' clocks are observed during QCOM‑ICE probe.
When the 'iface' clock is not voted on, unclocked register access would
be observed. On the other hand, if the associated power-domain for ICE
is not enabled, a 'stuck' clock is observed.
This patch series resolves both of these problems by adding explicit
power‑domain enablement and 'iface' clock‑vote handling to the QCOM‑ICE
driver.
The clock 'stuck' issue was first reported on Qualcomm RideSX4 (sa8775p)
platform: https://lore.kernel.org/all/ZZYTYsaNUuWQg3tR@x1/
Issue with unclocked ICE register access is easily reproducible on
on Qualcomm RB3Gen2 (kodiak) platform when 'clk_ignore_unused' is
not passed on the kernel command-line.
This patch series has been validated on: SM8650-MTP, RB3Gen2 and
Lemans-EVK.
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
Changes in v5:
- Rebased onto linux-next tag next-20260415
- Added patches 12 and 13 to this series to ensure newly added eliza and milos
DTS in v7.1 comply to the DT-binding introduced in this patch series.
- Fixed commit message of patch 1 to indicate eliza and milos DT support was
added in kernel v7.1.
- Collected Reviewed-by and Tested-by tags from Kuldeep, Konrad, Krzysztof and
Manivannan.
- Link to v4: https://lore.kernel.org/r/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com
Changes in v4:
- Squashed commits 1 and 2 from v3 to form a single consolidated patch with
an updated and more concise commit message that explains why the DT binding
needs to be fixed and why the fix is necessary for this release cycle.
- Re-order the ICE driver source code patches to be positioned before the DTS
patches.
- Collected Reviewed-by tags from Konrad for DTS patches which were missed in
v3.
- Link to v3: https://lore.kernel.org/r/20260317-qcom_ice_power_and_clk_vote-v3-0-53371dbabd6a@oss.qualcomm.com
Changes in v3:
- Dropped "_clk" suffix from clock names in DT binding and sources and ensure
ICE driver looks for these updated clock names.
- Updated commit message of DT binding change (Patch 1) to explicitly state
that the change is preserving backward compatibility.
- Introduced new DT binding commit to ensure eliza and milos require the iface
clock and power-domain.
- Check for IS_ERR() on devm_clk_get_optional_enabled(dev, "iface") return
value.
- Minor beautification of dev_err() prints as suggested by Konrad.
- Rebased onto latest linux-next tag next-20260316.
- Link to v2: https://lore.kernel.org/r/20260310-qcom_ice_power_and_clk_vote-v2-0-b9c2a5471d9e@oss.qualcomm.com
Changes in v2:
- Updated the DT bindings and ICE driver source to ensure no ABI breaks are
made in this patch series. A follow-up patch series will mark the clocks
and power-domain as required to preserve bisectability.
- Added list of allowed clock-names to the DT-binding.
- Added Fixes tag to mark the original regressions and ensure back-porting
for stable trees.
- Updated the commit messages to explicitly mention the problem of
potential unclocked register access and stuck clocks during probe.
- Dropped explicit calls to pm_runtime_* APIs from ICE probe, suspend and
resume.
- Link to v1: https://lore.kernel.org/r/20260123-qcom_ice_power_and_clk_vote-v1-0-e9059776f85c@qti.qualcomm.com
---
Harshal Dev (13):
dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE
arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node
arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node
arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node
arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node
arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node
arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
arch/arm64/boot/dts/qcom/eliza.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/kodiak.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/lemans.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/milos.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/monaco.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8450.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8750.dtsi | 6 +++-
drivers/soc/qcom/ice.c | 17 +++++++++--
13 files changed, 104 insertions(+), 14 deletions(-)
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260120-qcom_ice_power_and_clk_vote-769704f5036a
Best regards,
--
Harshal Dev <harshal.dev@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v5 01/13] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
power-domain and iface clock. Without enabling the iface clock and the
associated power-domain the ICE hardware cannot function correctly and
leads to unclocked hardware accesses being observed during probe.
Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
power-domain and iface clock for new devices (Eliza and Milos) introduced
in the current release (7.1) with yet-to-stabilize ABI, while preserving
backward compatibility for older devices.
Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index 876bf90ed96e..ccb6b8dd8e11 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -30,6 +30,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: iface
+
+ power-domains:
maxItems: 1
operating-points-v2: true
@@ -44,6 +54,25 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,eliza-inline-crypto-engine
+ - qcom,milos-inline-crypto-engine
+
+ then:
+ required:
+ - power-domains
+ - clock-names
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
examples:
- |
#include <dt-bindings/clock/qcom,sm8550-gcc.h>
@@ -52,7 +81,11 @@ examples:
compatible = "qcom,sm8550-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x01d88000 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
operating-points-v2 = <&ice_opp_table>;
--
2.34.1
^ permalink raw reply related
* [PATCH v5 02/13] soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev,
Manivannan Sadhasivam
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Since Qualcomm inline-crypto engine (ICE) is now a dedicated driver
de-coupled from the QCOM UFS driver, it explicitly votes for its required
clocks during probe. For scenarios where the 'clk_ignore_unused' flag is
not passed on the kernel command line, to avoid potential unclocked ICE
hardware register access during probe the ICE driver should additionally
vote on the 'iface' clock.
Also update the suspend and resume callbacks to handle un-voting and voting
on the 'iface' clock.
Fixes: 2afbf43a4aec6 ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver")
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
drivers/soc/qcom/ice.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index b203bc685cad..bf4ab2d9e5c0 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -108,6 +108,7 @@ struct qcom_ice {
void __iomem *base;
struct clk *core_clk;
+ struct clk *iface_clk;
bool use_hwkm;
bool hwkm_init_complete;
u8 hwkm_version;
@@ -312,8 +313,13 @@ int qcom_ice_resume(struct qcom_ice *ice)
err = clk_prepare_enable(ice->core_clk);
if (err) {
- dev_err(dev, "failed to enable core clock (%d)\n",
- err);
+ dev_err(dev, "Failed to enable core clock: %d\n", err);
+ return err;
+ }
+
+ err = clk_prepare_enable(ice->iface_clk);
+ if (err) {
+ dev_err(dev, "Failed to enable iface clock: %d\n", err);
return err;
}
qcom_ice_hwkm_init(ice);
@@ -323,6 +329,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
int qcom_ice_suspend(struct qcom_ice *ice)
{
+ clk_disable_unprepare(ice->iface_clk);
clk_disable_unprepare(ice->core_clk);
ice->hwkm_init_complete = false;
@@ -579,11 +586,17 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
engine->core_clk = devm_clk_get_optional_enabled(dev, "ice_core_clk");
if (!engine->core_clk)
engine->core_clk = devm_clk_get_optional_enabled(dev, "ice");
+ if (!engine->core_clk)
+ engine->core_clk = devm_clk_get_optional_enabled(dev, "core");
if (!engine->core_clk)
engine->core_clk = devm_clk_get_enabled(dev, NULL);
if (IS_ERR(engine->core_clk))
return ERR_CAST(engine->core_clk);
+ engine->iface_clk = devm_clk_get_optional_enabled(dev, "iface");
+ if (IS_ERR(engine->iface_clk))
+ return ERR_CAST(engine->iface_clk);
+
if (!qcom_ice_check_supported(engine))
return ERR_PTR(-EOPNOTSUPP);
--
2.34.1
^ permalink raw reply related
* [PATCH v5 03/13] arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
kaanapali.
Fixes: 2eeb5767d53f4 ("arm64: dts: qcom: Introduce Kaanapali SoC")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..14e362a4899b 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2538,7 +2538,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 04/13] arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for lemans.
Fixes: 96272ba7103d4 ("arm64: dts: qcom: sa8775p: enable the inline crypto engine")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index fe6e76351823..d83cad26a20f 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -2758,7 +2758,11 @@ ice: crypto@1d88000 {
compatible = "qcom,sa8775p-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 05/13] arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
monaco.
Fixes: cc9d29aad876d ("arm64: dts: qcom: qcs8300: enable the inline crypto engine")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 7b1d57460f1e..fa13210fc539 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -2737,7 +2737,11 @@ ice: crypto@1d88000 {
compatible = "qcom,qcs8300-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
crypto: crypto@1dfa000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 06/13] arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sc7180.
Fixes: 858536d9dc946 ("arm64: dts: qcom: sc7180: Add UFS nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index a4b17564469e..94a699cc2688 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1605,7 +1605,11 @@ ice: crypto@1d90000 {
compatible = "qcom,sc7180-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0 0x01d90000 0 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
ipa: ipa@1e40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 07/13] arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
kodiak.
Fixes: dfd5ee7b34bb7 ("arm64: dts: qcom: sc7280: Add inline crypto engine")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..55fc256501c5 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -2579,7 +2579,11 @@ ice: crypto@1d88000 {
compatible = "qcom,sc7280-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v3 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Rob Herring (Arm) @ 2026-04-16 12:00 UTC (permalink / raw)
To: Jens Emil Schulz Østergaard
Cc: Steen Hegelund, Krzysztof Kozlowski, devicetree, Jakub Kicinski,
linux-kernel, Vladimir Oltean, Woojung Huh, Conor Dooley,
Russell King, David S. Miller, netdev, UNGLinuxDriver,
Simon Horman, Daniel Machon, Paolo Abeni, Eric Dumazet,
Andrew Lunn
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-2-aadc8595306d@microchip.com>
On Fri, 10 Apr 2026 13:48:38 +0200, Jens Emil Schulz Østergaard wrote:
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
>
> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
> Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> ---
> Changes in v3:
> - remove additionalProperties: true
> - remove unnecessary | from description
> - change top level $ref to dsa.yaml#/$defs/ethernet-ports
> - use ethernet-ports and ethernet-port
> - move ethernet-ports under properties instead of patternProperties
> - move unevaluatedProperties: false after $ref
> - update example to use ethernet-ports and ethernet-port
>
> Changes in v2:
> - rename file to microchip,lan96455s-switch.yaml
> - remove led vendor property
> - add {rx,tx}-internal-delay-ps for rgmii delay
> - remove labels from example
> - remove container node from example
> ---
> .../net/dsa/microchip,lan96455s-switch.yaml | 111 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 112 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 08/13] arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8450.
Fixes: 86b0aef435851 ("arm64: dts: qcom: sm8450: Use standalone ICE node for UFS")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 03bf30b53f28..9528baedf8ae 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -5374,7 +5374,11 @@ ice: crypto@1d88000 {
compatible = "qcom,sm8450-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 09/13] arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8550.
Fixes: b8630c48b43fc ("arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 912525e9bca6..fe46a5d41fe0 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2465,7 +2465,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 10/13] arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8650.
Fixes: 10e0246712951 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 1604bc8cff37..e2d98cf6adca 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -4081,7 +4081,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 11/13] arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
sm8750.
Fixes: b1dac789c650a ("arm64: dts: qcom: sm8750: Add ICE nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 18fb52c14acd..099d7fb82ae6 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -2086,7 +2086,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 12/13] arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for milos.
Fixes: 04bb37433330e ("arm64: dts: qcom: milos: Add UFS nodes")
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..a6e463f3885d 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1275,7 +1275,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 13/13] arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
eliza.
Fixes: af20af39fc09b ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 4a7a0ac40ce6..7e97361a5dc5 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -843,7 +843,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: thermal: Fix false warning with 'phandle' in trips nodes
From: Rob Herring (Arm) @ 2026-04-16 12:03 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Daniel Lezcano, Zhang Rui, Krzysztof Kozlowski, Lukasz Luba,
Rafael J. Wysocki, linux-pm, Conor Dooley, linux-kernel,
devicetree
In-Reply-To: <20260410223601.1487473-2-robh@kernel.org>
On Fri, 10 Apr 2026 17:36:00 -0500, Rob Herring (Arm) wrote:
> A pattern property matching essentially anything doesn't work if there
> are implicit properties such as 'phandle' which can occur on any node.
> One such example popped up recently:
>
> arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: thermal-zones: gpuss0-thermal:trips:phandle: 531 is not of type 'object'
> from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
>
> Instead of a pattern property, use an "additionalProperties" schema
> instead which is the fallback in case of no matching property.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> Daniel, Please pick this up for v7.1 as the above warning is in next. Or
> if you prefer, I can take it.
>
> .../bindings/thermal/thermal-zones.yaml | 111 +++++++++---------
> 1 file changed, 54 insertions(+), 57 deletions(-)
>
Applied, thanks!
^ 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