* [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
In-Reply-To: <20260410-purwa_camss-v1-0-eedcf6d9d8ee@oss.qualcomm.com>
Add bindings for the Camera Subsystem for X1P42100.
The X1P42100 platform provides:
- 2 x CSIPHY
- 3 x TPG
- 3 x CSID
- 2 x CSID Lite
- 1 x IFE
- 2 x IFE Lite
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
.../bindings/media/qcom,x1p42100-camss.yaml | 424 +++++++++++++++++++++
1 file changed, 424 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..8bfa7e616c3b6b91adc8e21ebfbbe6fb579484f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
@@ -0,0 +1,424 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,x1p42100-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1P42100 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,x1p42100-camss
+
+ reg:
+ maxItems: 14
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_wrapper
+ - const: csiphy0
+ - const: csiphy4
+ - const: csitpg0
+ - const: csitpg1
+ - const: csitpg2
+ - const: vfe0
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ ranges: true
+
+ clocks:
+ maxItems: 22
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: cpas_vfe0
+ - const: cpas_vfe_lite
+ - const: cphy_rx_clk_src
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 10
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy4
+ - const: vfe0
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+ - const: sf_mnoc
+ - const: sf_icp_mnoc
+
+ iommus:
+ oneOf:
+ - items:
+ - description: S1 HLOS IFE and IFE_LITE non-protected read
+ - description: S1 HLOS IFE and IFE_LITE non-protected write
+ - description: S1 HLOS SFE non-protected read
+ - description: S1 HLOS SFE non-protected write
+ - description: S1 HLOS CDM IFE non-protected
+ - description: Legacy slot 0 - do not use
+ - description: Legacy slot 1 - do not use
+ - description: Legacy slot 2 - do not use
+ - items:
+ - description: S1 HLOS IFE and IFE_LITE non-protected read
+ - description: S1 HLOS IFE and IFE_LITE non-protected write
+ - description: S1 HLOS SFE non-protected read
+ - description: S1 HLOS SFE non-protected write
+ - description: S1 HLOS CDM IFE non-protected
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: top
+
+ vdd-csiphy-0p8-supply:
+ description:
+ 0.8V supply to a PHY.
+
+ vdd-csiphy-1p2-supply:
+ description:
+ 1.2V supply to a PHY.
+
+ phys:
+ maxItems: 2
+
+ phy-names:
+ items:
+ - const: csiphy0
+ - const: csiphy4
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports. Supports either standard single sensor mode or
+ Qualcomm's combo mode with one sensor in 2x1 + 1x1 data-lane, clock-lane mode.
+
+ patternProperties:
+ "^port@[0-3]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint@0:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ description:
+ Endpoint for receiving a single sensor input (or first leg of combo).
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4 # Base max allows 4 (for D-PHY)
+
+ clock-lanes:
+ maxItems: 1
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ endpoint@1:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ description:
+ Endpoint for receiving the second leg of a combo sensor input.
+
+ properties:
+ data-lanes:
+ maxItems: 1
+
+ clock-lanes:
+ maxItems: 1
+
+ bus-type:
+ const: 4 # Combo is D-PHY specific
+
+ required:
+ - data-lanes
+
+ allOf:
+ # Case 1: Combo Mode (endpoint@1 is present)
+ # If endpoint@1 exists, we restrict endpoint@0 to 2 lanes (D-PHY split)
+ - if:
+ required:
+ - endpoint@1
+ then:
+ properties:
+ endpoint@0:
+ properties:
+ data-lanes:
+ minItems: 2
+ maxItems: 2
+ bus-type:
+ const: 4
+ endpoint@1:
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 1
+ bus-type:
+ const: 4
+
+ # Case 2: Single Mode (endpoint@1 is missing)
+ # We explicitly allow up to 4 lanes here to cover the D-PHY use case.
+ - if:
+ not:
+ required:
+ - endpoint@1
+ then:
+ properties:
+ endpoint@0:
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+patternProperties:
+ "^phy@[0-9a-f]+$":
+ $ref: /schemas/phy/qcom,x1e80100-csi2-phy.yaml
+ unevaluatedProperties: false
+
+ "^opp-table(-.*)?$":
+ type: object
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
+ #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: isp@acb7000 {
+ compatible = "qcom,x1p42100-camss";
+
+ reg = <0 0x0acb7000 0 0x2000>,
+ <0 0x0acb9000 0 0x2000>,
+ <0 0x0acbb000 0 0x2000>,
+ <0 0x0acc6000 0 0x1000>,
+ <0 0x0acca000 0 0x1000>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ace4000 0 0x1000>,
+ <0 0x0acec000 0 0x4000>,
+ <0 0x0acf6000 0 0x1000>,
+ <0 0x0acf7000 0 0x1000>,
+ <0 0x0acf8000 0 0x1000>,
+ <0 0x0ac62000 0 0x4000>,
+ <0 0x0acc7000 0 0x2000>,
+ <0 0x0accb000 0 0x2000>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_wrapper",
+ "csiphy0",
+ "csiphy4",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_NRT_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPHY_RX_CLK_SRC>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe_lite",
+ "cphy_rx_clk_src",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy4",
+ "vfe0",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_mnoc",
+ "sf_icp_mnoc";
+
+ iommus = <&apps_smmu 0x800 0x60>,
+ <&apps_smmu 0x820 0x60>,
+ <&apps_smmu 0x840 0x60>,
+ <&apps_smmu 0x860 0x60>,
+ <&apps_smmu 0x18a0 0x0>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ power-domain-names = "ife0",
+ "top";
+
+ vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
+ vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ csiphy_ep0: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] media: camss: add support for purwa platform
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
This series adds camss support for purwa platform and enables TPG for
purwa-iot-evk board.
Have tested with following commands:
- media-ctl -d /dev/media0 --reset
- media-ctl -V '"msm_tpg0":0[fmt:SRGGB10/4608x2592 field:none]'
- media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4608x2592 field:none]'
- media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4608x2592 field:none]'
- media-ctl -l '"msm_tpg0":0->"msm_csid0":0[1]'
- media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
- v4l2-ctl -d /dev/v4l-subdev0 -c test_pattern=9
- yavta -B capture-mplane -n 5 -f SRGGB10P -s 4608x2592 -F /dev/video0 --capture=5
This patch series depends on patch series:
https://lore.kernel.org/all/20260409-purwa-videocc-camcc-v4-0-5a8e5f2dd4b2@oss.qualcomm.com/
https://lore.kernel.org/all/20260326-x1e-camss-csi2-phy-dtsi-v3-0-1d5a9306116a@linaro.org/
https://lore.kernel.org/all/20260317-camss_tpg-v10-0-b4cfa85c2e1b@oss.qualcomm.com/
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
Wenmeng Liu (4):
dt-bindings: media: Add bindings for qcom,x1p42100-camss
media: qcom: camss: add support for X1P42100 camss
arm64: dts: qcom: purwa: Add camss node
arm64: dts: qcom: purwa-iot-evk: Add camss node
.../bindings/media/qcom,x1p42100-camss.yaml | 424 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 +
arch/arm64/boot/dts/qcom/purwa.dtsi | 158 ++++++++
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 2 +
drivers/media/platform/qcom/camss/camss-vfe.c | 2 +
drivers/media/platform/qcom/camss/camss.c | 109 ++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
7 files changed, 700 insertions(+)
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260409-purwa_camss-475787b87e14
prerequisite-change-id: 20260331-purwa-videocc-camcc-d9700d0f797d:v4
prerequisite-patch-id: 61bdb45446193b72dd8a4b093e4ab2f78db2f066
prerequisite-patch-id: b5be9dcbb612a14108f890b2782860847edfcbe4
prerequisite-patch-id: 2f4d4c5c118e057c76e6d2785479df01d5bc1c7b
prerequisite-patch-id: 026db5dd71d5b0472225ba72c8ba2781334143a9
prerequisite-patch-id: 615e6f38e528de35dc206f1c7f3eaf78ff04afe2
prerequisite-patch-id: 66096b909debe4d942eee972948d5a138a5be427
prerequisite-patch-id: ee26e00cdde21ddb070af713230082ad3454422c
prerequisite-change-id: 20260325-dphy-params-extension-5fcd9ba8af61:v1
prerequisite-patch-id: 471e9403130bb3e65cea1d2365d75ef664662306
prerequisite-patch-id: 075fa72fba3c4f51138b88972e6a5e240038d90c
prerequisite-patch-id: 4edca361ad7d370a338641d1ebb5ca65b114a244
prerequisite-patch-id: 32dd1b55ba678d00088b376e33e12d9da6241aca
prerequisite-change-id: 20250710-x1e-csi2-phy-f6434b651d3a:v5
prerequisite-patch-id: 5c8b5c0011e54921bcfb64b07f0468977f44290b
prerequisite-patch-id: 22e71ff566976c8333537b09b2721116acd267e1
prerequisite-change-id: 20250313-b4-linux-next-25-03-13-dtsi-x1e80100-camss-1506f74bbd3a:v11
prerequisite-patch-id: 6e8e67cd3ab96a602971bbeeb7dfdeaf3f1426a2
prerequisite-patch-id: bbf431fcabc17c30fa5e804eb4accb8275198b37
prerequisite-patch-id: a7fbea14628b62a8de096dea420473b283010aba
prerequisite-patch-id: b6b6c4e7a5818e1b93fe2758902bd32d2be48509
prerequisite-patch-id: 4f11e3d079a484008a03ce750952d6e2933c0253
prerequisite-patch-id: 5f5504fd7b5eee72c3fb8c045fa57219fd2f0456
prerequisite-patch-id: 570b65b326f4c684d813f6ebeda152378dc2a47f
prerequisite-patch-id: bc5b9321c124abd961ae1f60610dc46701dc80ac
prerequisite-patch-id: 6d36feaa3a210039f87ea47aa74423a670260fb6
prerequisite-change-id: 20251226-camss_tpg-b23a398bb65a:v10
prerequisite-patch-id: 520491f0d518f3463d429e77444e231fa6016dd9
prerequisite-patch-id: 459fda84ad92fcd4a497d00ce1690cd19f2cbacb
prerequisite-patch-id: 82330aed01b91c49acbd577ba75bb73bcae6ac90
Best regards,
--
Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Taniya Das @ 2026-04-10 3:55 UTC (permalink / raw)
To: Bryan O'Donoghue, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <cb5a40e8-e2e3-4ed9-a9c6-0daa9f408710@nxsw.ie>
On 4/10/2026 12:10 AM, Bryan O'Donoghue wrote:
> On 09/04/2026 19:10, Taniya Das wrote:
>> + videocc: clock-controller@aaf0000 {
>> + compatible = "qcom,eliza-videocc";
>> + reg = <0x0 0xaaf0000 0x0 0x10000>;
>> +
>> + clocks = <&bi_tcxo_div2>,
>> + <&sleep_clk>,
>> + <&gcc GCC_VIDEO_AHB_CLK>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + #power-domain-cells = <1>;
>> + };
>> +
>> + camcc: clock-controller@ade0000 {
>> + compatible = "qcom,eliza-camcc";
>> + reg = <0x0 0x0ade0000 0x0 0x20000>;
>> +
>> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>> + <&bi_tcxo_div2>,
>> + <&sleep_clk>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + };
>
> This looks odd.
>
> Why do these two controllers have no power-domains ?
Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
--
Thanks,
Taniya Das
^ permalink raw reply
* [PATCH v3 2/2] arm64: defconfig: Enable Qualcomm Glymur clock controllers
From: Taniya Das @ 2026-04-10 3:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
devicetree, linux-kernel, Taniya Das, Dmitry Baryshkov
In-Reply-To: <20260410-glymur_mmcc_dt_config_v2-v3-0-acce9d106e72@oss.qualcomm.com>
Enable the Glymur video and gpu clock controller for their respective
functionalities on the Qualcomm Glymur CRD boards.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4ed70ab7ee854038fa7a756d8b650a609258bdb3..a607bf49c1563d22550c4b81a237d46fe4ea41ce 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1457,7 +1457,9 @@ CONFIG_COMMON_CLK_MT8192_VENCSYS=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_CLK_GLYMUR_DISPCC=m
CONFIG_CLK_GLYMUR_GCC=y
+CONFIG_CLK_GLYMUR_GPUCC=m
CONFIG_CLK_GLYMUR_TCSRCC=m
+CONFIG_CLK_GLYMUR_VIDEOCC=m
CONFIG_CLK_KAANAPALI_GCC=y
CONFIG_CLK_KAANAPALI_TCSRCC=m
CONFIG_CLK_X1E80100_CAMCC=m
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] arm64: dts: qcom: Add support for MM clock controllers for Glymur
From: Taniya Das @ 2026-04-10 3:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
devicetree, linux-kernel, Taniya Das, Konrad Dybcio
In-Reply-To: <20260410-glymur_mmcc_dt_config_v2-v3-0-acce9d106e72@oss.qualcomm.com>
Add the device nodes for the multimedia clock controllers videocc, gpucc
and gxclkctl.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index e269cec7942c85447892c0661f83171eded94f3b..882b8fe025e78ec7a9916226ea3b9c9c9e5c03f3 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5,7 +5,10 @@
#include <dt-bindings/clock/qcom,glymur-dispcc.h>
#include <dt-bindings/clock/qcom,glymur-gcc.h>
+#include <dt-bindings/clock/qcom,glymur-gpucc.h>
#include <dt-bindings/clock/qcom,glymur-tcsr.h>
+#include <dt-bindings/clock/qcom,glymur-videocc.h>
+#include <dt-bindings/clock/qcom,kaanapali-gxclkctl.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/gpio/gpio.h>
@@ -3335,6 +3338,34 @@ hsc_noc: interconnect@2000000 {
#interconnect-cells = <2>;
};
+ gxclkctl: clock-controller@3d64000 {
+ compatible = "qcom,glymur-gxclkctl";
+ reg = <0x0 0x03d64000 0x0 0x6000>;
+
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&rpmhpd RPMHPD_GMXC>,
+ <&gpucc GPU_CC_CX_GDSC>;
+
+ #power-domain-cells = <1>;
+ };
+
+ gpucc: clock-controller@3d90000 {
+ compatible = "qcom,glymur-gpucc";
+ reg = <0x0 0x03d90000 0x0 0x9800>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+
+ power-domains = <&rpmhpd RPMHPD_MX>,
+ <&rpmhpd RPMHPD_CX>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
ipcc: mailbox@3e04000 {
compatible = "qcom,glymur-ipcc", "qcom,ipcc";
reg = <0x0 0x03e04000 0x0 0x1000>;
@@ -3367,6 +3398,22 @@ lpass_ag_noc: interconnect@7e40000 {
#interconnect-cells = <2>;
};
+ videocc: clock-controller@aaf0000 {
+ compatible = "qcom,glymur-videocc";
+ reg = <0x0 0x0aaf0000 0x0 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
dispcc: clock-controller@af00000 {
compatible = "qcom,glymur-dispcc";
reg = <0x0 0x0af00000 0x0 0x20000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] clk: qcom: Add clock controller device nodes and enable clocks for Glymur
From: Taniya Das @ 2026-04-10 3:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
devicetree, linux-kernel, Taniya Das, Konrad Dybcio,
Dmitry Baryshkov
Add the Video clock controller and GPU/GX clock controllers for Glymur.
Enable the clock controllers for Glymur CRD boards.
Changes in v3:
- Update the GPUCC node with the required power-domain and the
require-opps [Akhil].
- Add RB-by tag [Dmitry] for defconfig.
- Link to v2: https://lore.kernel.org/r/20260303-glymur_mmcc_dt_config_v2-v2-0-da9ded08c26f@oss.qualcomm.com
Changes in v2:
- Add RB-by [Konrad].
- Cleaning up stray 0, and add 0x0 for regs.
- Add "Qualcomm" for defconfig commit subject.
- Update the subject for the Cover Letter [Dmitry]
- Link to v1: https://lore.kernel.org/r/20260220-glymur_mmcc_dt_config-v1-0-e0e2f43a32af@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
Taniya Das (2):
arm64: dts: qcom: Add support for MM clock controllers for Glymur
arm64: defconfig: Enable Qualcomm Glymur clock controllers
arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++++++
arch/arm64/configs/defconfig | 2 ++
2 files changed, 49 insertions(+)
---
base-commit: d517cb8cea012f43b069617fc8179b45404f8018
change-id: 20260303-glymur_mmcc_dt_config_v2-ac59220c73d1
Best regards,
--
Taniya Das <taniya.das@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 3/3] riscv: dts: spacemit: Add thermal sensor for K1 SoC
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
Include the Thermal Sensor node in the SpacemiT K1 dtsi
with definitions for registers, clocks, and interrupts.
Additionally, configure thermal zones for the soc, package, gpu, and
clusters to enable temperature monitoring via the thermal framework.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v2:
- Update compatible to "spacemit,k1-tsensor"
---
arch/riscv/boot/dts/spacemit/k1.dtsi | 101 +++++++++++++++++++++++++++++++++++
1 file changed, 101 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 529ec68e9c23..e9952204224e 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -339,6 +339,96 @@ osc_32k: clock-32k {
};
};
+ thermal-zones {
+ soc-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 0>;
+
+ trips {
+ soc-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ package-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 1>;
+
+ trips {
+ package-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 2>;
+
+ trips {
+ gpu-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ gpu-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster0-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 3>;
+
+ trips {
+ cluster0-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cluster0-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster1-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 4>;
+
+ trips {
+ cluster1-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cluster1-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <&plic>;
@@ -494,6 +584,17 @@ syscon_apbc: system-controller@d4015000 {
#reset-cells = <1>;
};
+ thermal: thermal@d4018000 {
+ compatible = "spacemit,k1-tsensor";
+ reg = <0x0 0xd4018000 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_TSEN>,
+ <&syscon_apbc CLK_TSEN_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <61>;
+ resets = <&syscon_apbc RESET_TSEN>;
+ #thermal-sensor-cells = <1>;
+ };
+
i2c6: i2c@d4018800 {
compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4018800 0x0 0x38>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Troy Mitchell, Yao Zi, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
The thermal sensor on K1 supports monitoring five temperature zones.
The driver registers these sensors with the thermal framework
and supports standard operations:
- Reading temperature (millidegree Celsius)
- Setting high/low thresholds for interrupts
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Reviewed-by: Yao Zi <me@ziyao.cc>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v4:
- Add 'depends on THERMAL_OF' in drivers/thermal/spacemit/Kconfig
Changes in v3:
- Align multi-line assignments as suggested by reviewer
- Remove unnecessary variable definitions
Changes in v2:
- Rename k1_thermal.c to k1_tsensor.c for better hardware alignment
- Move driver to drivers/thermal/spacemit/
- Add Kconfig/Makefile for spacemit and update top-level build files
- Refactor names, style, code alignment, and comments
- Simplify probe and error handling
---
drivers/thermal/Kconfig | 2 +
drivers/thermal/Makefile | 1 +
drivers/thermal/spacemit/Kconfig | 19 +++
drivers/thermal/spacemit/Makefile | 3 +
drivers/thermal/spacemit/k1_tsensor.c | 281 ++++++++++++++++++++++++++++++++++
5 files changed, 306 insertions(+)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b10080d61860..1c4a5cd5a23e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -472,6 +472,8 @@ endmenu
source "drivers/thermal/renesas/Kconfig"
+source "drivers/thermal/spacemit/Kconfig"
+
source "drivers/thermal/tegra/Kconfig"
config GENERIC_ADC_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index bb21e7ea7fc6..3b249195c088 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -65,6 +65,7 @@ obj-y += mediatek/
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
+obj-y += spacemit/
obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
obj-$(CONFIG_LOONGSON2_THERMAL) += loongson2_thermal.o
diff --git a/drivers/thermal/spacemit/Kconfig b/drivers/thermal/spacemit/Kconfig
new file mode 100644
index 000000000000..de7b5ece5af2
--- /dev/null
+++ b/drivers/thermal/spacemit/Kconfig
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menu "SpacemiT thermal drivers"
+depends on ARCH_SPACEMIT || COMPILE_TEST
+
+config SPACEMIT_K1_TSENSOR
+ tristate "SpacemiT K1 thermal sensor driver"
+ depends on THERMAL_OF
+ help
+ This driver provides support for the thermal sensor
+ integrated in the SpacemiT K1 SoC.
+
+ The thermal sensor monitors temperatures for five thermal zones:
+ soc, package, gpu, cluster0, and cluster1. It supports reporting
+ temperature values and handling high/low threshold interrupts.
+
+ Say Y here if you want to enable thermal monitoring on SpacemiT K1.
+ If compiled as a module, it will be called k1_tsensor.
+
+endmenu
diff --git a/drivers/thermal/spacemit/Makefile b/drivers/thermal/spacemit/Makefile
new file mode 100644
index 000000000000..82b30741e4ec
--- /dev/null
+++ b/drivers/thermal/spacemit/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_SPACEMIT_K1_TSENSOR) += k1_tsensor.o
diff --git a/drivers/thermal/spacemit/k1_tsensor.c b/drivers/thermal/spacemit/k1_tsensor.c
new file mode 100644
index 000000000000..b742739e9019
--- /dev/null
+++ b/drivers/thermal/spacemit/k1_tsensor.c
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Thermal sensor driver for SpacemiT K1 SoC
+ *
+ * Copyright (C) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
+ */
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/thermal.h>
+
+#include "../thermal_hwmon.h"
+
+#define K1_TSENSOR_PCTRL_REG 0x00
+#define K1_TSENSOR_PCTRL_ENABLE BIT(0)
+#define K1_TSENSOR_PCTRL_TEMP_MODE BIT(3)
+#define K1_TSENSOR_PCTRL_RAW_SEL BIT(7)
+
+#define K1_TSENSOR_PCTRL_CTUNE GENMASK(11, 8)
+#define K1_TSENSOR_PCTRL_SW_CTRL GENMASK(21, 18)
+#define K1_TSENSOR_PCTRL_HW_AUTO_MODE BIT(23)
+
+#define K1_TSENSOR_EN_REG 0x08
+#define K1_TSENSOR_EN_ALL GENMASK(MAX_SENSOR_NUMBER - 1, 0)
+
+#define K1_TSENSOR_TIME_REG 0x0C
+#define K1_TSENSOR_TIME_WAIT_REF_CNT GENMASK(3, 0)
+#define K1_TSENSOR_TIME_ADC_CNT_RST GENMASK(7, 4)
+#define K1_TSENSOR_TIME_FILTER_PERIOD GENMASK(21, 20)
+#define K1_TSENSOR_TIME_MASK GENMASK(23, 0)
+
+#define K1_TSENSOR_INT_CLR_REG 0x10
+#define K1_TSENSOR_INT_EN_REG 0x14
+#define K1_TSENSOR_INT_STA_REG 0x18
+
+#define K1_TSENSOR_INT_EN_MASK BIT(0)
+#define K1_TSENSOR_INT_MASK(x) (GENMASK(2, 1) << ((x) * 2))
+
+#define K1_TSENSOR_DATA_BASE_REG 0x20
+#define K1_TSENSOR_DATA_REG(x) (K1_TSENSOR_DATA_BASE_REG + ((x) / 2) * 4)
+#define K1_TSENSOR_DATA_LOW_MASK GENMASK(15, 0)
+#define K1_TSENSOR_DATA_HIGH_MASK GENMASK(31, 16)
+
+#define K1_TSENSOR_THRSH_BASE_REG 0x40
+#define K1_TSENSOR_THRSH_REG(x) (K1_TSENSOR_THRSH_BASE_REG + ((x) * 4))
+#define K1_TSENSOR_THRSH_LOW_MASK GENMASK(15, 0)
+#define K1_TSENSOR_THRSH_HIGH_MASK GENMASK(31, 16)
+
+#define MAX_SENSOR_NUMBER 5
+
+/* Hardware offset value required for temperature calculation */
+#define TEMPERATURE_OFFSET 278
+
+struct k1_tsensor_channel {
+ struct k1_tsensor *ts;
+ struct thermal_zone_device *tzd;
+ int id;
+};
+
+struct k1_tsensor {
+ void __iomem *base;
+ struct k1_tsensor_channel ch[MAX_SENSOR_NUMBER];
+};
+
+static void k1_tsensor_init(struct k1_tsensor *ts)
+{
+ u32 val;
+
+ /* Disable all the interrupts */
+ writel(0xffffffff, ts->base + K1_TSENSOR_INT_EN_REG);
+
+ /* Configure ADC sampling time and filter period */
+ val = readl(ts->base + K1_TSENSOR_TIME_REG);
+ val &= ~K1_TSENSOR_TIME_MASK;
+ val |= K1_TSENSOR_TIME_FILTER_PERIOD |
+ K1_TSENSOR_TIME_ADC_CNT_RST |
+ K1_TSENSOR_TIME_WAIT_REF_CNT;
+ writel(val, ts->base + K1_TSENSOR_TIME_REG);
+
+ /*
+ * Enable all sensors' auto mode, enable dither control,
+ * consecutive mode, and power up sensor.
+ */
+ val = readl(ts->base + K1_TSENSOR_PCTRL_REG);
+ val &= ~K1_TSENSOR_PCTRL_SW_CTRL;
+ val &= ~K1_TSENSOR_PCTRL_CTUNE;
+ val |= K1_TSENSOR_PCTRL_RAW_SEL |
+ K1_TSENSOR_PCTRL_TEMP_MODE |
+ K1_TSENSOR_PCTRL_HW_AUTO_MODE |
+ K1_TSENSOR_PCTRL_ENABLE;
+ writel(val, ts->base + K1_TSENSOR_PCTRL_REG);
+
+ /* Enable thermal interrupt */
+ val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
+ val |= K1_TSENSOR_INT_EN_MASK;
+ writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
+
+ /* Enable each sensor */
+ val = readl(ts->base + K1_TSENSOR_EN_REG);
+ val |= K1_TSENSOR_EN_ALL;
+ writel(val, ts->base + K1_TSENSOR_EN_REG);
+}
+
+static void k1_tsensor_enable_irq(struct k1_tsensor_channel *ch)
+{
+ struct k1_tsensor *ts = ch->ts;
+ u32 val;
+
+ val = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
+ val |= K1_TSENSOR_INT_MASK(ch->id);
+ writel(val, ts->base + K1_TSENSOR_INT_CLR_REG);
+
+ val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
+ val &= ~K1_TSENSOR_INT_MASK(ch->id);
+ writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
+}
+
+/*
+ * The conversion formula used is:
+ * T(m°C) = (((raw_value & mask) >> shift) - TEMPERATURE_OFFSET) * 1000
+ */
+static int k1_tsensor_get_temp(struct thermal_zone_device *tz, int *temp)
+{
+ struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
+ struct k1_tsensor *ts = ch->ts;
+ u32 val;
+
+ val = readl(ts->base + K1_TSENSOR_DATA_REG(ch->id));
+ if (ch->id % 2)
+ *temp = FIELD_GET(K1_TSENSOR_DATA_HIGH_MASK, val);
+ else
+ *temp = FIELD_GET(K1_TSENSOR_DATA_LOW_MASK, val);
+
+ *temp -= TEMPERATURE_OFFSET;
+ *temp *= 1000;
+
+ return 0;
+}
+
+/*
+ * For each sensor, the hardware threshold register is 32 bits:
+ * - Lower 16 bits [15:0] configure the low threshold temperature.
+ * - Upper 16 bits [31:16] configure the high threshold temperature.
+ */
+static int k1_tsensor_set_trips(struct thermal_zone_device *tz, int low, int high)
+{
+ struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
+ struct k1_tsensor *ts = ch->ts;
+ u32 val;
+
+ if (low >= high)
+ return -EINVAL;
+
+ if (low < 0)
+ low = 0;
+
+ high = high / 1000 + TEMPERATURE_OFFSET;
+ low = low / 1000 + TEMPERATURE_OFFSET;
+
+ val = readl(ts->base + K1_TSENSOR_THRSH_REG(ch->id));
+ val &= ~K1_TSENSOR_THRSH_HIGH_MASK;
+ val |= FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, high);
+
+ val &= ~K1_TSENSOR_THRSH_LOW_MASK;
+ val |= FIELD_PREP(K1_TSENSOR_THRSH_LOW_MASK, low);
+ writel(val, ts->base + K1_TSENSOR_THRSH_REG(ch->id));
+
+ return 0;
+}
+
+static const struct thermal_zone_device_ops k1_tsensor_ops = {
+ .get_temp = k1_tsensor_get_temp,
+ .set_trips = k1_tsensor_set_trips,
+};
+
+static irqreturn_t k1_tsensor_irq_thread(int irq, void *data)
+{
+ struct k1_tsensor *ts = (struct k1_tsensor *)data;
+ int mask, status, i;
+
+ status = readl(ts->base + K1_TSENSOR_INT_STA_REG);
+
+ for (i = 0; i < MAX_SENSOR_NUMBER; i++) {
+ if (status & K1_TSENSOR_INT_MASK(i)) {
+ mask = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
+ mask |= K1_TSENSOR_INT_MASK(i);
+ writel(mask, ts->base + K1_TSENSOR_INT_CLR_REG);
+ thermal_zone_device_update(ts->ch[i].tzd, THERMAL_EVENT_UNSPECIFIED);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int k1_tsensor_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct k1_tsensor *ts;
+ struct reset_control *reset;
+ struct clk *clk;
+ int i, irq, ret;
+
+ ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ ts->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(ts->base))
+ return dev_err_probe(dev, PTR_ERR(ts->base), "Failed to get reg\n");
+
+ reset = devm_reset_control_get_exclusive_deasserted(dev, NULL);
+ if (IS_ERR(reset))
+ return dev_err_probe(dev, PTR_ERR(reset), "Failed to get/deassert reset control\n");
+
+ clk = devm_clk_get_enabled(dev, "core");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk), "Failed to get core clock\n");
+
+ clk = devm_clk_get_enabled(dev, "bus");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk), "Failed to get bus clock\n");
+
+ k1_tsensor_init(ts);
+
+ for (i = 0; i < MAX_SENSOR_NUMBER; ++i) {
+ ts->ch[i].id = i;
+ ts->ch[i].ts = ts;
+ ts->ch[i].tzd = devm_thermal_of_zone_register(dev, i, ts->ch + i, &k1_tsensor_ops);
+ if (IS_ERR(ts->ch[i].tzd))
+ return PTR_ERR(ts->ch[i].tzd);
+
+ /* Attach sysfs hwmon attributes for userspace monitoring */
+ ret = devm_thermal_add_hwmon_sysfs(dev, ts->ch[i].tzd);
+ if (ret)
+ dev_warn(dev, "Failed to add hwmon sysfs attributes\n");
+
+ k1_tsensor_enable_irq(ts->ch + i);
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ k1_tsensor_irq_thread,
+ IRQF_ONESHOT, "k1_tsensor", ts);
+ if (ret < 0)
+ return ret;
+
+ platform_set_drvdata(pdev, ts);
+
+ return 0;
+}
+
+static const struct of_device_id k1_tsensor_dt_ids[] = {
+ { .compatible = "spacemit,k1-tsensor" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, k1_tsensor_dt_ids);
+
+static struct platform_driver k1_tsensor_driver = {
+ .driver = {
+ .name = "k1_tsensor",
+ .of_match_table = k1_tsensor_dt_ids,
+ },
+ .probe = k1_tsensor_probe,
+};
+module_platform_driver(k1_tsensor_driver);
+
+MODULE_DESCRIPTION("SpacemiT K1 Thermal Sensor Driver");
+MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: thermal: Add SpacemiT K1 thermal sensor
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Krzysztof Kozlowski, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
Document the SpacemiT K1 Thermal Sensor, which supports
monitoring temperatures for five zones: soc, package, gpu, cluster0,
and cluster1.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v2:
- Rename binding file to spacemit,k1-tsensor.yaml and update compatible
---
.../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml b/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml
new file mode 100644
index 000000000000..6dad76a7dd36
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/spacemit,k1-tsensor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 Thermal Sensor
+
+description:
+ The SpacemiT K1 Thermal Sensor monitors the temperature of the SoC
+ using multiple internal sensors (e.g., soc, package, gpu, clusters).
+
+maintainers:
+ - Shuwei Wu <shuwei.wu@mailbox.org>
+
+$ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-tsensor
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Core clock for thermal sensor
+ - description: Bus clock for thermal sensor
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: Reset for the thermal sensor
+
+ "#thermal-sensor-cells":
+ const: 1
+ description:
+ The first cell indicates the sensor ID.
+ 0 = soc
+ 1 = package
+ 2 = gpu
+ 3 = cluster0
+ 4 = cluster1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - resets
+ - "#thermal-sensor-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+
+ thermal@d4018000 {
+ compatible = "spacemit,k1-tsensor";
+ reg = <0xd4018000 0x100>;
+ clocks = <&syscon_apbc CLK_TSEN>,
+ <&syscon_apbc CLK_TSEN_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <61>;
+ resets = <&syscon_apbc RESET_TSEN>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/3] thermal: spacemit: Add support for SpacemiT K1 SoC thermal sensor
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Krzysztof Kozlowski, Vincent Legoll, Gong Shuai, Anand Moon,
Troy Mitchell, Yao Zi
Introduce support for the on-die thermal sensor found
on the SpacemiT K1 SoC.
Include the device tree binding documentation in YAML format, the
thermal sensor driver implementation, and the device tree changes to
enable the sensor on K1 SoC.
---
Changes in v4:
- Add 'depends on THERMAL_OF' in Kconfig to ensure functional dependency
- Link to v3: https://lore.kernel.org/spacemit/20260119-patchv2-k1-thermal-v3-0-3d82c9ebe8a4@163.com/
Changes in v3:
- Fix indentation and variable types
- Simplify clock management and redundant assignments
- Link to v2: https://lore.kernel.org/r/20251216-patchv2-k1-thermal-v1-0-d4b31fe9c904@163.com
Changes in v2:
- Move driver to drivers/thermal/spacemit/ and update Kconfig/Makefile
- Address reviewer feedback on style and structure
- Improve variable naming and comments
- Link to v1: https://lore.kernel.org/r/20251127-b4-k1-thermal-v1-0-f32ce47b1aba@163.com
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Shuwei Wu (3):
dt-bindings: thermal: Add SpacemiT K1 thermal sensor
thermal: spacemit: k1: Add thermal sensor support
riscv: dts: spacemit: Add thermal sensor for K1 SoC
.../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 101 ++++++++
drivers/thermal/Kconfig | 2 +
drivers/thermal/Makefile | 1 +
drivers/thermal/spacemit/Kconfig | 19 ++
drivers/thermal/spacemit/Makefile | 3 +
drivers/thermal/spacemit/k1_tsensor.c | 281 +++++++++++++++++++++
7 files changed, 483 insertions(+)
---
base-commit: a55f7f5f29b32c2c53cc291899cf9b0c25a07f7c
change-id: 20260409-k1-thermal-fa1a6bc8b65e
Best regards,
--
Shuwei Wu <shuwei.wu@mailbox.org>
^ permalink raw reply
* Re: [net-next,PATCH v6 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted
From: patchwork-bot+netdevbpf @ 2026-04-10 3:10 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, robh, davem, olek2, andrew, conor+dt, edumazet,
f.fainelli, hkallweit1, ivan.galkin, kuba, krzk+dt, michael,
pabeni, linux, vladimir.oltean, devicetree
In-Reply-To: <20260405233008.148974-1-marek.vasut@mailbox.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 6 Apr 2026 01:29:56 +0200 you wrote:
> Sort the documented properties alphabetically, no functional change.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Ivan Galkin <ivan.galkin@axis.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
>
> [...]
Here is the summary with links:
- [net-next,v6,1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted
https://git.kernel.org/netdev/net-next/c/4de7a8acd18e
- [net-next,v6,2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,*-ssc-enable property
https://git.kernel.org/netdev/net-next/c/bfb859a5cb49
- [net-next,v6,3/3] net: phy: realtek: Add property to enable SSC
https://git.kernel.org/netdev/net-next/c/84c5a3f00084
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH 7/7] arm64: dts: qcom: hamoa: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the hamoa device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..f10af9db8bd4 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -6882,6 +6882,7 @@ tpdm@10003000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -6939,6 +6940,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -7077,6 +7079,7 @@ tpdm@10800000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rpdm_mxa";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7096,6 +7099,7 @@ tpdm@1082c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7115,6 +7119,7 @@ tpdm@10841000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -7134,6 +7139,7 @@ tpdm@10844000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_lpass";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7177,6 +7183,7 @@ cti@1098b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp_cscti";
};
tpdm@109d0000 {
@@ -7185,6 +7192,7 @@ tpdm@109d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7205,6 +7213,7 @@ tpdm@10ac0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_south_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7225,6 +7234,7 @@ tpdm@10ac1000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_south_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7459,6 +7469,7 @@ tpdm@10b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7478,6 +7489,7 @@ tpdm@10b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7497,6 +7509,7 @@ tpdm@10b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7516,6 +7529,7 @@ tpdm@10b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7535,6 +7549,7 @@ tpdm@10b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7554,6 +7569,7 @@ tpdm@10b20000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr_lpi";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7624,6 +7640,7 @@ tpdm@10c08000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlmm";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7672,6 +7689,7 @@ tpdm@10c28000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlct";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7691,6 +7709,7 @@ tpdm@10c29000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7824,6 +7843,7 @@ tpdm@10c38000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7843,6 +7863,7 @@ tpdm@10c39000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mx";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7939,6 +7960,7 @@ tpdm@10cc1000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_tmess_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -8043,6 +8065,7 @@ tpdm@10d08000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_0";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8062,6 +8085,7 @@ tpdm@10d09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_1";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8081,6 +8105,7 @@ tpdm@10d0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_2";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8100,6 +8125,7 @@ tpdm@10d0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_3";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8119,6 +8145,7 @@ tpdm@10d0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_4";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8138,6 +8165,7 @@ tpdm@10d0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_5";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8157,6 +8185,7 @@ tpdm@10d0e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_6";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8176,6 +8205,7 @@ tpdm@10d0f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_7";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
--
2.34.1
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: qcom: sm8750: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the sm8750 device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 18fb52c14acd..c13e9a6bc68e 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -4112,6 +4112,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4176,6 +4177,7 @@ tpdm@10800000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_modem_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4256,6 +4258,7 @@ cti@1080b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_mss_qdsp6";
};
tpdm@1082c000 {
@@ -4264,6 +4267,7 @@ tpdm@1082c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -4282,6 +4286,7 @@ tpdm@10841000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-msrs-num = <32>;
@@ -4300,6 +4305,7 @@ tpdm@1084e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_bcv";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4319,6 +4325,7 @@ tpdm@1084f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_lmh";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4338,6 +4345,7 @@ tpdm@10850000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_dpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4402,6 +4410,7 @@ tpdm@10980000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4490,6 +4499,7 @@ cti@1098b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp_qdsp";
};
tpdm@109a3000 {
@@ -4498,6 +4508,7 @@ tpdm@109a3000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,cmb-msrs-num = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4517,6 +4528,7 @@ tpdm@109a4000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-msrs-num = <32>;
@@ -4535,6 +4547,7 @@ tpdm@109a5000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlmm";
qcom,dsb-msrs-num = <32>;
@@ -4553,6 +4566,7 @@ tpdm@109a6000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_north_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4571,6 +4585,7 @@ tpdm@109a7000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4589,6 +4604,7 @@ tpdm@109a8000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cmb0";
qcom,cmb-msrs-num = <32>;
@@ -4607,6 +4623,7 @@ tpdm@109a9000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cmb1";
qcom,cmb-msrs-num = <32>;
@@ -4625,6 +4642,7 @@ tpdm@109aa000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cmb2";
qcom,cmb-msrs-num = <32>;
@@ -4776,6 +4794,7 @@ tpdm@109d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-msrs-num = <32>;
@@ -4909,6 +4928,7 @@ tpdm@10b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4928,6 +4948,7 @@ tpdm@10b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4947,6 +4968,7 @@ tpdm@10b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4966,6 +4988,7 @@ tpdm@10b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4985,6 +5008,7 @@ tpdm@10b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -6801,6 +6825,7 @@ timer {
tpdm-cdsp-llm {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6814,6 +6839,7 @@ tpdm_cdsp_llm_out: endpoint {
tpdm-cdsp-llm2 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm2";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6827,6 +6853,7 @@ tpdm_cdsp_llm2_out: endpoint {
tpdm-modem1 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_modem_1";
qcom,dsb-element-bits = <32>;
out-ports {
--
2.34.1
^ permalink raw reply related
* [PATCH 5/7] arm64: dts: qcom: kaanapali: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM nodes in the kaanapali device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..0d5714ddef9d 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -4201,6 +4201,7 @@ tpdm@10003000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
@@ -4256,6 +4257,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
@@ -4319,6 +4321,7 @@ tpdm@11000000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_modem_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4407,6 +4410,7 @@ tpdm@1102c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -4425,6 +4429,7 @@ tpdm@11180000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4444,6 +4449,7 @@ tpdm@11183000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_cmsr1";
qcom,dsb-element-bits = <32>;
qcom,cmb-element-bits = <32>;
@@ -4463,6 +4469,7 @@ tpdm@11184000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_cmsr2";
qcom,dsb-element-bits = <32>;
qcom,cmb-element-bits = <32>;
@@ -4482,6 +4489,7 @@ tpdm@11185000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm1";
qcom,cmb-element-bits = <64>;
@@ -4500,6 +4508,7 @@ tpdm@11186000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm2";
qcom,cmb-element-bits = <64>;
@@ -4619,6 +4628,7 @@ tpdm@111a3000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,dsb-msrs-num = <32>;
@@ -4637,6 +4647,7 @@ tpdm@111a4000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qrng";
out-ports {
port {
@@ -4653,6 +4664,7 @@ tpdm@111a5000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlmm";
qcom,dsb-msrs-num = <32>;
@@ -4671,6 +4683,7 @@ tpdm@111a6000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_north_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4689,6 +4702,7 @@ tpdm@111a7000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4707,6 +4721,7 @@ tpdm@111a8000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cx";
out-ports {
port {
@@ -4723,6 +4738,7 @@ tpdm@111a9000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxa";
out-ports {
port {
@@ -4739,6 +4755,7 @@ tpdm@111aa000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxc";
out-ports {
port {
@@ -4755,6 +4772,7 @@ tpdm@111ab000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb0";
out-ports {
port {
@@ -4771,6 +4789,7 @@ tpdm@111ac000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb1";
out-ports {
port {
@@ -4787,6 +4806,7 @@ tpdm@111ad000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb2";
out-ports {
port {
@@ -4803,6 +4823,7 @@ tpdm@111ae000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb3";
out-ports {
port {
@@ -4819,6 +4840,7 @@ tpdm@111af000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb4";
out-ports {
port {
@@ -4835,6 +4857,7 @@ tpdm@111b3000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pcie_rscc";
out-ports {
port {
@@ -5024,6 +5047,7 @@ tpdm@111d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
out-ports {
port {
@@ -5040,6 +5064,7 @@ tpdm@11303000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_4";
qcom,cmb-element-bits = <64>;
@@ -5181,6 +5206,7 @@ tpdm@11309000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
@@ -5199,6 +5225,7 @@ tpdm@1130a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
@@ -5217,6 +5244,7 @@ tpdm@1130b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
@@ -5235,6 +5263,7 @@ tpdm@1130c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
@@ -5253,6 +5282,7 @@ tpdm@1130d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -5272,6 +5302,7 @@ tpdm@11422000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipa";
qcom,dsb-msrs-num = <32>;
@@ -6958,6 +6989,7 @@ timer {
tpdm-cdsp-llm {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6971,6 +7003,7 @@ tpdm_cdsp_llm_out: endpoint {
tpdm-cdsp-llm2 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm2";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6984,6 +7017,7 @@ tpdm_cdsp_llm2_out: endpoint {
tpdm-modem1 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_modem_1";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6997,6 +7031,7 @@ tpdm_modem1_out: endpoint {
tpdm-modem2 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_modem_2";
qcom,cmb-element-bits = <64>;
out-ports {
--
2.34.1
^ permalink raw reply related
* [PATCH 4/7] arm64: dts: qcom: kodiak: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the kodiak device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..3a2c28752e31 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -3513,6 +3513,7 @@ tpdm@600f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3532,6 +3533,7 @@ cti@6010000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss";
};
funnel@6041000 {
@@ -3681,6 +3683,7 @@ cti@6b00000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao";
};
cti@6b01000 {
@@ -3689,6 +3692,7 @@ cti@6b01000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_1";
};
cti@6b02000 {
@@ -3697,6 +3701,7 @@ cti@6b02000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_2";
};
cti@6b03000 {
@@ -3705,6 +3710,7 @@ cti@6b03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_3";
};
funnel@6b04000 {
@@ -3859,6 +3865,7 @@ tpdm@6b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3878,6 +3885,7 @@ tpdm@6b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3897,6 +3905,7 @@ tpdm@6b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3916,6 +3925,7 @@ tpdm@6b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3935,6 +3945,7 @@ tpdm@6b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3954,6 +3965,7 @@ cti@6b11000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aoss";
};
etm@7040000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/7] arm64: dts: qcom: monaco: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the monaco device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 7b1d57460f1e..3e076a1df1b9 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -3045,6 +3045,7 @@ tpdm@400f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3307,6 +3308,7 @@ tpdm@4841000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3326,6 +3328,7 @@ tpdm@4850000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pimem";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3347,6 +3350,7 @@ tpdm@4860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_ch_south";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3440,6 +3444,7 @@ tpdm@4980000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3483,6 +3488,7 @@ tpdm@4ac0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mmnoc_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3555,6 +3561,7 @@ tpdm@4ad0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlct";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3807,6 +3814,7 @@ tpdm@4b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3826,6 +3834,7 @@ tpdm@4b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3845,6 +3854,7 @@ tpdm@4b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3864,6 +3874,7 @@ tpdm@4b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3883,6 +3894,7 @@ tpdm@4b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3902,6 +3914,7 @@ cti@4b13000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aoss";
};
tpdm@4b80000 {
@@ -3910,6 +3923,7 @@ tpdm@4b80000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3977,6 +3991,7 @@ cti@4b8b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp_1";
};
tpdm@4c40000 {
@@ -3985,6 +4000,7 @@ tpdm@4c40000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gpdsp_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4078,6 +4094,7 @@ tpdm@4c50000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_south";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4150,6 +4167,7 @@ tpdm@4e00000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4240,6 +4258,7 @@ tpdm@4e10000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr_ch0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4283,6 +4302,7 @@ tpdm@4e20000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr_ch1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4608,6 +4628,7 @@ cti@682b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss";
};
tpdm@6860000 {
@@ -4616,6 +4637,7 @@ tpdm@6860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_actpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4635,6 +4657,7 @@ tpdm@6861000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_apss";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4715,6 +4738,7 @@ tpdm@68a0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_gold";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4734,6 +4758,7 @@ tpdm@68b0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_silver";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4753,6 +4778,7 @@ tpdm@68c0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ext_dsb";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4772,6 +4798,7 @@ cti@68e0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_llm_gold";
};
cti@68f0000 {
@@ -4780,6 +4807,7 @@ cti@68f0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_llm_silver";
};
cti@6900000 {
@@ -4788,6 +4816,7 @@ cti@6900000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ext_dsb";
};
sdhc_1: mmc@87c4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 2/7] arm64: dts: qcom: talos: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to CTI and TPDM nodes in the talos device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 59 +++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index ff5afbfce2a4..019911f3f923 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -2180,6 +2180,7 @@ cti@6010000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss";
};
cti@6011000 {
@@ -2188,6 +2189,7 @@ cti@6011000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_1";
};
cti@6012000 {
@@ -2196,6 +2198,7 @@ cti@6012000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_2";
};
cti@6013000 {
@@ -2204,6 +2207,7 @@ cti@6013000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_3";
};
cti@6014000 {
@@ -2212,6 +2216,7 @@ cti@6014000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_4";
};
cti@6015000 {
@@ -2220,6 +2225,7 @@ cti@6015000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_5";
};
cti@6016000 {
@@ -2228,6 +2234,7 @@ cti@6016000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_6";
};
cti@6017000 {
@@ -2236,6 +2243,7 @@ cti@6017000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_7";
};
cti@6018000 {
@@ -2244,6 +2252,7 @@ cti@6018000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_8";
};
cti@6019000 {
@@ -2252,6 +2261,7 @@ cti@6019000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_9";
};
cti@601a000 {
@@ -2260,6 +2270,7 @@ cti@601a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_10";
};
cti@601b000 {
@@ -2268,6 +2279,7 @@ cti@601b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_11";
};
cti@601c000 {
@@ -2276,6 +2288,7 @@ cti@601c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_12";
};
cti@601d000 {
@@ -2284,6 +2297,7 @@ cti@601d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_13";
};
cti@601e000 {
@@ -2292,6 +2306,7 @@ cti@601e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_14";
};
cti@601f000 {
@@ -2300,6 +2315,7 @@ cti@601f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_15";
};
funnel@6041000 {
@@ -2532,6 +2548,7 @@ cti@683b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdsp6";
};
tpdm@6840000 {
@@ -2540,6 +2557,7 @@ tpdm@6840000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_vsense";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -2560,6 +2578,7 @@ tpdm@684c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2579,6 +2598,7 @@ tpdm@6850000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pimem";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -2600,6 +2620,7 @@ tpdm@6860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2643,6 +2664,7 @@ cti@6867000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp";
};
tpdm@6870000 {
@@ -2651,6 +2673,7 @@ tpdm@6870000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2671,6 +2694,7 @@ tpdm@699c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_wcss";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2693,6 +2717,7 @@ tpdm@69c0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_monaq";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2736,6 +2761,7 @@ tpdm@69d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2756,6 +2782,7 @@ tpdm@6a00000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2776,6 +2803,7 @@ cti@6a02000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl0";
};
cti@6a03000 {
@@ -2784,6 +2812,7 @@ cti@6a03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl0_1";
};
cti@6a10000 {
@@ -2792,6 +2821,7 @@ cti@6a10000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl1";
};
cti@6a11000 {
@@ -2800,6 +2830,7 @@ cti@6a11000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl1_1";
};
funnel@6a05000 {
@@ -2870,6 +2901,7 @@ tpdm@6b02000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -2890,6 +2922,7 @@ tpdm@6b03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2910,6 +2943,7 @@ cti@6b04000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao";
};
cti@6b05000 {
@@ -2918,6 +2952,7 @@ cti@6b05000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_1";
};
cti@6b06000 {
@@ -2926,6 +2961,7 @@ cti@6b06000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_2";
};
cti@6b07000 {
@@ -2934,6 +2970,7 @@ cti@6b07000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_3";
};
funnel@6b08000 {
@@ -3040,6 +3077,7 @@ cti@6b21000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aop_m3";
};
tpdm@6b48000 {
@@ -3048,6 +3086,7 @@ tpdm@6b48000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_west";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3067,6 +3106,7 @@ cti@6c13000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_titan";
/* Not all required clocks can be enabled from the OS */
status = "fail";
@@ -3078,6 +3118,7 @@ cti@6c20000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_venus";
status = "disabled";
};
@@ -3087,6 +3128,7 @@ tpdm@6c28000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3106,6 +3148,7 @@ cti@6c29000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_dlct";
};
cti@6c2a000 {
@@ -3114,6 +3157,7 @@ cti@6c2a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_dlct_1";
};
cti@7020000 {
@@ -3122,6 +3166,7 @@ cti@7020000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_2";
};
etm@7040000 {
@@ -3150,6 +3195,7 @@ cti@7120000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_3";
};
etm@7140000 {
@@ -3178,6 +3224,7 @@ cti@7220000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_4";
};
etm@7240000 {
@@ -3206,6 +3253,7 @@ cti@7320000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_5";
};
etm@7340000 {
@@ -3234,6 +3282,7 @@ cti@7420000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_6";
};
etm@7440000 {
@@ -3262,6 +3311,7 @@ cti@7520000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_7";
};
etm@7540000 {
@@ -3290,6 +3340,7 @@ cti@7620000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_8";
};
etm@7640000 {
@@ -3318,6 +3369,7 @@ cti@7720000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_9";
};
etm@7740000 {
@@ -3492,6 +3544,7 @@ tpdm@7830000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_olc";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3535,6 +3588,7 @@ tpdm@7860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_apss";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3578,6 +3632,7 @@ tpdm@78a0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_silver";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3597,6 +3652,7 @@ tpdm@78b0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_gold";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3664,6 +3720,7 @@ cti@78e0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss";
};
cti@78f0000 {
@@ -3672,6 +3729,7 @@ cti@78f0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_1";
};
cti@7900000 {
@@ -3680,6 +3738,7 @@ cti@7900000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_2";
};
remoteproc_cdsp: remoteproc@8300000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 1/7] arm64: dts: qcom: lemans: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the lemans device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index fe6e76351823..7cdca20708cc 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -2847,6 +2847,7 @@ tpdm@4003000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2906,6 +2907,7 @@ tpdm@400f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3374,6 +3376,7 @@ tpdm@4b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3394,6 +3397,7 @@ tpdm@4b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3414,6 +3418,7 @@ tpdm@4b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3434,6 +3439,7 @@ tpdm@4b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3454,6 +3460,7 @@ tpdm@4b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3474,6 +3481,7 @@ aoss_cti: cti@4b13000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aoss";
};
funnel@4b83000 {
@@ -3795,6 +3803,7 @@ tpdm@6860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_actpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3815,6 +3824,7 @@ tpdm@6861000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_apss";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3897,6 +3907,7 @@ tpdm@68a0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_silver";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3917,6 +3928,7 @@ tpdm@68b0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_gold";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3937,6 +3949,7 @@ tpdm@68c0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_ext";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -8590,6 +8603,7 @@ arch_timer: timer {
turing-llm-tpdm {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm_0";
qcom,cmb-element-bits = <32>;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/7] arm64: dts: qcom: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
The CoreSight framework and userspace tools identify trace devices by
their base address, which is not human-readable. The label property
provides a stable, descriptive name for each TPDM and CTI device,
allowing tools to refer to devices by name rather than address.
This series adds label properties to TPDM and CTI nodes across seven
Qualcomm platforms:
lemans
talos
monaco
kodiak
kaanapali
sm8750
hamoa
With the change, we will have a sysfs node for each Coresight device:
root@qemuarm64:/sys/bus/coresight/devices/tpdm0# cat label
tpdm_spdm
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Jie Gan (7):
arm64: dts: qcom: lemans: Add label properties to CoreSight devices
arm64: dts: qcom: talos: Add label properties to CoreSight devices
arm64: dts: qcom: monaco: Add label properties to CoreSight devices
arm64: dts: qcom: kodiak: Add label properties to CoreSight devices
arm64: dts: qcom: kaanapali: Add label properties to CoreSight devices
arm64: dts: qcom: sm8750: Add label properties to CoreSight devices
arm64: dts: qcom: hamoa: Add label properties to CoreSight devices
arch/arm64/boot/dts/qcom/hamoa.dtsi | 30 +++++++++++++++++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 35 +++++++++++++++++++
arch/arm64/boot/dts/qcom/kodiak.dtsi | 12 +++++++
arch/arm64/boot/dts/qcom/lemans.dtsi | 14 ++++++++
arch/arm64/boot/dts/qcom/monaco.dtsi | 29 ++++++++++++++++
arch/arm64/boot/dts/qcom/sm8750.dtsi | 27 +++++++++++++++
arch/arm64/boot/dts/qcom/talos.dtsi | 59 +++++++++++++++++++++++++++++++++
7 files changed, 206 insertions(+)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260409-add-label-to-coresight-device-b17a2ba6030e
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 3:06 UTC (permalink / raw)
To: Yao Zi, Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <adfF4y8_GhtExZMf@pie>
Hi, Yao Zi
On 2026/4/9 下午11:29, Yao Zi wrote:
> On Thu, Apr 09, 2026 at 08:03:47PM +0800, Hongliang Wang wrote:
>> Hi, Krzysztof
>>
>> On 2026/3/31 下午3:11, Hongliang Wang wrote:
>>> On 2026/3/30 下午3:23, Krzysztof Kozlowski wrote:
>>>> On 30/03/2026 09:18, Hongliang Wang wrote:
>>>>> On 2026/3/27 下午2:39, Krzysztof Kozlowski wrote:
>>>>>> On 27/03/2026 04:09, Hongliang Wang wrote:
>>>>>>> The initial idea was that this patch could be used for
>>>>>>> both ACPI and DTS.
>>>>>>>>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>>>>>>>>> platform, parse
>>>>>>>>>> the same parameters regardless of dts or
>>>>>>>>>> acpi parameter passing, So
>>>>>>>>>> clock-input
>>>>>>>>>> and clock-div attributes are defined to
>>>>>>>>>> describe input clock of i2c
>>>>>>>>>> controller and
>>>>>>>>>> divisor of input clock. It can be used on
>>>>>>>>>> both 2K and 3A+7A platform.
>>>>>>>>> And you cannot use them in DTS.
>>>>>>> OK
>>>>>>>> I need to keep guessing what you want to achieve,
>>>>>>>> because neither your
>>>>>>>> message nor commit text was explicit
>>>>>>> What I want to achieve is to describe the input clock
>>>>>>> and divisor of I2C
>>>>>>> controller
>>>>>> Input clocks are defined as clock inputs obviously in DT, not as
>>>>>> integers. Bindings need to describe the hardware, so start with that.
>>>>> I can describe the hardware in loongson,ls2x-i2c.yaml, and I
>>>>> would like to
>>>>> confirm with you what final implementation plan you agree to? clock
>>>>> framework
>>>>> or custom clock-input an clock-div attributes? if clock framework, how
>>>>> can it
>>>>> also be used for ACPI?
>>>> And you ask DT maintainer for that? It's not relevant. You sent DT
>>>> bindings patch, so this patch must be correct and we discuss this patch
>>>> here.
>>> I don't. My idea is that if the clock input attribute can't be used for
>>> both
>>> dts and acpi, then clock framework will be used for dts and new define
>>> attribute
>>> will be used for acpi. I will first implement the hardware description
>>> and clock
>>> framework in Bindings.
>>>> Best regards,
>>>> Krzysztof
>>> Best regards,
>>> Hongliang Wang
>>>
>> I have a question, the input clock of i2c controller can be described by
>> "clocks",
>> but there is no existing attribute can describe the divisor of the input
>> clock,
> From the description of 7A1000's user manual (section 2.3
> "时钟功能描述"), it seems the divider isn't part of the I2C controller,
> but instead is an on-chip divider with fixed 1/2 factor, feeding both
> "MISC" block (including I2C) and SPI.
>
>> Can I define a new attribute named "clock-div" to describe it in DT
>> bindings?
>> or do you have any standard solutions for the divisor problem? Thank you.
> If these devicetree-based Loongson platforms follow a similar pattern as
> the bridge chip, then the divisor shouldn't be described in the I2C
> controller node. You may want to include a "fixed-factor-clock" node to
> match the hardware.
>
Sorry, I didn't describe it clearly, The divisor I described doesn't
refer to
the fixed 1/2 factor feeding MISC block(including I2C). What I have
described
is included in the formula in section 10.2 of the 7a1000 user manual.
Prcescale = clock_a/(clock_div*clock_s)-1
clock_a represents the input clock(it is the fixed 1/2 factor feeding
MISC block
(including I2C), 50M on 7a1000), which is described by "clocks",
clock_s represents the i2c bus frequency, which is described by
"clock-frequency",
The divisor I described is clock_div in formula. which has different
value on
different platform. for example, it is 5 on 7a1000/7a2000, 4 on
2K1000/2K2000,
5.5 on 2K3000. I need a property to describe clock_div in this formula.
>> Best regards,
>> Hongliang Wang
>>
>>
>>
> Regards,
> Yao Zi
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 3:04 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <dc1c0b6d-b6e6-4a88-8e50-e8316e3dcf5e@kernel.org>
Hi, Krzysztof
On 2026/4/9 下午8:11, Krzysztof Kozlowski wrote:
> On 09/04/2026 14:03, Hongliang Wang wrote:
>> I have a question, the input clock of i2c controller can be described by
>> "clocks",
>> but there is no existing attribute can describe the divisor of the input
>> clock,
>> Can I define a new attribute named "clock-div" to describe it in DT
>> bindings?
>> or do you have any standard solutions for the divisor problem? Thank you.
>>
> You should determine/calculate the divisor in the driver code, depending
> on clocks and bus frequencies. You don't need a property for that, usually.
Not only clocks and bus frequencies, but also a third property is required.
The frequency divison calculation formula of i2c is
Prcescale = clock_a/(clock_div*clock_s)-1
There is three parameters in this formula:
clock_a represents the input clock, which is described by "clocks",
clock_s represents the i2c bus frequency, which is described by
"clock-frequency",
but there is no existing property to describe clock_div, which has
different value
on different platform (for example, it is 5 on 7a1000/7a2000, 4 on
2K1000/2K2000,
5.5 on 2K3000.), So I need a property to describe clock_div in this formula.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* RE: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Sherry Sun @ 2026-04-10 3:00 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <omtn42mopdz7igg7jaqwehd67l6xc77zk7zzqwkufgnsycvadg@5kodhpgfesre>
> Subject: Re: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device
> trees
>
> On Thu, Apr 02, 2026 at 06:09:59PM +0800, Sherry Sun wrote:
> > Note: This patch set depends on my previous patch set [1] which adds
> > Root Port device tree nodes and support parsing the reset property in
> > new Root Port binding in pci-imx6 driver.
> >
> > This series integrates the PCI pwrctrl framework into the pci-imx6
> > driver and updates i.MX EVK board device trees to support it.
> >
> > Patches 2-8 update device trees for i.MX EVK boards which maintained
> > by NXP to move power supply properties from the PCIe controller node
> > to the Root Port child node, which is required for pwrctrl framework.
> > Affected boards:
> > - i.MX6Q/DL SABRESD
> > - i.MX6SX SDB
> > - i.MX8MM EVK
> > - i.MX8MP EVK
> > - i.MX8MQ EVK
> > - i.MX8DXL/QM/QXP EVK
> > - i.MX95 15x15/19x19 EVK
> >
> > The driver maintains legacy regulator handling for device trees that
> > haven't been updated yet. Both old and new device tree structures are
> > supported.
> >
>
> Thanks for the work! Due to some recently merged patches, this series (Patch
> 1) doesn't apply on top of pci/controller/dwc-imx6 branch. Please rebase and
> resend!
>
> - Mani
Hi Mani, thanks for the reminder.
Actually this patch set depends on my PERST# patch set [1], which adds
support for Root Port dts nodes and correctly adjusts the sequence of PERST#
assert/deassert and regulator/clock enable in pci-imx6 driver.
I will resend this series once the PERST# patch set been accepted.
[1] https://lore.kernel.org/all/20260410023055.2439146-1-sherry.sun@nxp.com/
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-04-10 2:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Looks like this driver uses page pool.
If you're sharing the same page pool across multiple netdevs
it must not be linked to a netdev.
^ permalink raw reply
* Re: [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-10-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Do not stop GDM port if it is shared
Theoretically, in the current codebase, two independent net_devices can
be connected to the same GDM port so we need to check the GDM port is not
used by any other running net_device before setting the forward
configuration to FE_PSE_PORT_DROP.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index fd27ba13029bd..5b0cd37b155e4 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> struct airoha_qdma *qdma = dev->qdma;
> - int i, err;
> + int i;
>
> netif_tx_disable(netdev);
> - err = airoha_set_vip_for_gdm_port(dev, false);
> - if (err)
> - return err;
> -
> for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> netdev_tx_reset_subqueue(netdev, i);
>
> - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> - FE_PSE_PORT_DROP);
> + if (atomic_dec_and_test(&port->users)) {
> + airoha_set_vip_for_gdm_port(dev, false);
> + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> + REG_GDM_FWD_CFG(port->id),
> + FE_PSE_PORT_DROP);
> + }
>
> if (atomic_dec_and_test(&qdma->users)) {
> airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
>
> for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> if (!qdma->q_tx[i].ndesc)
> continue;
>
> airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> }
> }
This problem wasn't introduced by this patch, but does the QDMA teardown
path have a DMA corruption vulnerability here?
When GLOBAL_CFG_TX_DMA_EN_MASK is cleared, it fails to poll
GLOBAL_CFG_TX_DMA_BUSY_MASK, proceeding to unmap memory while the hardware
DMA engine may still be processing in-flight descriptors.
Furthermore, airoha_qdma_cleanup_tx_queue() unmaps the DMA addresses and
frees the SKBs, but it does not appear to clear the physical hardware
descriptors or reset the hardware ring pointers (REG_TX_CPU_IDX /
REG_TX_DMA_IDX).
When the device is later reopened in airoha_dev_open(),
GLOBAL_CFG_TX_DMA_EN_MASK is set again without re-initializing the rings.
Will the hardware DMA engine resume fetching from its previous index,
processing stale descriptors whose backing memory was already unmapped
and freed?
[ ... ]
> @@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = dev->port;
> - u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> struct airoha_eth *eth = dev->eth;
>
> + cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
> + airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
> + if (len < cur_len) {
> + u8 port_refcnt = atomic_read(&port->users);
> +
> + /* We can decrease the device MTU just if the GDM port is
> + * not shared or if the other device is not running.
> + */
> + if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
> + return -EBUSY;
> + }
> +
Does this MTU decrease validation create a state trap on shared ports?
If both eth0 and eth1 (sharing a port) are up, and a user increases eth0 MTU
to 9000, the hardware MTU updates to 9000. If the user then tries to lower
eth0 MTU back to 1500, len < cur_len evaluates to true. Because eth1 is also
up (port_refcnt > 1), this returns -EBUSY.
This would prevent either interface from decreasing its MTU without fully
bringing down the sibling interface.
Should the software netdev->mtu be decoupled from the hardware validation,
allowing valid MTU changes in software while dynamically programming the
hardware MTU to the maximum of all currently up interfaces on the shared
port?
^ permalink raw reply
* Re: [PATCH net-next v3 09/12] net: airoha: Support multiple net_devices for a single FE GDM port
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-9-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Support multiple net_devices for a single FE GDM port
This commit introduces support for mapping multiple net_device interfaces
to a single Frame Engine (FE) GDM port via an external hardware arbiter.
It updates the rx/tx paths, port allocation, and registration logic to
handle the new net_device array.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -615,9 +617,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> struct page *page = virt_to_head_page(e->buf);
> u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> - struct airoha_gdm_port *port;
> - struct net_device *netdev;
> - int data_len, len, p;
> + struct airoha_gdm_dev *dev;
> + int data_len, len;
>
> if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> break;
While looking at this code, I noticed an issue that predates this patch.
Can the lack of a memory barrier after checking the descriptor ownership bit
cause stale reads?
The driver checks QDMA_DESC_DONE_MASK to verify that the hardware has finished
writing the descriptor. However, it reads desc->msg1 before this check and
without a dma_rmb():
u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
struct page *page = virt_to_head_page(e->buf);
u32 desc_ctrl = le32_to_cpu(desc->ctrl);
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
Since weakly ordered architectures can reorder memory reads, could the CPU
prefetch msg1 before the DMA engine writes the new descriptor values, leading
to routing the packet to the wrong gdm_dev?
[ ... ]
> @@ -1764,9 +1765,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
>
> - /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
> - nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> - src_port = eth->soc->ops.get_src_port_id(port, nbq);
> + src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
> if (src_port < 0)
> return src_port;
Can configuring the loopback for one device break connectivity for other
devices sharing the same port?
When multiple net_devices (like PCIE0 and PCIE1 on GDM3) open and call
airoha_set_gdm2_loopback(), they modify global hardware registers such as
REG_FE_WAN_PORT.
Since WAN0_MASK is unconditionally updated to track the current device's
src_port:
airoha_fe_rmw(eth, REG_FE_WAN_PORT,
WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
FIELD_PREP(WAN0_MASK, src_port));
won't the last configured device clobber the hardware state for the others?
[ ... ]
> @@ -1987,7 +1986,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> }
>
> fport = airoha_get_fe_port(dev);
> - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
>
> q = &qdma->q_tx[qid];
Does sharing the hardware QDMA TX queues among multiple net_device instances
introduce a permanent transmit stall?
In airoha_dev_xmit(), if a shared hardware queue is full, the driver stops the
netdev_queue of the specific netdev making the call:
if (q->queued + nr_frags >= q->ndesc) {
/* not enough space in the queue */
netif_tx_stop_queue(txq);
spin_unlock_bh(&q->lock);
return NETDEV_TX_BUSY;
}
However, the TX completion handler (airoha_tx_irq_process()) only wakes the
queue of the netdev attached to the completed packet. If an interface's TX
queue is stopped but it has no pending packets in the hardware queue (because
another interface filled it), will it ever get woken up?
[ ... ]
> @@ -2955,11 +2958,25 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> netdev->dev_addr);
> }
>
> + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> + * and PCIE1 respectively.
> + */
> + index = nbq;
> + if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> + index -= 4;
> +
> + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> + return -EINVAL;
> + }
> +
> + netdev->dev.of_node = of_node_get(np);
> dev = netdev_priv(netdev);
Does this code leak the of_node reference?
The node reference is explicitly incremented via of_node_get(np). The networking
core does not automatically drop explicit of_node references on free_netdev().
Without a matching of_node_put() in the error paths or the driver's teardown
function (airoha_remove()), will this reference permanently leak when the device
is destroyed?
[ ... ]
> @@ -3003,7 +3021,43 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> if (err)
> return err;
>
> - return airoha_alloc_gdm_device(eth, port, np);
> + for_each_child_of_node(np, node) {
> + /* Multiple external serdes connected to the FE GDM port via an
> + * external arbiter.
> + */
> + const __be32 *nbq_ptr;
> + int nbq;
> +
> + if (!of_device_is_compatible(node, "airoha,eth-port"))
> + continue;
> +
> + d++;
> + if (!of_device_is_available(node))
> + continue;
> +
> + nbq_ptr = of_get_property(node, "reg", NULL);
> + if (!nbq_ptr) {
> + dev_err(eth->dev, "missing nbq id\n");
> + of_node_put(node);
> + return -EINVAL;
> + }
> +
> + /* Verify the provided nbq parameter is valid */
> + nbq = be32_to_cpup(nbq_ptr);
> + err = eth->soc->ops.get_src_port_id(port, nbq);
> + if (err < 0) {
> + of_node_put(node);
> + return err;
> + }
> +
> + err = airoha_alloc_gdm_device(eth, port, nbq, node);
> + if (err) {
> + of_node_put(node);
> + return err;
> + }
> + }
> +
> + return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
> }
Does passing 0 for nbq in the fallback path break older device trees on the
EN7581 SoC?
Later, when the interface is brought up, airoha_set_gdm2_loopback() calls
airoha_en7581_get_src_port_id(), which returns -EINVAL for GDM3 if nbq is
not 4 or 5:
switch (port->id) {
case AIROHA_GDM3_IDX:
/* 7581 SoC supports PCIe serdes on GDM3 port */
if (nbq == 4)
return HSGMII_LAN_7581_PCIE0_SRCPORT;
if (nbq == 5)
return HSGMII_LAN_7581_PCIE1_SRCPORT;
break;
If nbq is hardcoded to 0 for legacy DTs, won't this cause interface
initialization to fail unconditionally for GDM3?
^ 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