* [PATCH] dt-bindings: timer: Remove sifive,fine-ctr-bits property
From: Nick Hu @ 2026-04-20 6:18 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Samuel Holland, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Anup Patel
Cc: Conor Dooley, linux-kernel, devicetree, linux-riscv, Nick Hu
The counter width can be inferred from the compatible string, making the
explicit "sifive,fine-ctr-bits" property redundant. Remove the property
to simplify the bindings.
Fixes: 0f920690a82c ("dt-bindings: timer: Add SiFive CLINT2")
Suggested-by: Conor Dooley <conor+dt@kernel.org>
Link: https://lore.kernel.org/linux-riscv/20260330-relative-hardened-5ce35fe1ef57@spud/
Signed-off-by: Nick Hu <nick.hu@sifive.com>
---
.../devicetree/bindings/timer/sifive,clint.yaml | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 3c16b260db04..051edb1da0d7 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -72,22 +72,6 @@ properties:
minItems: 1
maxItems: 4095
- sifive,fine-ctr-bits:
- maximum: 15
- description: The width in bits of the fine counter.
-
-if:
- properties:
- compatible:
- contains:
- const: sifive,clint2
-then:
- required:
- - sifive,fine-ctr-bits
-else:
- properties:
- sifive,fine-ctr-bits: false
-
additionalProperties: false
required:
---
base-commit: c1f49dea2b8f335813d3b348fd39117fb8efb428
change-id: 20260409-clintv2-remove-fine-ctr-d5caeda27863
Best regards,
--
Nick Hu <nick.hu@sifive.com>
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: amlogic: add support for X98Q
From: christian.koever-draxl @ 2026-04-20 6:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, funderscore, devicetree,
linux-kernel, linux-arm-kernel, linux-amlogic,
christian.koever-draxl
In-Reply-To: <20260420061854.5421-1-christian.koever-draxl@student.uibk.ac.at>
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 250 ++++++++++++++++++
2 files changed, 251 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..c7752684dea6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -85,6 +85,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-ugoos-am3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
new file mode 100644
index 000000000000..26c60a4c2a43
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
@@ -0,0 +1,250 @@
+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
+ * Based on meson-s4-s905y4-khadas-vim1s.dts:
+ * - Copyright (c) 2026 Khadas Technology Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "meson-s4.dtsi"
+
+/ {
+ model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ mmc0 = &emmc; /* eMMC */
+ mmc1 = &sd; /* SD card */
+ mmc2 = &sdio; /* SDIO */
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 52 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ reg = <0x0 0x05000000 0x0 0x3400000>;
+ no-map;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_32k: sdio-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&sdio_32k>;
+ clock-names = "ext_clock";
+ };
+
+ main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ vddio_sd: regulator-vddio-sd {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <1800000 1 3300000 0>;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_5v>;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ /* SY8120B1ABC DC/DC Regulator. */
+ vddcpu: regulator-vddcpu {
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <689000>;
+ regulator-max-microvolt = <1049000>;
+
+ vin-supply = <&main_5v>;
+
+ pwms = <&pwm_ij 1 1500 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ /* Voltage Duty-Cycle */
+ voltage-table = <1049000 0>,
+ <1039000 3>,
+ <1029000 6>,
+ <1019000 9>,
+ <1009000 12>,
+ <999000 14>,
+ <989000 17>,
+ <979000 20>,
+ <969000 23>,
+ <959000 26>,
+ <949000 29>,
+ <939000 31>,
+ <929000 34>,
+ <919000 37>,
+ <909000 40>,
+ <899000 43>,
+ <889000 45>,
+ <879000 48>,
+ <869000 51>,
+ <859000 54>,
+ <849000 56>,
+ <839000 59>,
+ <829000 62>,
+ <819000 65>,
+ <809000 68>,
+ <799000 70>,
+ <789000 73>,
+ <779000 76>,
+ <769000 79>,
+ <759000 81>,
+ <749000 84>,
+ <739000 87>,
+ <729000 89>,
+ <719000 92>,
+ <709000 95>,
+ <699000 98>,
+ <689000 100>;
+ };
+};
+
+&emmc {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins1>;
+ pinctrl-names = "default";
+};
+
+&pwm_ij {
+ status = "okay";
+};
+
+&sd {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+/*
+* Wireless SDIO Module (Amlogic W150S1)
+* Note: There is no driver for this at the moment.
+*/
+
+&sdio {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ no-sd;
+ no-mmc;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+&uart_b {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: arm: amlogic: add X98Q compatible
From: christian.koever-draxl @ 2026-04-20 6:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, funderscore, devicetree,
linux-kernel, linux-arm-kernel, linux-amlogic,
christian.koever-draxl
In-Reply-To: <20260420061854.5421-1-christian.koever-draxl@student.uibk.ac.at>
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..82671d58d1da 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -254,6 +254,13 @@ properties:
- khadas,vim1s
- const: amlogic,s905y4
- const: amlogic,s4
+
+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
+ items:
+ - enum:
+ - amediatech,x98q
+ - const: amlogic,s905w2
+ - const: amlogic,s4
- description: Boards with the Amlogic S6 S905X5 SoC
items:
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: christian.koever-draxl @ 2026-04-20 6:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, funderscore, devicetree,
linux-kernel, linux-arm-kernel, linux-amlogic,
christian.koever-draxl
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Supported features:
- 1GB/2GB RAM (via U-Boot memory fixup)
- 10/100 Ethernet (Internal PHY)
- eMMC and SD card storage
- PWM-based CPU voltage regulation
- UART (Serial console)
Changes in v2:
- Split dt-bindings and dts changes into separate patches.
- Updated model string to match documented vendor prefix.
- Put vddio_sd states array in a single line.
- Added a clarifying comment for the unsupported Amlogic W150S1 Wi-Fi module.
Notes:
- The console uses uart_b at 921600 baud.
- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB.
- Tested on the 2GB RAM plus 16GB eMMC variant.
Christian Stefan Kövér-Draxl (2):
dt-bindings: arm: amlogic: add X98Q compatible
arm64: dts: amlogic: add support for X98Q
.../devicetree/bindings/arm/amlogic.yaml | 7 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 250 ++++++++++++++++++
3 files changed, 258 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
--
2.53.0
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: bridge: This patch adds new content to the lontium,lt9611.yaml binding file
From: syyang @ 2026-04-20 6:16 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, yangsunyun1993, xmzhu, Sunyun Yang
In-Reply-To: <20260420061644.1251070-1-syyang@lontium.com>
From: Sunyun Yang <syyang@lontium.com>
Add lt9611c,lt9611ex,lt9611uxd to the lontium,lt9611.yaml file.
LT9611C(EX/UXD) is a high performance Single/Dual-Port MIPI to
HDMI 1.4/2.0 converter:
-Single/Dual-port MIPI DSI Receiver
1. Compliantwith D-PHY1.2&DSI-2 1.0
2. 1/2configurable ports
3. 1 clock lane and 1/2/3/4 configurable data lanes per port
4. 80Mbps~2.5Gbps per data lane
5. Support RGB666, loosely RGB666, RGB888, RGB565,16-bit YCbCr4:2:2
-HDMI 1.4/2.0 Transmitter
1.Data rate up to 6Gbps
2.Support HDCP1.4/2.3
3.Support CEC,HDR10
4.Support lane swap
-audio
1.sample rates of 32~192 KHz and sample sizes
of 16~24 bits
2.SPDIF interface supports PCM, Dolbydigital, DTS digital audio
at up to 192KHz frame rate
-Miscellaneous
1.CSC:RGB<->YUV444<->YUV422
Signed-off-by: Sunyun Yang <syyang@lontium.com>
---
.../bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
index 429a06057ae8..a67e63a5c87e 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -4,19 +4,23 @@
$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
+title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI to HDMI Bridge
maintainers:
- Vinod Koul <vkoul@kernel.org>
description: |
- The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
+ The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
+ are bridge devices which convert DSI to HDMI
properties:
compatible:
enum:
- lontium,lt9611
- lontium,lt9611uxc
+ - lontium,lt9611c
+ - lontium,lt9611ex
+ - lontium,lt9611uxd
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Shawn Guo @ 2026-04-20 6:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Add compatibles for GENI Serial Engine QUP Wrapper Controller on Nord SoC
with fallback on SA8255P compatibles.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
index 352af3426d34..d73f9edcbbdb 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
@@ -19,7 +19,12 @@ description:
properties:
compatible:
- const: qcom,sa8255p-geni-se-qup
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-se-qup
+ - items:
+ - const: qcom,nord-auto-geni-se-qup
+ - const: qcom,sa8255p-geni-se-qup
reg:
description: QUP wrapper common register address and length.
@@ -67,9 +72,16 @@ patternProperties:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,nord-auto-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,nord-auto-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
required:
- compatible
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Geert Uytterhoeven @ 2026-04-20 6:50 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, linux-tegra, linux-arm-kernel, linux-pm,
linux-omap, linux-m68k, devicetree, linux-kernel, Paul Walmsley
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
Hi Thierry,
On Fri, 17 Apr 2026 at 15:15, Thierry Reding <thierry.reding@kernel.org> wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Peter sadly passed away a while back. Paul did a much better job at
> finding the right words to mourn this loss than I ever could, so I will
> leave this link here:
>
> https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
>
> Co-developed-by: Paul Walmsley <pjw@kernel.org>
> Co-developed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org>
"every Co-developed-by: must be immediately
followed by a Signed-off-by: of the associated co-author."
https://elixir.bootlin.com/linux/v7.0/source/Documentation/process/submitting-patches.rst#L506
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v2:
> - add more missing entries
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: thermal: qcom-tsens: Document Nord Temperature Sensor
From: Shawn Guo @ 2026-04-20 6:54 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, linux-pm,
devicetree, linux-arm-msm, linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Add compatible for Temperature Sensor (TSENS) of Nord SoC with
a fallback on qcom,tsens-v2.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 7d34ba00e684..e65ebc6f1698 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -58,6 +58,7 @@ properties:
- qcom,glymur-tsens
- qcom,kaanapali-tsens
- qcom,milos-tsens
+ - qcom,nord-tsens
- qcom,msm8953-tsens
- qcom,msm8996-tsens
- qcom,msm8998-tsens
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: rockchip: Replace deprecated snps,* props for NanoPi R5S
From: Tianling Shen @ 2026-04-20 6:58 UTC (permalink / raw)
To: Diederik de Haas, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner
Cc: Arnd Bergmann, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Quentin Schulz, Jonas Karlman
In-Reply-To: <DHTSOV43O2EX.38TGASN7SQEZL@cknow-tech.com>
On 2026/4/15 22:23, Diederik de Haas wrote:
> On Wed Apr 1, 2026 at 3:11 PM CEST, Diederik de Haas wrote:
>> The various snps,reset-* properties are deprecated, so convert them into
>> their replacements.
>>
>> Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
>> index 90ce6f0e1dcf..92d044ec696b 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
>> @@ -85,10 +85,6 @@ &gmac0_tx_bus2
>> &gmac0_rx_bus2
>> &gmac0_rgmii_clk
>> &gmac0_rgmii_bus>;
>> - snps,reset-gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_LOW>;
>> - snps,reset-active-low;
>> - /* Reset time is 15ms, 50ms for rtl8211f */
>> - snps,reset-delays-us = <0 15000 50000>;
>> tx_delay = <0x3c>;
>> rx_delay = <0x2f>;
>> status = "okay";
>> @@ -100,6 +96,9 @@ rgmii_phy0: ethernet-phy@1 {
>> reg = <1>;
>> pinctrl-0 = <&gmac0_rstn_gpio0_c5_pin>;
>> pinctrl-names = "default";
>> + reset-assert-us = <15000>;
>> + reset-deassert-us = <50000>;
>> + reset-gpios = <&gpio0 RK_PC5 GPIO_ACTIVE_LOW>;
>> };
>> };
>>
>
> Please disregard/drop this patch.
>
> I was recently made aware of 'sashiko.dev' and checked whether it had
> also checked my patch, which it did:
> https://sashiko.dev/#/patchset/20260401131551.734456-1-diederik%40cknow-tech.com
>
> And it turns out that the concern raised is valid (thanks Quentin!), so
> this patch could introduce a regression.
> So it looks like staying with the deprecated properties is actually
> better (in this case?).
Well actually we more or less rely on U-Boot to reset the PHY first now.
Many rockchip boards in tree require a reset before the PHY can be
recognized, but we just use the generic "ethernet-phy-ieee802.3-c22"
compatible.
Another option is to move the reset props to mdio node instead of PHY
node, though.
Thanks,
Tianling.
>
> Cheers,
> Diederik
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Michael Walle @ 2026-04-20 7:22 UTC (permalink / raw)
To: Linus Walleij, Yu-Chun Lin [林祐君]
Cc: Bartosz Golaszewski, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸]
In-Reply-To: <CAD++jLkpS-T9yK=ctSwpLvXkj7s7ivmwu1KKwzy4KS40LVYeyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3744 bytes --]
Hi,
On Sun Apr 19, 2026 at 11:19 PM CEST, Linus Walleij wrote:
> Hi Yu-Chun,
>
> On Fri, Apr 10, 2026 at 11:39 AM Yu-Chun Lin [林祐君]
> <eleanor.lin@realtek.com> wrote:
>
>> We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
>> our platform due to the specific hardware design:
>>
>> 1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
>> into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
>> register for each individual GPIO. This single register controls the
>> input/output state, direction, and interrupt trigger type for that specific pin.
>
> Isn't that attainable by:
>
> - setting .ngpio_per_reg to 1 in struct gpio_regmap_config
Which is just used by the gpio_regmap_simple_xlate() anyway. So it
doesn't really matter. But yeah, 1 would be the correct value here,
assuming that the registers are consecutive.
> - extend .reg_mask_xlate callback with an enum for each operation
> (need to change all users of the .reg_mask_xlate callback but
> who cares, they are not many):
>
> e.g.
>
> enum gpio_regmap_operation {
> GPIO_REGMAP_GET_OP,
> GPIO_REGMAP_SET_OP,
> GPIO_REGMAP_SET_WITH_CLEAR_OP,
> GPIO_REGMAP_GET_DIR_OP,
> GPIO_REGMAP_SET_DIR_OP,
> };
>
> int (*reg_mask_xlate)(struct gpio_regmap *gpio,
> enum_gpio_regmap_operation op,
> unsigned int base,
> unsigned int offset, unsigned int *reg,
> unsigned int *mask);
>
> This way .reg_mask_xlate() can hit different bits in the returned
> *mask depending on operation and it will be find to pack all of
> the bits into one 32bit register.
>
> Added Michael Walle to the the thread, he will know if this is a
> good idea.
Nice idea, though the information is then redundant in the usual
case, i.e. drivers which need to translate specific registers
will do a "switch (base)" at the moment. These should be converted
to "switch (op)" just to keep all the drivers aligned and prevent
new drivers from using the old method. You'd need to touch them
anyway.
I was briefly thinking about making it somewhat possible to embed
the op into the base, if it would otherwise be all the same. That
way, you could gpio-regmap as is. A special case like
GPIO_REGMAP_ADDR_ZERO, that could be used by these kind of drivers,
but that is probably too hacky.
I'm fine with either way.
>> 2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
>> mask to be written simultaneously when updating the register values.
>
> Which is to just set bit 31.
>
> With the above scheme your .reg_mask_xlate callback can just set bit 31
> no matter what operating you're doing. Piece of cake.
Keep in mind, that this will make reading and writing somewhat
different. reading assumes there is only one bit set in mask,
because of the "!!(val & mask)" op, which is hardcoded. I'm not
against using the write like that though.
-michael
>> 3. Hardware Debounce: We also need to support hardware debounce settings per pin,
>> which requires custom configuration via set_config mapped to these specific per-pin
>> registers.
>
> Just add a version of an optional .set_config() call to gpio-regmap.c
> to handle this using .reg_mask_xlate() per above and add a new
> GPIO_REGMAP_CONFIG_OP to the above enum, problem solved.
>
> If it seems too hard I can write patch 1 & 2 adding this infrastructure
> but I bet you can easily see what can be done with gpio-regmap.c
> here provided Michael W approves the idea.
>
> Yours,
> Linus Walleij
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Billy Tsai @ 2026-04-20 7:22 UTC (permalink / raw)
To: Conor Dooley
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: <20260417-anemia-borrower-fb90ac02b417@spud>
> > > > + properties:
> > > > + function:
> > > > + enum:
> > > > + - EMMC
> > > > + - JTAGDDR
> > > > + - JTAGM0
> > > > + - JTAGPCIEA
> > > > + - JTAGPCIEB
> > > > + - JTAGPSP
> > > > + - JTAGSSP
> > > > + - JTAGTSP
> > > > + - JTAGUSB3A
> > > > + - JTAGUSB3B
> > > > + - PCIERC0PERST
> > > > + - PCIERC1PERST
> > > > + - TSPRSTN
> > > > + - UFSCLKI
> > > > + - USB2AD0
> > > > + - USB2AD1
> > > > + - USB2AH
> > > > + - USB2AHP
> > > > + - USB2AHPD0
> > > > + - USB2AXH
> > > > + - USB2AXH2B
> > > > + - USB2AXHD1
> > > > + - USB2AXHP
> > > > + - USB2AXHP2B
> > > > + - USB2AXHPD1
> > > > + - USB2BD0
> > > > + - USB2BD1
> > > > + - USB2BH
> > > > + - USB2BHP
> > > > + - USB2BHPD0
> > > > + - USB2BXH
> > > > + - USB2BXH2A
> > > > + - USB2BXHD1
> > > > + - USB2BXHP
> > > > + - USB2BXHP2A
> > > > + - USB2BXHPD1
> > > > + - USB3AXH
> > > > + - USB3AXH2B
> > > > + - USB3AXHD
> > > > + - USB3AXHP
> > > > + - USB3AXHP2B
> > > > + - USB3AXHPD
> > > > + - USB3BXH
> > > > + - USB3BXH2A
> > > > + - USB3BXHD
> > > > + - USB3BXHP
> > > > + - USB3BXHP2A
> > > > + - USB3BXHPD
> > > > + - VB
> > > > + - VGADDC
> > > > +
> > > > + groups:
> > > > + enum:
> > > > + - EMMCCDN
> > > > + - EMMCG1
> > > > + - EMMCG4
> > > > + - EMMCG8
> > > > + - EMMCWPN
> > > > + - JTAG0
> > > > + - PCIERC0PERST
> > > > + - PCIERC1PERST
> > > > + - TSPRSTN
> > > > + - UFSCLKI
> > > > + - USB2A
> > > > + - USB2AAP
> > > > + - USB2ABP
> > > > + - USB2ADAP
> > > > + - USB2AH
> > > > + - USB2AHAP
> > > > + - USB2B
> > > > + - USB2BAP
> > > > + - USB2BBP
> > > > + - USB2BDBP
> > > > + - USB2BH
> > > > + - USB2BHBP
> > > > + - USB3A
> > > > + - USB3AAP
> > > > + - USB3ABP
> > > > + - USB3B
> > > > + - USB3BAP
> > > > + - USB3BBP
> > > > + - VB0
> > > > + - VB1
> > > > + - VGADDC
> > > > + pins:
> > > > + enum:
> > > > + - AB13
> > > > + - AB14
> > > > + - AC13
> > > > + - AC14
> > > > + - AD13
> > > > + - AD14
> > > > + - AE13
> > > > + - AE14
> > > > + - AE15
> > > > + - AF13
> > > > + - AF14
> > > > + - AF15
> > > Why do you have groups and pins?
> > > Is it valid in your device to have groups and pins in the same node?
> > The intent is to support both group-based mux selection and
> > configuration, as well as per-pin configuration.
> > In our hardware:
> > - `function` + `groups` are used for pinmux selection.
> > - `pins` is used for per-pin configuration (e.g. drive strength,
> > bias settings).
> > - `groups` may also be used for group-level configuration.
> > As a result, both `groups` and `pins` may appear in the same node,
> > but they serve different purposes and do not conflict:
> > - `groups` selects the mux function and may apply configuration to
> > the entire group.
> > - `pins` allows overriding or specifying configuration for individual
> > pins.
> > In most cases, only one of them is needed, but both are allowed when
> > both group-level and per-pin configuration are required.
> To be honest, that sounds like your groups are not sufficiently
> granular and should be reduced such that you can use them for pin
> settings.
The intent was to keep the binding flexible, but in practice the mixed
use of `groups` and `pins` in the same node is not expected to be used.
Given that, I agree this flexibility is unnecessary and makes the
binding semantics less clear. I'll rework the binding to make the
expected usage explicit rather than allowing combinations that do not
correspond to a real use case.
In particular, I'll split the constraints as follows:
- For pinmux, the presence of `function` will require `groups`, and
`pins` will not be allowed. This reflects the hardware design, where
the groups are defined by the pins affected by a given mux expression
- For pin configuration, exactly one of `groups` or `pins` will be
required (using oneOf), so that configuration is applied either at
group level or per-pin, but not both.
- if:
required:
- function
then:
required:
- groups
not:
required:
- pins
else:
oneOf:
- required:
- groups
not:
required:
- pins
- required:
- pins
not:
required:
- groups
Does this match what you had in mind?
Thanks
Billy Tsai
^ permalink raw reply
* [PATCH 0/2] Add PMAU0102 RPMH regulator support
From: Shawn Guo @ 2026-04-20 7:26 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Kamal Wadhwa, Bartosz Golaszewski, Deepti Jaggi,
devicetree, linux-arm-msm, linux-kernel, Shawn Guo
This series adds RPMH regulator support for PMAU0102 PMIC found on
Qualcomm Nord SoC based devices.
Patch 1 adds the PMAU0102 compatible to the dt-bindings for
qcom,rpmh-regulator, documenting its 8 SMPSes and 3 LDOs.
Patch 2 adds the corresponding vreg data to the rpmh-regulator driver.
Kamal Wadhwa (1):
regulator: rpmh-regulator: Add RPMH regulator support for Nord
Shawn Guo (1):
regulator: dt-bindings: qcom,rpmh: Add PMAU0102 support
.../regulator/qcom,rpmh-regulator.yaml | 11 +++++++++++
drivers/regulator/qcom-rpmh-regulator.c | 19 +++++++++++++++++++
2 files changed, 30 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] regulator: dt-bindings: qcom,rpmh: Add PMAU0102 support
From: Shawn Guo @ 2026-04-20 7:26 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Kamal Wadhwa, Bartosz Golaszewski, Deepti Jaggi,
devicetree, linux-arm-msm, linux-kernel, Shawn Guo
In-Reply-To: <20260420072639.1249984-1-shengchao.guo@oss.qualcomm.com>
Add support for PMAU0102 PMIC used on Nord boards.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../bindings/regulator/qcom,rpmh-regulator.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
index 58bb0ad5dda4..cd5391892fc6 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
@@ -51,6 +51,7 @@ description: |
For PM8450, smps1 - smps6, ldo1 - ldo4
For PM8550, smps1 - smps6, ldo1 - ldo17, bob1 - bob2
For PM8998, smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+ For PMAU0102, smps1 - smps8, ldo1 - ldo3
For PMH0101, ldo1 - ldo18, bob1 - bob2
For PMH0104, smps1 - smps4
For PMH0110, smps1 - smps10, ldo1 - ldo4
@@ -87,6 +88,7 @@ properties:
- qcom,pm8550ve-rpmh-regulators
- qcom,pm8550vs-rpmh-regulators
- qcom,pm8998-rpmh-regulators
+ - qcom,pmau0102-rpmh-regulators
- qcom,pmc8180-rpmh-regulators
- qcom,pmc8180c-rpmh-regulators
- qcom,pmc8380-rpmh-regulators
@@ -413,6 +415,15 @@ allOf:
patternProperties:
"^vdd-s([1-9]|1[0-3])-supply$": true
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,pmau0102-rpmh-regulators
+ then:
+ patternProperties:
+ "^vdd-s[1-8]-supply$": true
+
- if:
properties:
compatible:
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] regulator: rpmh-regulator: Add RPMH regulator support for Nord
From: Shawn Guo @ 2026-04-20 7:26 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Kamal Wadhwa, Bartosz Golaszewski, Deepti Jaggi,
devicetree, linux-arm-msm, linux-kernel, Shawn Guo
In-Reply-To: <20260420072639.1249984-1-shengchao.guo@oss.qualcomm.com>
From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Add support for PMAU0102 PMIC voltage regulators which are present on
Nord boards.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
drivers/regulator/qcom-rpmh-regulator.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
index 6e4cb2871fca..9545300d7b03 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -1100,6 +1100,21 @@ static const struct rpmh_vreg_init_data pm8998_vreg_data[] = {
{}
};
+static const struct rpmh_vreg_init_data pmau0102_vreg_data[] = {
+ RPMH_VREG("smps1", SMPS, 1, &pmic5_ftsmps527, "vdd-s1"),
+ RPMH_VREG("smps2", SMPS, 2, &pmic5_ftsmps527, "vdd-s2"),
+ RPMH_VREG("smps3", SMPS, 3, &pmic5_ftsmps527, "vdd-s3"),
+ RPMH_VREG("smps4", SMPS, 4, &pmic5_ftsmps527, "vdd-s4"),
+ RPMH_VREG("smps5", SMPS, 5, &pmic5_ftsmps527, "vdd-s5"),
+ RPMH_VREG("smps6", SMPS, 6, &pmic5_ftsmps527, "vdd-s6"),
+ RPMH_VREG("smps7", SMPS, 7, &pmic5_ftsmps527, "vdd-s7"),
+ RPMH_VREG("smps8", SMPS, 8, &pmic5_ftsmps527, "vdd-s8"),
+ RPMH_VREG("ldo1", LDO, 1, &pmic5_nldo515, NULL),
+ RPMH_VREG("ldo2", LDO, 2, &pmic5_nldo515, NULL),
+ RPMH_VREG("ldo3", LDO, 3, &pmic5_pldo515_mv, NULL),
+ {}
+};
+
static const struct rpmh_vreg_init_data pmg1110_vreg_data[] = {
RPMH_VREG("smps1", SMPS, 1, &pmic5_ftsmps510, "vdd-s1"),
{}
@@ -1877,6 +1892,10 @@ static const struct of_device_id __maybe_unused rpmh_regulator_match_table[] = {
.compatible = "qcom,pm8998-rpmh-regulators",
.data = pm8998_vreg_data,
},
+ {
+ .compatible = "qcom,pmau0102-rpmh-regulators",
+ .data = pmau0102_vreg_data,
+ },
{
.compatible = "qcom,pmg1110-rpmh-regulators",
.data = pmg1110_vreg_data,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 5/5] arch: arm64: dts: qcom: Add support for PCIe3a
From: Qiang Yu @ 2026-04-20 7:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <d486616b-ef21-4933-aaf5-dcba339dd8cc@kernel.org>
On Thu, Apr 16, 2026 at 08:19:09AM +0200, Krzysztof Kozlowski wrote:
> On 16/04/2026 05:24, Qiang Yu wrote:
> > On Wed, Apr 15, 2026 at 09:44:15AM +0200, Krzysztof Kozlowski wrote:
> >> On Sun, Apr 12, 2026 at 11:26:00PM -0700, Qiang Yu wrote:
> >>> Describe PCIe3a controller and PHY. Also add required system resources
> >>> like regulators, clocks, interrupts and registers configuration for PCIe3a.
> >>>
> >>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>
> >> subject: drop arch.
> >>
> >> Please use subject prefixes matching the subsystem. You can get them for
> >> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
> >> your patch is touching. For bindings, the preferred subjects are
> >> explained here:
> >> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
> >>
> >
> > Thanks for pointing me the link. I’ll drop arch: in next version.
> >
> >>> ---
> >>> arch/arm64/boot/dts/qcom/glymur.dtsi | 316 ++++++++++++++++++++++++++++++++++-
> >>> 1 file changed, 315 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> >>> index f23cf81ddb77a4138deeb4e00dd8b316930a2feb..c15f87c37ecbad72076a6c731f4959a1a8bd8425 100644
> >>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> >>> @@ -736,7 +736,7 @@ gcc: clock-controller@100000 {
> >>> <0>, /* USB 2 Phy PCIE PIPEGMUX */
> >>> <0>, /* USB 2 Phy PIPEGMUX */
> >>> <0>, /* USB 2 Phy SYS PCIE PIPEGMUX */
> >>> - <0>, /* PCIe 3a */
> >>> + <&pcie3a_phy>, /* PCIe 3a */
> >>> <&pcie3b_phy>, /* PCIe 3b */
> >>> <&pcie4_phy>, /* PCIe 4 */
> >>> <&pcie5_phy>, /* PCIe 5 */
> >>> @@ -3640,6 +3640,320 @@ pcie3b_port0: pcie@0 {
> >>> };
> >>
> >> ...
> >>
> >>>> + pcie3a_phy: phy@f00000 {
> >>
> >> Same comment as before.
> >>
> >
> > The existing PCIe/PHY nodes are not strictly ordered by address. Current
> > order is:
>
> Obviously we cannot even keep order of nodes when creating a new DTSI
> file from scratch.
>
> But adding @f00000 after @1c10000 makes even less sense, regardless how
> bad existing code is. Don't make it worse!
>
> This goes before phy@fa0000
Okay, will move phy@f00000 before phy@fa0000
- Qiang Yu
>
> >
> > - pcie4: pci@1bf0000
> > - pcie4_phy: phy@1bf6000
> > - pcie5: pci@1b40000
> > - pcie5_phy: phy@1b50000
> > - pcie6: pci@1c00000
> > - pcie6_phy: phy@1c06000
> > - pcie3b: pci@1b80000
> > - pcie3a: pci@1c10000 (added in this patch)
> > - pcie3a_phy: phy@f00000 (added in this patch)
> > - pcie3b_phy: phy@f10000
> >
> > Do you want me to reorder these nodes to follow strict address order?
>
> No, but don't add nodes randomly or following the previous broken order.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: crypto: qcom,inline-crypto-engine: Document Nord ICE
From: Shawn Guo @ 2026-04-20 7:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-crypto, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
Add compatible for Inline Crypto Engine (ICE) on Qualcomm Nord SoC
witha fallback on qcom,inline-crypto-engine.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index 876bf90ed96e..9251db2b8fcd 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -16,6 +16,7 @@ properties:
- qcom,eliza-inline-crypto-engine
- qcom,kaanapali-inline-crypto-engine
- qcom,milos-inline-crypto-engine
+ - qcom,nord-inline-crypto-engine
- qcom,qcs8300-inline-crypto-engine
- qcom,sa8775p-inline-crypto-engine
- qcom,sc7180-inline-crypto-engine
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] clk: qcom: Add common clkref support and migrate Glymur
From: Qiang Yu @ 2026-04-20 7:42 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu
This series adds a common clkref_en implementation and converts glymur to
use it, along with the related binding and DTS updates.
The PCIe clkref clocks on Glymur gate the QREF block which provides
reference clocks to the PCIe PHYs. QREF requires LDO supplies and a
reference voltage from the refgen block to operate. The refgen block
itself requires vdda-refgen_0p9 and vdda-refgen_1p2 LDOs to function.
Previously, these QREF votes were done in PHY drivers. In earlier
discussion [1], the feedback was that this is the wrong ownership point:
those supplies are for the QREF controlled by clkref registers, not for
PHY directly. Based on that feedback, this series keeps the regulator
handling with the clkref control path.
Another reason for this series is reuse. clkref_en registers may live in
different blocks across platforms (for example TCSR on Glymur, TLMM on
SM8750 [2]), while the behavior is the same. The common helper lets each
driver provide simple descriptors (name, offset, optional supplies) and
reuse shared registration and runtime logic.
[1] https://lore.kernel.org/lkml/aEBfV2M-ZqDF7aRz@hovoldconsulting.com/
[2] https://lore.kernel.org/linux-arm-msm/20260202-topic-8750_tcsr-v1-0-cd7e6648c64f@oss.qualcomm.com/
Changes in v2:
- RFC tag dropped
- Changed back to additionalProperties: false
- Moved all Glymur supply properties into top-level properties so they are explicitly defined.
- Link to v1: https://lore.kernel.org/all/20260331-qref_vote-v1-0-3fd7fbf87864@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Qiang Yu (4):
dt-bindings: clock: qcom: Add QREF regulator supplies for glymur
clk: qcom: Add generic clkref_en support
clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
.../bindings/clock/qcom,sm8550-tcsr.yaml | 40 +++
arch/arm64/boot/dts/qcom/glymur-crd.dts | 19 ++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-ref.c | 202 ++++++++++++
drivers/clk/qcom/tcsrcc-glymur.c | 340 ++++++---------------
include/linux/clk/qcom.h | 69 +++++
6 files changed, 424 insertions(+), 247 deletions(-)
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260419-vote_qref_in_tcsrcc-c015dc0c2ae8
Best regards,
--
Qiang Yu <qiang.yu@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur
From: Qiang Yu @ 2026-04-20 7:42 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com>
Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
required by clkref clocks.
The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
QREF TX/RPT/RX components, while SoC-specific topology and instance count
differ. Document them here for qcom,glymur-tcsr.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../bindings/clock/qcom,sm8550-tcsr.yaml | 40 ++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
index 1ccdf4b0f5dd..0cf612e6d7ee 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
@@ -51,6 +51,46 @@ properties:
'#reset-cells':
const: 1
+ vdda-refgen-0p9-supply: true
+ vdda-refgen-1p2-supply: true
+ vdda-qrefrx0-0p9-supply: true
+ vdda-qrefrx1-0p9-supply: true
+ vdda-qrefrx2-0p9-supply: true
+ vdda-qrefrx4-0p9-supply: true
+ vdda-qrefrx5-0p9-supply: true
+ vdda-qreftx0-0p9-supply: true
+ vdda-qreftx0-1p2-supply: true
+ vdda-qreftx1-0p9-supply: true
+ vdda-qrefrpt0-0p9-supply: true
+ vdda-qrefrpt1-0p9-supply: true
+ vdda-qrefrpt2-0p9-supply: true
+ vdda-qrefrpt3-0p9-supply: true
+ vdda-qrefrpt4-0p9-supply: true
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,glymur-tcsr
+ else:
+ properties:
+ vdda-refgen-0p9-supply: false
+ vdda-refgen-1p2-supply: false
+ vdda-qrefrx0-0p9-supply: false
+ vdda-qrefrx1-0p9-supply: false
+ vdda-qrefrx2-0p9-supply: false
+ vdda-qrefrx4-0p9-supply: false
+ vdda-qrefrx5-0p9-supply: false
+ vdda-qreftx0-0p9-supply: false
+ vdda-qreftx0-1p2-supply: false
+ vdda-qreftx1-0p9-supply: false
+ vdda-qrefrpt0-0p9-supply: false
+ vdda-qrefrpt1-0p9-supply: false
+ vdda-qrefrpt2-0p9-supply: false
+ vdda-qrefrpt3-0p9-supply: false
+ vdda-qrefrpt4-0p9-supply: false
+
required:
- compatible
- clocks
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] clk: qcom: Add generic clkref_en support
From: Qiang Yu @ 2026-04-20 7:42 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com>
Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
register controls whether refclk is gated through to the PHY side.
These clkref controls are different from typical GCC branch clocks:
- only a single enable bit is present, without branch-style config bits
- regulators must be voted before enable and unvoted after disable
Model this as a dedicated clk_ref clock type with custom clk_ops instead
of reusing struct clk_branch semantics.
Also provide a common registration/probe API so the same clkref model
can be reused regardless of where clkref_en registers are placed, e.g.
TCSR on glymur and TLMM on SM8750.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-ref.c | 202 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/clk/qcom.h | 69 ++++++++++++++++
3 files changed, 272 insertions(+)
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 89d07c35e4d9..1659e9d9afa9 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -8,6 +8,7 @@ clk-qcom-y += clk-pll.o
clk-qcom-y += clk-rcg.o
clk-qcom-y += clk-rcg2.o
clk-qcom-y += clk-branch.o
+clk-qcom-y += clk-ref.o
clk-qcom-y += clk-regmap-divider.o
clk-qcom-y += clk-regmap-mux.o
clk-qcom-y += clk-regmap-mux-div.o
diff --git a/drivers/clk/qcom/clk-ref.c b/drivers/clk/qcom/clk-ref.c
new file mode 100644
index 000000000000..ea2ed03460f2
--- /dev/null
+++ b/drivers/clk/qcom/clk-ref.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk/qcom.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#define QCOM_CLK_REF_EN_MASK BIT(0)
+
+struct qcom_clk_ref_provider {
+ struct qcom_clk_ref *refs;
+ size_t num_refs;
+};
+
+static inline struct qcom_clk_ref *to_qcom_clk_ref(struct clk_hw *hw)
+{
+ return container_of(hw, struct qcom_clk_ref, hw);
+}
+
+static const struct clk_parent_data qcom_clk_ref_parent_data = {
+ .index = 0,
+};
+
+static int qcom_clk_ref_prepare(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+ int ret;
+
+ if (!rclk->desc.num_regulators)
+ return 0;
+
+ ret = regulator_bulk_enable(rclk->desc.num_regulators, rclk->regulators);
+ if (ret)
+ pr_err("Failed to enable regulators for %s: %d\n",
+ clk_hw_get_name(hw), ret);
+
+ return ret;
+}
+
+static void qcom_clk_ref_unprepare(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+
+ if (rclk->desc.num_regulators)
+ regulator_bulk_disable(rclk->desc.num_regulators, rclk->regulators);
+}
+
+static int qcom_clk_ref_enable(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+ int ret;
+
+ ret = regmap_update_bits(rclk->regmap, rclk->desc.offset, QCOM_CLK_REF_EN_MASK,
+ QCOM_CLK_REF_EN_MASK);
+ if (ret)
+ return ret;
+
+ udelay(10);
+
+ return 0;
+}
+
+static void qcom_clk_ref_disable(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+
+ regmap_update_bits(rclk->regmap, rclk->desc.offset, QCOM_CLK_REF_EN_MASK, 0);
+ udelay(10);
+}
+
+static int qcom_clk_ref_is_enabled(struct clk_hw *hw)
+{
+ struct qcom_clk_ref *rclk = to_qcom_clk_ref(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(rclk->regmap, rclk->desc.offset, &val);
+ if (ret)
+ return ret;
+
+ return !!(val & QCOM_CLK_REF_EN_MASK);
+}
+
+static const struct clk_ops qcom_clk_ref_ops = {
+ .prepare = qcom_clk_ref_prepare,
+ .unprepare = qcom_clk_ref_unprepare,
+ .enable = qcom_clk_ref_enable,
+ .disable = qcom_clk_ref_disable,
+ .is_enabled = qcom_clk_ref_is_enabled,
+};
+
+static int qcom_clk_ref_register(struct device *dev, struct regmap *regmap,
+ struct qcom_clk_ref *clk_refs,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs)
+{
+ const struct qcom_clk_ref_desc *desc;
+ struct qcom_clk_ref *clk_ref;
+ size_t clk_idx;
+ unsigned int i;
+ int ret;
+
+ for (clk_idx = 0; clk_idx < num_clk_refs; clk_idx++) {
+ clk_ref = &clk_refs[clk_idx];
+ desc = &descs[clk_idx];
+
+ if (!desc->name)
+ return -EINVAL;
+
+ clk_ref->regmap = regmap;
+ clk_ref->desc = *desc;
+
+ if (clk_ref->desc.num_regulators) {
+ clk_ref->regulators = devm_kcalloc(dev, clk_ref->desc.num_regulators,
+ sizeof(*clk_ref->regulators),
+ GFP_KERNEL);
+ if (!clk_ref->regulators)
+ return -ENOMEM;
+
+ for (i = 0; i < clk_ref->desc.num_regulators; i++)
+ clk_ref->regulators[i].supply =
+ clk_ref->desc.regulator_names[i];
+
+ ret = devm_regulator_bulk_get(dev, clk_ref->desc.num_regulators,
+ clk_ref->regulators);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to get regulators for %s\n",
+ clk_ref->desc.name);
+ }
+
+ clk_ref->init_data.name = clk_ref->desc.name;
+ clk_ref->init_data.parent_data = &qcom_clk_ref_parent_data;
+ clk_ref->init_data.num_parents = 1;
+ clk_ref->init_data.ops = &qcom_clk_ref_ops;
+ clk_ref->hw.init = &clk_ref->init_data;
+
+ ret = devm_clk_hw_register(dev, &clk_ref->hw);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct clk_hw *qcom_clk_ref_provider_get(struct of_phandle_args *clkspec, void *data)
+{
+ struct qcom_clk_ref_provider *provider = data;
+ unsigned int idx = clkspec->args[0];
+
+ if (idx >= provider->num_refs)
+ return ERR_PTR(-EINVAL);
+
+ return &provider->refs[idx].hw;
+}
+
+int qcom_clk_ref_probe(struct platform_device *pdev,
+ const struct regmap_config *config,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs)
+{
+ struct qcom_clk_ref_provider *provider;
+ struct device *dev = &pdev->dev;
+ struct regmap *regmap;
+ void __iomem *base;
+ int ret;
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ regmap = devm_regmap_init_mmio(dev, base, config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
+ if (!provider)
+ return -ENOMEM;
+
+ provider->refs = devm_kcalloc(dev, num_clk_refs, sizeof(*provider->refs),
+ GFP_KERNEL);
+ if (!provider->refs)
+ return -ENOMEM;
+
+ provider->num_refs = num_clk_refs;
+
+ ret = qcom_clk_ref_register(dev, regmap, provider->refs, descs,
+ provider->num_refs);
+ if (ret)
+ return ret;
+
+ return devm_of_clk_add_hw_provider(dev, qcom_clk_ref_provider_get, provider);
+}
+EXPORT_SYMBOL_GPL(qcom_clk_ref_probe);
diff --git a/include/linux/clk/qcom.h b/include/linux/clk/qcom.h
new file mode 100644
index 000000000000..09e2e3178cfb
--- /dev/null
+++ b/include/linux/clk/qcom.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef __LINUX_CLK_QCOM_H
+#define __LINUX_CLK_QCOM_H
+
+#include <linux/clk-provider.h>
+#include <linux/errno.h>
+#include <linux/kconfig.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct device;
+struct platform_device;
+struct regulator_bulk_data;
+
+/**
+ * struct qcom_clk_ref_desc - descriptor for a clkref_en gate clock
+ * @name: clock name exposed to the common clock framework
+ * @offset: clkref_en register offset from the block base
+ * @regulator_names: optional supply names enabled while preparing the clock
+ * @num_regulators: number of entries in @regulator_names
+ */
+struct qcom_clk_ref_desc {
+ const char *name;
+ u32 offset;
+ const char * const *regulator_names;
+ unsigned int num_regulators;
+};
+
+/**
+ * struct qcom_clk_ref - per-clock data for a clkref_en gate clock
+ * @hw: common clock framework hardware clock handle
+ * @init_data: common clock framework registration data
+ * @regmap: register map backing the clkref_en register
+ * @desc: clock descriptor copied at registration time
+ * @regulators: optional bulk regulator handles for @desc.regulator_names
+ */
+struct qcom_clk_ref {
+ struct clk_hw hw;
+ struct clk_init_data init_data;
+ struct regmap *regmap;
+ struct qcom_clk_ref_desc desc;
+ struct regulator_bulk_data *regulators;
+};
+
+#if IS_ENABLED(CONFIG_COMMON_CLK_QCOM)
+
+int qcom_clk_ref_probe(struct platform_device *pdev,
+ const struct regmap_config *config,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs);
+
+#else
+
+static inline int
+qcom_clk_ref_probe(struct platform_device *pdev,
+ const struct regmap_config *config,
+ const struct qcom_clk_ref_desc *descs,
+ size_t num_clk_refs)
+{
+ return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
From: Qiang Yu @ 2026-04-20 7:42 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com>
Replace local clk_branch-based clkref definitions with descriptor-based
registration via qcom_clk_ref_probe().
This keeps the glymur driver focused on clock metadata and reuses common
runtime logic for regulator handling, enable/disable sequencing, and OF
provider wiring.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/clk/qcom/tcsrcc-glymur.c | 340 +++++++++++----------------------------
1 file changed, 93 insertions(+), 247 deletions(-)
diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
index 9c0edebcdbb1..585f87b23af2 100644
--- a/drivers/clk/qcom/tcsrcc-glymur.c
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@ -4,265 +4,115 @@
*/
#include <linux/clk-provider.h>
+#include <linux/clk/qcom.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <dt-bindings/clock/qcom,glymur-tcsr.h>
-#include "clk-alpha-pll.h"
-#include "clk-branch.h"
-#include "clk-pll.h"
-#include "clk-rcg.h"
-#include "clk-regmap.h"
-#include "clk-regmap-divider.h"
-#include "clk-regmap-mux.h"
-#include "common.h"
-#include "gdsc.h"
-#include "reset.h"
-
-enum {
- DT_BI_TCXO_PAD,
-};
-
-static struct clk_branch tcsr_edp_clkref_en = {
- .halt_reg = 0x60,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x60,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_edp_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+static const char * const tcsr_pcie_1_regulators[] = {
+ "vdda-refgen-0p9",
+ "vdda-refgen-1p2",
+ "vdda-qrefrx5-0p9",
+ "vdda-qreftx0-0p9",
+ "vdda-qreftx0-1p2",
+};
+
+static const char * const tcsr_pcie_2_regulators[] = {
+ "vdda-refgen-0p9",
+ "vdda-refgen-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrpt2-0p9",
+ "vdda-qrefrx2-0p9",
+};
+
+static const char * const tcsr_pcie_3_regulators[] = {
+ "vdda-refgen-0p9",
+ "vdda-refgen-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrx1-0p9",
+};
+
+static const char * const tcsr_pcie_4_regulators[] = {
+ "vdda-refgen-0p9",
+ "vdda-refgen-1p2",
+ "vdda-qreftx1-0p9",
+ "vdda-qrefrpt0-0p9",
+ "vdda-qrefrpt1-0p9",
+ "vdda-qrefrpt2-0p9",
+ "vdda-qrefrx2-0p9",
+};
+
+static const struct qcom_clk_ref_desc tcsr_cc_glymur_clk_descs[] = {
+ [TCSR_EDP_CLKREF_EN] = {
+ .name = "tcsr_edp_clkref_en",
+ .offset = 0x60,
},
-};
-
-static struct clk_branch tcsr_pcie_1_clkref_en = {
- .halt_reg = 0x48,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x48,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_1_CLKREF_EN] = {
+ .name = "tcsr_pcie_1_clkref_en",
+ .offset = 0x48,
+ .regulator_names = tcsr_pcie_1_regulators,
+ .num_regulators = ARRAY_SIZE(tcsr_pcie_1_regulators),
},
-};
-
-static struct clk_branch tcsr_pcie_2_clkref_en = {
- .halt_reg = 0x4c,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x4c,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_2_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_2_CLKREF_EN] = {
+ .name = "tcsr_pcie_2_clkref_en",
+ .offset = 0x4c,
+ .regulator_names = tcsr_pcie_2_regulators,
+ .num_regulators = ARRAY_SIZE(tcsr_pcie_2_regulators),
},
-};
-
-static struct clk_branch tcsr_pcie_3_clkref_en = {
- .halt_reg = 0x54,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x54,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_3_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_3_CLKREF_EN] = {
+ .name = "tcsr_pcie_3_clkref_en",
+ .offset = 0x54,
+ .regulator_names = tcsr_pcie_3_regulators,
+ .num_regulators = ARRAY_SIZE(tcsr_pcie_3_regulators),
},
-};
-
-static struct clk_branch tcsr_pcie_4_clkref_en = {
- .halt_reg = 0x58,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x58,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_pcie_4_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_PCIE_4_CLKREF_EN] = {
+ .name = "tcsr_pcie_4_clkref_en",
+ .offset = 0x58,
+ .regulator_names = tcsr_pcie_4_regulators,
+ .num_regulators = ARRAY_SIZE(tcsr_pcie_4_regulators),
},
-};
-
-static struct clk_branch tcsr_usb2_1_clkref_en = {
- .halt_reg = 0x6c,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x6c,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_1_CLKREF_EN] = {
+ .name = "tcsr_usb2_1_clkref_en",
+ .offset = 0x6c,
},
-};
-
-static struct clk_branch tcsr_usb2_2_clkref_en = {
- .halt_reg = 0x70,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x70,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_2_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_2_CLKREF_EN] = {
+ .name = "tcsr_usb2_2_clkref_en",
+ .offset = 0x70,
},
-};
-
-static struct clk_branch tcsr_usb2_3_clkref_en = {
- .halt_reg = 0x74,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x74,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_3_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_3_CLKREF_EN] = {
+ .name = "tcsr_usb2_3_clkref_en",
+ .offset = 0x74,
},
-};
-
-static struct clk_branch tcsr_usb2_4_clkref_en = {
- .halt_reg = 0x88,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x88,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb2_4_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB2_4_CLKREF_EN] = {
+ .name = "tcsr_usb2_4_clkref_en",
+ .offset = 0x88,
},
-};
-
-static struct clk_branch tcsr_usb3_0_clkref_en = {
- .halt_reg = 0x64,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x64,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb3_0_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB3_0_CLKREF_EN] = {
+ .name = "tcsr_usb3_0_clkref_en",
+ .offset = 0x64,
},
-};
-
-static struct clk_branch tcsr_usb3_1_clkref_en = {
- .halt_reg = 0x68,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x68,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb3_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB3_1_CLKREF_EN] = {
+ .name = "tcsr_usb3_1_clkref_en",
+ .offset = 0x68,
},
-};
-
-static struct clk_branch tcsr_usb4_1_clkref_en = {
- .halt_reg = 0x44,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x44,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb4_1_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB4_1_CLKREF_EN] = {
+ .name = "tcsr_usb4_1_clkref_en",
+ .offset = 0x44,
},
-};
-
-static struct clk_branch tcsr_usb4_2_clkref_en = {
- .halt_reg = 0x5c,
- .halt_check = BRANCH_HALT_DELAY,
- .clkr = {
- .enable_reg = 0x5c,
- .enable_mask = BIT(0),
- .hw.init = &(const struct clk_init_data) {
- .name = "tcsr_usb4_2_clkref_en",
- .parent_data = &(const struct clk_parent_data){
- .index = DT_BI_TCXO_PAD,
- },
- .num_parents = 1,
- .ops = &clk_branch2_ops,
- },
+ [TCSR_USB4_2_CLKREF_EN] = {
+ .name = "tcsr_usb4_2_clkref_en",
+ .offset = 0x5c,
},
};
-static struct clk_regmap *tcsr_cc_glymur_clocks[] = {
- [TCSR_EDP_CLKREF_EN] = &tcsr_edp_clkref_en.clkr,
- [TCSR_PCIE_1_CLKREF_EN] = &tcsr_pcie_1_clkref_en.clkr,
- [TCSR_PCIE_2_CLKREF_EN] = &tcsr_pcie_2_clkref_en.clkr,
- [TCSR_PCIE_3_CLKREF_EN] = &tcsr_pcie_3_clkref_en.clkr,
- [TCSR_PCIE_4_CLKREF_EN] = &tcsr_pcie_4_clkref_en.clkr,
- [TCSR_USB2_1_CLKREF_EN] = &tcsr_usb2_1_clkref_en.clkr,
- [TCSR_USB2_2_CLKREF_EN] = &tcsr_usb2_2_clkref_en.clkr,
- [TCSR_USB2_3_CLKREF_EN] = &tcsr_usb2_3_clkref_en.clkr,
- [TCSR_USB2_4_CLKREF_EN] = &tcsr_usb2_4_clkref_en.clkr,
- [TCSR_USB3_0_CLKREF_EN] = &tcsr_usb3_0_clkref_en.clkr,
- [TCSR_USB3_1_CLKREF_EN] = &tcsr_usb3_1_clkref_en.clkr,
- [TCSR_USB4_1_CLKREF_EN] = &tcsr_usb4_1_clkref_en.clkr,
- [TCSR_USB4_2_CLKREF_EN] = &tcsr_usb4_2_clkref_en.clkr,
-};
-
static const struct regmap_config tcsr_cc_glymur_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -271,11 +121,12 @@ static const struct regmap_config tcsr_cc_glymur_regmap_config = {
.fast_io = true,
};
-static const struct qcom_cc_desc tcsr_cc_glymur_desc = {
- .config = &tcsr_cc_glymur_regmap_config,
- .clks = tcsr_cc_glymur_clocks,
- .num_clks = ARRAY_SIZE(tcsr_cc_glymur_clocks),
-};
+static int tcsr_cc_glymur_probe(struct platform_device *pdev)
+{
+ return qcom_clk_ref_probe(pdev, &tcsr_cc_glymur_regmap_config,
+ tcsr_cc_glymur_clk_descs,
+ ARRAY_SIZE(tcsr_cc_glymur_clk_descs));
+}
static const struct of_device_id tcsr_cc_glymur_match_table[] = {
{ .compatible = "qcom,glymur-tcsr" },
@@ -283,11 +134,6 @@ static const struct of_device_id tcsr_cc_glymur_match_table[] = {
};
MODULE_DEVICE_TABLE(of, tcsr_cc_glymur_match_table);
-static int tcsr_cc_glymur_probe(struct platform_device *pdev)
-{
- return qcom_cc_probe(pdev, &tcsr_cc_glymur_desc);
-}
-
static struct platform_driver tcsr_cc_glymur_driver = {
.probe = tcsr_cc_glymur_probe,
.driver = {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
From: Qiang Yu @ 2026-04-20 7:42 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com>
The TCSR clkref clocks gate the QREF block which provides reference
clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
and refgen blocks on the CRD board:
- vdda-refgen_0p9/1p2: LDOs for the refgen block that generates the
reference voltage for QREF
- vdda-qrefrx/tx/rpt: LDOs for the QREF receiver, transmitter
and repeater circuits
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index 35aaf09e4e2b..382398e44296 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
@@ -358,6 +358,25 @@ &usb_1 {
status = "okay";
};
+&tcsr {
+ vdda-refgen-0p9-supply = <&vreg_l1f_e1_0p82>;
+ vdda-refgen-1p2-supply = <&vreg_l4f_e1_1p08>;
+
+ vdda-qrefrx5-0p9-supply = <&vreg_l3f_e0_0p72>;
+ vdda-qreftx0-0p9-supply = <&vreg_l3f_e0_0p72>;
+ vdda-qreftx0-1p2-supply = <&vreg_l4h_e0_1p2>;
+ vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrpt3-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qrefrx0-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
+ vdda-qrefrx4-0p9-supply = <&vreg_l2h_e0_0p72>;
+ vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
+};
+
&usb_1_dwc3_hs {
remote-endpoint = <&pmic_glink_hs_in1>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document Nord QMP UFS PHY
From: Shawn Guo @ 2026-04-20 7:49 UTC (permalink / raw)
To: Vinod Koul
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, linux-phy,
devicetree, linux-arm-msm, linux-kernel, Shawn Guo
Add compatible for QMP UFS PHY on Qualcomm Nord SoC with a fallback
on qcom,sm8650-qmp-ufs-phy.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index 9616c736b6d4..cc3457d6aa3b 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -36,6 +36,10 @@ properties:
- enum:
- qcom,kaanapali-qmp-ufs-phy
- const: qcom,sm8750-qmp-ufs-phy
+ - items:
+ - enum:
+ - qcom,nord-qmp-ufs-phy
+ - const: qcom,sm8650-qmp-ufs-phy
- enum:
- qcom,milos-qmp-ufs-phy
- qcom,msm8996-qmp-ufs-phy
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Qiang Yu @ 2026-04-20 7:23 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260417-awesome-tacky-coot-e59a30@quoll>
On Fri, Apr 17, 2026 at 11:18:08AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Apr 15, 2026 at 07:58:13PM -0700, Qiang Yu wrote:
> > On Wed, Apr 15, 2026 at 09:50:28AM +0200, Krzysztof Kozlowski wrote:
> > > On Sun, Apr 12, 2026 at 11:25:56PM -0700, Qiang Yu wrote:
> > > > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> > > >
> > > > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > > > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > > > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > > > follower to form a single 8-lane PCIe Gen5 interface
> > > >
> > > > In bifurcation mode, the hardware design requires controlling additional
> > > > resources beyond the standard pcie3a PHY configuration:
> > > >
> > > > - pcie3b's aux_clk (phy_b_aux)
> > > > - pcie3b's phy_gdsc power domain
> > > > - pcie3b's bcr/nocsr reset
> > > >
> > > > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > > > 8-lane bifurcation configuration.
> > >
> > > Do you describe PCI3A or PCI3B or something combined PCI3?
> >
> > I describe a single x8 PHY with resources from both the pcie3a and pcie3b
> > PHY blocks for x8 operation.
> >
> > >
> > > >
> > > > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > > > requiring the clock-names enum to be extended to support both
> > > > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > > > pattern used for [rchng, refgen] clocks at index 3.
> > > >
> > > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > ---
> > > > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
> > > > 1 file changed, 45 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
> > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > @@ -18,6 +18,7 @@ properties:
> > > > enum:
> > > > - qcom,glymur-qmp-gen4x2-pcie-phy
> > > > - qcom,glymur-qmp-gen5x4-pcie-phy
> > > > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > >
> > > That's the same device as 5x4, no? One device, one compatible and this
> > > suggests you will have three PCI phys in the DT - two 5x4 and one 5x8?
> > >
> >
> > It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
> > phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
>
> OK, that's what I wanted to hear. And that's what should not be done,
>
> You should not have a separate node for the same hardware. First, DTC
> will give you a W=1 warning, although warning itself should be moved to
> W=2.
>
> Second, the warning tells important story - same hardware is described
> twice.
>
> You only need phy_3a and phy_3b, so only two in total.
We can keep only phy_3a and phy_3b, but still add new compatible
qcom,glymur-qmp-gen5x8-pcie-phy in binding, right?
For boards that support pcie3a(1x4) + pcie3b(1x4), DTS would be:
pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
For boards that support 1x8, we would override pcie3a_phy with:
pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x8-pcie-phy"; /* additional resources */ };
pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
This still uses only two PHY nodes and DTC will not report warning.
- Qiang Yu
>
> phy_3a could have resources of phy_3b OR could have a phandle to
> companion (follower) phy to fetch resources from it. I don't know yet
> which choice is better, though.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: Harshal Dev @ 2026-04-20 8:05 UTC (permalink / raw)
To: johannes.goede, Konrad Dybcio, Thara Gopinath, Herbert Xu,
David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Bartosz Golaszewski,
Udit Tiwari
In-Reply-To: <cf8ba27f-2c9e-4c13-8c28-4e1e22e22479@oss.qualcomm.com>
+Udit, +Bartoz
Hello Hans,
On 4/17/2026 8:00 PM, johannes.goede@oss.qualcomm.com wrote:
> Hi,
>
> On 17-Apr-26 15:38, Harshal Dev wrote:
>>
>>
>> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>>> Hi,
>>>>
>>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>>> SM8x50 platforms.
>>>>>>
>>>>>> Describe the crypto engine and its BAM.
>>>>>>
>>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>>> 1 file changed, 26 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>>> status = "disabled";
>>>>>> };
>>>>>>
>>>>>> + cryptobam: dma-controller@1dc4000 {
>>>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + #dma-cells = <1>;
>>>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>>>> + <&apps_smmu 0x481 0x0>;
>>>>>
>>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>>> tested this patch on hw?
>>>>
>>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>>> (I hope I don't need to pad them?)
>>>
>>> No, you don't
>>
>> Ack.
>>
>>>
>>>>
>>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>>
>>>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>>
>>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>>> SIDs and wait for a Tested-by from him.
>>>
>>> Thanks
>>>
>>> I think you should be able to get some life out of the crypto engine
>>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>>> mentioned reports a failure on Hamoa)
>>
>> Sure, I'll try this, could you also point me to the bug report?
>
> No bug report yet, I was asking around internally who I should
> talk to about his.
>
> I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
> T14s gen 6 (Hamoa x1e78100):
>
> [ 1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
> [ 1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
> [ 1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"
>
> This is with manually compiled 7.0-rc# using Fedora's default kernel
> config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
> with the latter being hidden behind CONFIG_EXPERT for some reason.
>
> This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
> is also enabled by Fedora and it works fine.
Our Crypto Engine enablement for Hamoa (x1e80100) was merged as part of the 7.0 kernel
https://lore.kernel.org/all/a9a6b840-5a4f-4d27-8b34-da82657e5c9d@app.fastmail.com/
I did not run the CRYPTO_SELF_TESTS for these, so I am not sure if they were passing
for 7.0 with the Crypto Engine enablement changes. I also do not know if we have been
running the self-tests for other Qualcomm targets which have support for the Crypto Engine.
Maybe Bartoz can help answer this, since he has been involved from the beginning.
But it is worthwhile to check if something else introduced this regression or simply
the enablement of Crypto Engine on Hamoa. If you have a manually compiled 7.0-rc build
could you perhaps check reproduction after reverting this commit?
7d1974ce80fc386834e5667b0f579c2c766c4faa ("arm64: dts: qcom: x1e80100: Add crypto engine")
>
> I've not looked further into this yet, other then a message to fellow
> OSTT team arm64-laptop users asking for tips / whom to report this to.
>
> I would be happy to send create a kernel.bugzilla.org bug-report
> about this to, or report to email somewhere, or ...
>
> Please let met know where you want a bug-report to be filed and
> also what information to add on top of the above info ?
>
> E.g. these failures trigger a WARN() and thus log a backtrace,
> do you want those backtraces and if yes I presume I should run
> them through addr2line ?
>
Please send an email to me, Neeraj, Udit and Bartoz for a separate discussion on this.
Please provide information which can help us reproduce this on our setup, and
also the the dmesg and backtrace logs which you are mentioning here apart from any
other information which you feel is relevant.
Thank you very much for your efforts on this!
Regards,
Harshal
> Regards,
>
> Hans
>
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC
From: Manivannan Sadhasivam @ 2026-04-20 8:16 UTC (permalink / raw)
To: Shawn Guo
Cc: Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260420040141.1247612-1-shengchao.guo@oss.qualcomm.com>
On Mon, Apr 20, 2026 at 12:01:41PM +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Document Inter-Processor Communication Controller on Qualcomm Nord SoC
> with a fallback on qcom,ipcc.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> index f5c584cf2146..0a86230a2b18 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> @@ -28,6 +28,7 @@ properties:
> - qcom,glymur-ipcc
> - qcom,kaanapali-ipcc
> - qcom,milos-ipcc
> + - qcom,nord-ipcc
What is the difference between this and the existing 'sa8775p' compatible? Are
they both representing the same SoC series?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ 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