* [PATCH 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I split the patches to avoid bounces from mailing list due to email size.
This can go via clock tree (no dependencies)... or both could go via
Rob's tree.
---
.../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8084.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq6018.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9615.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8660.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8909.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8916.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8974.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-sdm660.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq5018-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 6 +++---
.../devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov920-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +-
32 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
index 53a5ab319159..6863db9bd092 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm display clock control module provides the clocks, resets and power
domains on SM8150/SM8250/SM8350.
- See also::
+ See also:
include/dt-bindings/clock/qcom,dispcc-sm8150.h
include/dt-bindings/clock/qcom,dispcc-sm8250.h
include/dt-bindings/clock/qcom,dispcc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
index 27df7e3e5bf3..68532244901e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8960.h
include/dt-bindings/reset/qcom,gcc-msm8960.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
index 0a0a26d9beab..1c022e75fd71 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8084.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-apq8084.h
include/dt-bindings/reset/qcom,gcc-apq8084.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
index 4d2614d4f368..c7fb84438db7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ6018.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq6018.h
include/dt-bindings/reset/qcom,gcc-ipq6018.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
index a71557395c01..b4d3175780bc 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
include/dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
index d7da30b0e7ee..0a7be7583bdd 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9607.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
index 418dea31eb62..0656d5ee448d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9615.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
index e03b6d0acdb6..70c9da1f35c2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks and resets on
MSM8660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8660.h
include/dt-bindings/reset/qcom,gcc-msm8660.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
index ce1f5a60bd8c..2edb6c251d99 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8909, MSM8917 or QM215.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8909.h
include/dt-bindings/clock/qcom,gcc-msm8917.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
index 258b6b93deca..af4b639ea8c3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8916 or MSM8939.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8916.h
include/dt-bindings/clock/qcom,gcc-msm8939.h
include/dt-bindings/reset/qcom,gcc-msm8916.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
index ced3118c8580..fc0360554f68 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8937, MSM8940, MSM8953 or SDM439.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8917.h
include/dt-bindings/clock/qcom,gcc-msm8953.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
index 929fafc84c19..378dfe7854ac 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8974 (all variants) and MSM8226.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
include/dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
index 724ce0491118..72aaf699cf70 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on SDM630, SDM636 and SDM660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
$ref: qcom,gcc.yaml#
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 4cdff6161bf0..3ac4419009a9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gpucc-sdm845.h
include/dt-bindings/clock/qcom,gpucc-sa8775p.h
include/dt-bindings/clock/qcom,gpucc-sc7180.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
index 489d0fc5607c..9925b931ecad 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ5018
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq5018-gcc.h
include/dt-bindings/reset/qcom,ipq5018-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 27ae9938febc..5b128fa841aa 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ9574
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq9574-gcc.h
include/dt-bindings/reset/qcom,ipq9574-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
index 61473385da2d..3da10c364a85 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm NSS clock control module provides the clocks and resets
on QCA8386(switch mode)/QCA8084(PHY mode)
- See also::
+ See also:
include/dt-bindings/clock/qcom,qca8k-nsscc.h
include/dt-bindings/reset/qcom,qca8k-nsscc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
index 734880805c1b..bedbdabef672 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,qcm2290-gpucc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8..b6c835bfd0d9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
- come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is
+ come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock is
an "active" clock, which means that the consumer only care that the clock is
available when the apps CPU subsystem is active, i.e. not suspended or in
deep idle. If it is important that the clock keeps running during system
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
index 99ab9106009f..fd06ac9bceb9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks and
power domains on SC7280.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
index 273d66e245c5..f235b4e24cc7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks,
and reset on SC8280XP.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
index 8cbab3fbb660..d7e1938b5e1b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm LPASS core and audio clock controllers provide audio-related resets
on SM6115 and its derivatives.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6115-lpasscc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
index 5c2ecec0624e..a986ab4ce7c7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,videocc-sm8350.h
include/dt-bindings/reset/qcom,videocc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index f4ff9acef9d5..124d259fc85e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6350-videocc.h
include/dt-bindings/clock/qcom,videocc-sc7180.h
include/dt-bindings/clock/qcom,videocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
index b05f83533e3d..56ab972c3da5 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
@@ -14,17 +14,17 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
- Phy clocks::
+ Phy clocks:
There are several clocks which are generated by specific PHYs. These clocks
are fed into the clock controller and then routed to the hardware blocks.
- These clocks are defined as fixed clocks in the driver with following names::
+ These clocks are defined as fixed clocks in the driver with following names:
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
index b737c9d35a1c..1d907dd8fbf1 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
index 3f9326e09f79..8a289f1e2ace 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "oscclk" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
index c137c6744ef9..a51cd4fafb41 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
index cdc5ded59fe5..68c2fd318765 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos850 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
+ two external clocks: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
clocks must be defined as fixed-rate clocks in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index 32f39e543b36..e9d17d48b4f3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos Auto v9 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
index 6b1fc61a2ff9..475db824d4d3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
@@ -17,7 +17,7 @@ description: |
ExynosAuto v920 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
index 67a33665cf00..b1617d96d3fb 100644
--- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "xxti" - external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti" - external crystal oscillator connected to XUSBXTI and XUSBXTO
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: PCI: qcom: Document the Hawi PCIe Controller
From: Krzysztof Kozlowski @ 2026-06-22 10:12 UTC (permalink / raw)
To: Matthew Leung
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, linux-arm-msm, linux-pci,
devicetree, linux-kernel
In-Reply-To: <20260618-hawi-pcie-v3-1-f31880bfb3ec@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:00:32PM +0000, Matthew Leung wrote:
> Add a dedicated schema for the PCIe controllers found on the Hawi
> platform.
>
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
> .../devicetree/bindings/pci/qcom,hawi-pcie.yaml | 202 +++++++++++++++++++++
> 1 file changed, 202 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,hawi-pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,hawi-pcie.yaml
> new file mode 100644
> index 000000000000..fb3145f89f7f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,hawi-pcie.yaml
> @@ -0,0 +1,202 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,hawi-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Hawi PCI Express Root Complex
> +
> +maintainers:
> + - Bjorn Andersson <andersson@kernel.org>
> + - Manivannan Sadhasivam <mani@kernel.org>
> +
> +description:
> + Qualcomm Hawi SoC (and compatible) PCIe root complex controller is based on
> + the Synopsys DesignWare PCIe IP.
> +
> +properties:
> + compatible:
> + const: qcom,hawi-pcie
> +
> + reg:
> + minItems: 5
> + items:
> + - description: Qualcomm specific registers
> + - description: DesignWare PCIe registers
> + - description: External local bus interface registers
> + - description: ATU address space
> + - description: PCIe configuration space
> + - description: MHI registers
Why is MHI optional?
> +
> + reg-names:
> + minItems: 5
> + items:
> + - const: parf
> + - const: dbi
> + - const: elbi
> + - const: atu
> + - const: config
> + - const: mhi
> +
> + clocks:
> + minItems: 6
> + items:
> + - description: PCIe Auxiliary clock
> + - description: PCIe Configuration clock
> + - description: PCIe Master AXI clock
> + - description: PCIe Slave AXI clock
> + - description: PCIe Slave Q2A AXI clock
> + - description: PCIe Aggre NoC AXI clock
> + - description: PCIe Config NoC AXI clock
Same here - does that mean that once instance does not have this clock?
If so, mention this in commit msg.
> +
> + clock-names:
> + minItems: 6
> + items:
> + - const: aux
> + - const: cfg
> + - const: bus_master
> + - const: bus_slave
> + - const: slave_q2a
> + - const: noc_aggr
> + - const: cnoc_sf_axi
> +
> + interrupts:
> + minItems: 8
> + maxItems: 9
> +
> + interrupt-names:
> + minItems: 8
> + items:
> + - const: msi0
> + - const: msi1
> + - const: msi2
> + - const: msi3
> + - const: msi4
> + - const: msi5
> + - const: msi6
> + - const: msi7
> + - const: global
Here as well - why is global optional?
> +
> + resets:
> + minItems: 1
Same here?
> + items:
> + - description: PCIe core reset
> + - description: PCIe link down reset
> +
> + reset-names:
> + minItems: 1
> + items:
> + - const: pci
> + - const: link_down
> +
> +required:
> + - power-domains
> + - resets
> + - reset-names
> +
> +allOf:
> + - $ref: qcom,pcie-common.yaml#
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] media: i2c: vd55g1: Fix manual digital gain on color variant
From: Jacopo Mondi @ 2026-06-22 10:09 UTC (permalink / raw)
To: Benjamin Mugnier
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <20260428-vd55g4_and_fixes-v1-3-4f745a83b87e@foss.st.com>
Hi Benjamin
On Tue, Apr 28, 2026 at 10:40:57AM +0200, Benjamin Mugnier wrote:
> Apply digital gain to all channels, each channel representing a color.
>
> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
Also cc stable here
>
> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Thanks
j
> ---
> drivers/media/i2c/vd55g1.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index e44174056ace..2c962fcb41d2 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -60,7 +60,10 @@
> #define VD55G1_PATGEN_ENABLE BIT(0)
> #define VD55G1_REG_MANUAL_ANALOG_GAIN CCI_REG8(0x0501)
> #define VD55G1_REG_MANUAL_COARSE_EXPOSURE CCI_REG16_LE(0x0502)
> -#define VD55G1_REG_MANUAL_DIGITAL_GAIN CCI_REG16_LE(0x0504)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH0 CCI_REG16_LE(0x0504)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH1 CCI_REG16_LE(0x0506)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH2 CCI_REG16_LE(0x0508)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH3 CCI_REG16_LE(0x050a)
> #define VD55G1_REG_APPLIED_COARSE_EXPOSURE CCI_REG16_LE(0x00e8)
> #define VD55G1_REG_APPLIED_ANALOG_GAIN CCI_REG16_LE(0x00ea)
> #define VD55G1_REG_APPLIED_DIGITAL_GAIN CCI_REG16_LE(0x00ec)
> @@ -850,9 +853,16 @@ static int vd55g1_update_expo_cluster(struct vd55g1 *sensor, bool is_auto)
> vd55g1_write(sensor, VD55G1_REG_MANUAL_ANALOG_GAIN,
> sensor->again_ctrl->val, &ret);
>
> - if (!is_auto && sensor->dgain_ctrl->is_new)
> - vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN,
> + if (!is_auto && sensor->dgain_ctrl->is_new) {
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH0,
> sensor->dgain_ctrl->val, &ret);
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH1,
> + sensor->dgain_ctrl->val, &ret);
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH2,
> + sensor->dgain_ctrl->val, &ret);
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH3,
> + sensor->dgain_ctrl->val, &ret);
> + }
>
> return ret;
> }
>
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH 2/2] dt-bindings: thermal: amlogic: Correct 'reg' in the example
From: Krzysztof Kozlowski @ 2026-06-22 10:02 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau, linux-pm, linux-amlogic, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260622100231.438435-3-krzysztof.kozlowski@oss.qualcomm.com>
The example DTS is tested in a wrapped node with address/size-cells=1,
thus reg had incorrect entry leading to dt_binding_check fails:
thermal/amlogic,thermal.example.dtb: temperature-sensor@20000 (amlogic,t7-thermal): reg: [[0, 131072], [0, 80]] is too long
Fixes: b1c8ccdbd4e9 ("dt-bindings: thermal: amlogic: Add support for T7")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index d8f7f3eb7ae2..8cfa44dcda58 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -92,7 +92,7 @@ examples:
temperature-sensor@20000 {
compatible = "amlogic,t7-thermal";
- reg = <0x0 0x20000 0x0 0x50>;
+ reg = <0x20000 0x50>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clkc_periphs CLKID_TS>;
#thermal-sensor-cells = <0>;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: thermal: amlogic: Fix missing header in the example
From: Krzysztof Kozlowski @ 2026-06-22 10:02 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau, linux-pm, linux-amlogic, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Usage of defines from headers requires including relevant header,
otherwise dt_binding_check fails:
Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:59.27-34 Unexpected 'GIC_SPI'
Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:59.38-57 Unexpected 'IRQ_TYPE_LEVEL_HIGH'
Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:60.37-45 Unexpected 'CLKID_TS'
Fixes: b1c8ccdbd4e9 ("dt-bindings: thermal: amlogic: Add support for T7")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Fix for current RC - commit already pulled in merge window.
This should be applied fast to fix current RC, thus maybe Rob?
---
Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index e28612510d67..d8f7f3eb7ae2 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -87,6 +87,9 @@ examples:
amlogic,ao-secure = <&sec_AO>;
};
- |
+ #include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
temperature-sensor@20000 {
compatible = "amlogic,t7-thermal";
reg = <0x0 0x20000 0x0 0x50>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: Jonathan Cameron @ 2026-06-22 10:02 UTC (permalink / raw)
To: Kurt Borja
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nguyen Minh Tien, linux-iio,
devicetree, linux-kernel
In-Reply-To: <DJF5LHOE6368.2QCY5LIPT8098@gmail.com>
On Sun, 21 Jun 2026 19:32:29 -0500
"Kurt Borja" <kuurtb@gmail.com> wrote:
> On Sun Jun 21, 2026 at 2:14 PM -05, Jonathan Cameron wrote:
> > On Tue, 16 Jun 2026 13:16:46 -0500
> > David Lechner <dlechner@baylibre.com> wrote:
> >
> >> On 6/16/26 12:26 PM, Kurt Borja wrote:
> >> > On Tue Jun 16, 2026 at 10:21 AM -05, David Lechner wrote:
> >> >> On 6/15/26 7:18 PM, Kurt Borja wrote:
> >> >>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
> >>
> >> ...
> >>
> >> >>>> All of these chips have in common that they are designed for use with
> >> >>>> RTDs and thermocouples and so they look very similar to each other in
> >> >>>> terms of wiring and feature set, even if the register maps are
> >> >>>> different. They are in the gray area where we could either keep them
> >> >>>> separate because they are just different enough, or we could do like
> >> >>>> we've done before with ad_sigma_delta and have a bit of an abstraction
> >> >>>> layer for the register differences and otherwise try to share as much
> >> >>>> code as possible. Normally, I would lean towards keeping them separate,
> >> >>>> but in this case, I'm considering trying to share code because the
> >> >>>> devicetree bindings for the inputs is complex and is going to be mostly
> >> >>>> the same across all of these chips.
> >> >>>
> >> >>> The channel configuration is indeed very similar for the three chips.
> >> >>> All three have IDAC, BOC and VREF configurations.
> >> >>
> >> >> Hmm... I forgot to include the burnout current in the DT bindings. Following
> >> >> the channel = "conditions for measurement" pattern that I have set out here
> >> >> I guess that would mean that we would need to have the same inputs twice
> >> >> when using the burnout. One "channel" would be the one used to do a "precision"
> >> >> measurement and the other would be the one to do open/short circuit detection.
> >> >>
> >> >>
> >> >> i2c {
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >>
> >> >> adc@40 {
> >> >> compatible = "ti,ads112c14";
> >> >> reg = <0x40>;
> >> >>
> >> >> avdd-supply = <&avdd>;
> >> >> dvdd-supply = <&dvdd>;
> >> >>
> >> >> refp-supply = <&avdd>;
> >> >>
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >>
> >> >> channel@0 {
> >> >> reg = <0>;
> >> >> diff-channels = <1>, <2>;
> >> >> excitation-channels = <0>, <3>;
> >> >> excitation-current-microamp = <500>;
> >> >> current-chopping;
> >> >> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> >> label = "rtd-precision";
> >> >> };
> >> >>
> >> >> channel@1 {
> >> >> reg = <0>;
> >> >> diff-channels = <1>, <2>;
> >> >> excitation-channels = <0>, <3>;
> >> >> excitation-current-microamp = <500>;
> > Maybe use an example with more stuff changing? Do we want same excitation
> > for burn out? I've no idea.
> >
> >> >> burnout-current-nanoamp = <1000>;
> >> >> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> >> label = "rtd-diagnostic";
> >> >> };
> >> >
> >> > This would mean we wouldn't be able to use iio_chan_spec .channel and
> >> > .channel2 to describe inputs because of duplicate sysfs attributes, no?
> >> >
> >>
> >> Yes, that is a bit unfortunate. At least there the labels to tell them
> >> apart. I guess we would just need to use consecutive channel and channel2
> >> when dynamically allocating the channels to avoid conflict.
> >
> > From a very initial look, maybe do something similar to the folk have
> > been looking at for the more complex DDS devices where we have lots
> > of channels that are on the same 'wires'. Basically add a numbering
> > scheme to keep them reasonably separate - channel numbers are cheap.
> > Maybe first channel is 10->1f, second 20-2f etc. They are differential
> > so it will get ugly. Perhaps have a play around and see if there is
> > a reasonable channel naming scheme for this 'same inputs, different thing
> > being measured case'
>
> May I also suggest having some sort of IIO_VOLTAGE_DIAGNOSTIC channel
> type? Would that be worth the trouble?
Nope. That would get messy fast as any channel type could have a diagnostic
variant. If we only ever want to poll it from sysfs we could use
an info_mask element so in_voltageX_burnoutraw or something like that.
>
> We could also maybe just drop burn-out current completely from
> dt-bindings and add IIO_CHAN_INFO_BURNOUT_CURRENT. Given that this
> feature is only used ocasionally for diagnostic purposes (I assume...).
I did wonder if we just push this either into debugfs, or into an
events type interface. So poll it every now and then or on demand.
>
^ permalink raw reply
* Re: [PATCH v5 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Krzysztof Kozlowski @ 2026-06-22 10:02 UTC (permalink / raw)
To: linux-kernel-dev, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Conor Dooley
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-1-9040ca36afe2@aliel.fr>
On 24/04/2026 17:45, Ronald Claveau via B4 Relay wrote:
> + - |
> + temperature-sensor@20000 {
> + compatible = "amlogic,t7-thermal";
> + reg = <0x0 0x20000 0x0 0x50>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
This wasn't ever even built! Really, it fails immediately. I will send
fixes, but quite disappointing that contributor does not test its own code.-
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: Joshua Crofts @ 2026-06-22 9:55 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260622-axiado-ax3000-ax3005-saradc-v3-2-e57c7c7ae675@axiado.com>
On Mon, 22 Jun 2026 00:47:28 -0700
Petar Stepanovic <pstepanovic@axiado.com> wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
>
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.
>
> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
> ---
> + info->clk_rate = clk_get_rate(info->clk);
> + if (!info->clk_rate)
> + return dev_err_probe(dev, -EINVAL, "invalid clock rate\n");
> +
> + ret = devm_regulator_get_enable_read_voltage(dev, "vref");
> + if (ret < 0)
> + return dev_err_probe(dev, info->vref_uV,
> + "failed to get vref voltage\n");
Sashiko raised an issue that I've missed on previous reads - why
are you using info->vref_uV in dev_err_probe()? The info struct
is not zeroed out on initialization, which means that dev_err_probe
will return a different value each time when read_voltage() fails.
It was designed to accept the retval from whatever function we're
checking.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Jonathan Cameron @ 2026-06-22 9:55 UTC (permalink / raw)
To: David Lechner
Cc: Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree,
linux-kernel
In-Reply-To: <da875b00-6f93-444b-982c-30b8001dd8e0@baylibre.com>
On Sun, 21 Jun 2026 16:14:57 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 6/21/26 1:41 PM, Jonathan Cameron wrote:
> > On Mon, 15 Jun 2026 16:59:59 -0500
> > "David Lechner (TI)" <dlechner@baylibre.com> wrote:
> >
> >> Add new bindings for ti,ads122c14 and similar devices.
> >>
> >> This is an ADC that is primarily intended for use with temperature
> >> sensors. There are a few unusual properties because of this. In
> >> particular, the reference voltage source and current output requirements
> >> can be different for each measurement, so these are included in the
> >> channel bindings.
> >>
> >> The REFP/REFN reference voltage is usually just connected to a resistor
> >> that is being driven by the ADC's current outputs, so there is special
> >> property for this case rather than requiring a regulator to be defined
> >> to represent that.
> >>
> >> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> >> have preferred an enum of strings).
> >>
> >> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> >
> > A few queries inline though I'm only just starting to get my head
> > around this device...
> >
> > Thanks
> >
> > Jonathan
> >
> >> ---
> >> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
> >> MAINTAINERS | 7 +
> >> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
> >> 3 files changed, 242 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> new file mode 100644
> >> index 000000000000..dc7f37cad772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> @@ -0,0 +1,224 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments' ADS112C14 and similar ADC chips
> >> +
> >> +description: |
> >> + Supports the following Texas Instruments' ADC chips:
> >> + - ADS112C14 (16-bit)
> >> + - ADS122C14 (24-bit)
> >> +
> >> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> >> +
> >> + These chips are primarily designed for use with temperature sensors such as
> >> + RTDs and thermocouples. The channel bindings reflect this in that each channel
> >> + represents the conditions required to make a measurement rather than strictly
> >> + just the physical input channels.
> >> +
> >> +maintainers:
> >> + - David Lechner <dlechner@baylibre.com>
> >> +
> >> +unevaluatedProperties: false
> >> +
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - ti,ads112c14
> >> + - ti,ads122c14
> >> +
> >> + reg:
> >> + items:
> >> + - minimum: 0x40
> >> + maximum: 0x47
> >> +
> >> + clocks:
> >> + maxItems: 1
> >> + description: Optional external clock connected to GPIO3 pin.
> >> +
> >> + avdd-supply: true
> >> + dvdd-supply: true
> >> +
> >> + refp-supply: true
> >> + refn-supply: true
> >> +
> >> + refp-refn-resistor-ohms:
> >> + description:
> >> + The resistance of the external resistor between REFP and REFN when using
> >> + resistor bridge driven by current outputs for RTD measurements.
> >> +
> >> + interrupts:
> >> + minItems: 1
> >> + items:
> >> + - description: FAULT interrupt (GPIO2 pin)
> >> + - description: DRDY interrupt (GPIO3 pin)
> >> +
> >> + interrupt-names:
> >> + minItems: 1
> >> + maxItems: 2
> >> + items:
> >> + enum: [fault, drdy]
> >> +
> >> + gpio-controller: true
> >> + '#gpio-cells':
> >> + const: 2
> >> +
> >> + '#address-cells':
> >> + const: 1
> >> +
> >> + '#size-cells':
> >> + const: 0
> >> +
> >> +patternProperties:
> >> + ^channel@[0-7]$:
> >> + $ref: adc.yaml
> >> +
> >> + unevaluatedProperties: false
> >> +
> >> + properties:
> >> + reg:
> >> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
> >> +
> >> + single-channel:
> >> + maximum: 7
> >> +
> >> + diff-channels:
> >> + items:
> >> + maximum: 7
> >> +
> >> + bipolar:
> >> + description:
> >> + Set this flag if the differential input can be negative.
> >
> > I'd leave that description to adc.yaml Maybe that doc could be improved though
> > given it basically says bipolar == bipolar mode ;)
>
> It seems not always obvious to me which properties from adc.yaml apply
> and which ones don't to a given ADC that makes use of it. So I was
> hoping to have some way of saying that bipolar is applicable to this
> chip.
bipolar: true
should be enough I think.
>
> >
> >> +
> >> + excitation-channels:
> >> + description: AINx pins used as current output.
> >> + $ref: /schemas/types.yaml#/definitions/uint32-array
> >> + minItems: 1
> >> + maxItems: 2
> >> + items:
> >> + maximum: 7
> >> +
> >> + excitation-current-microamp:
> >
> > There seem to be separate controls. Are their usecases where this needs
> > to be in array?
>
> I'll have to ask, but probably yes since there are separate controls
> so `maxItems: 2` would be appropriate.
>
> >
> >> + description: The current output of the excitation channels in microamps.
> >> + minimum: 1
> >> + maximum: 1000
> >> +
> >> + current-chopping:
> >> + $ref: /schemas/types.yaml#/definitions/flag
> >> + description:
> >> + If provided, the two excitation channels are to be used with current
> >> + chopping enabled.
> >
> > Can I have a reference for that? My initial read suggests it's the input channels
>
> No. :-)
>
> I must have got two ideas mixed together in my head to come up with
> this. Clearly this should be `input-channel-rotation` or something like
> that (we discussed in another thread already). Also curious if you thing
> any of these properties are common enough to promote to adc.yaml or if we
> should just make them e.g. `ti,input-channel-rotation` (you might not have
> had time to read the threads on that yet).
It's turned up in a couple of drivers and the concept is fairly standard I think
so I'm fine with promoting this to a top level property if the definition can
be generic enough.
For a non TI example, the LTC2893 has this as well for it's thermistor settings.
It might be worth comparing the approach given here with what we have there.
In that case there are specific node types for different types of things that
are wired up with constraints on things like excitation currents.
It kind of constrains things to the sane known use cases. However that is
partly because that device does (I think) more type specific handling than
we have here.
>
> > that are chopped. For GC_EN
> > "When enabled, the device automatically swaps
> > the analog inputs and takes the average of two consecutive conversions to
> > cancel the internal offset voltage"
> >
> >
> >> +
> >> + ti,vref-source:
> >> + description: |
> >> + Indicates the source for the reference voltage for this channel.
> >> + 0 - Internal 2.5V reference
> >> + 1 - Internal 1.25V reference
> >> + 2 - External reference (REFP-REFN)
> >> + 3 - AVDD as reference
> >> +
> >> + For convenience, macros for these values are available in
> >> + dt-bindings/iio/adc/ti,ads112c14.h.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> + maximum: 3
> >> + default: 0
> >> +
> >> + dependencies:
> >> + excitation-channels: [ excitation-current-microamp ]
> >> + excitation-current-microamp: [ excitation-channels ]
> >> + current-chopping: [ excitation-channels ]
> >> +
> >> + oneOf:
> >> + - required: [ single-channel ]
> >> + - required: [ diff-channels ]
> >
> >> +examples:
> >> + - |
> >> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> >> +
> >> + i2c {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + adc@40 {
> >> + compatible = "ti,ads112c14";
> >> + reg = <0x40>;
> >> +
> >> + avdd-supply = <&avdd>;
> >> + dvdd-supply = <&dvdd>;
> >> +
> >> + /* 3-Wire RTD: Two IDACs, One Measurement (AIN1-AIN2) */
> >> +
> >> + refp-refn-resistor-ohms = <500>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + channel@0 {
> >> + reg = <0>;
> >> + diff-channels = <1>, <2>;
> >> + excitation-channels = <0>, <3>;
> >> + excitation-current-microamp = <500>;
> >> + current-chopping;
> >> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> + label = "rtd";
> >> + };
> >> + };
> >> + };
> >> + - |
> >> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> >> +
> >> + i2c {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + adc@40 {
> >> + compatible = "ti,ads112c14";
> >> + reg = <0x40>;
> >> +
> >> + avdd-supply = <&avdd>;
> >> + dvdd-supply = <&dvdd>;
> >> +
> >> + /* Resistive Bridge Measurement With a Thermistor for Temperature Compensation*/
> >> +
> >> + refp-supply = <&avdd>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + channel@0 {
> >> + reg = <0>;
> >> + diff-channels = <6>, <7>;
> >> + bipolar;
> >> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> + label = "bridge";
> >> + };
> >> +
> >> + channel@1 {
> >> + reg = <1>;
> >> + diff-channels = <1>, <2>;
> >> + ti,vref-source = <ADS112C14_VREF_SOURCE_INTERNAL_2_5V>;
> >> + label = "thermistor";
> >
> > Hmm. I'm interested to see where this goes, but generally when we have
> > a thermistor we attempt to ultimately convert it to a temperature
> > channel and I'm not seeing info here to allow us to do that.
>
> Since the hardware doesn't have any special features for handling
> specific sensor types, it seems like a case of the driver trying to
> do things that the hardware doesn't do, which we generally try to
> avoid in the kernel.
>
> For cases where we want a quick and easy (and not necessarily accurate)
> temperature conversion done in the kernel, we could make a generic thermistor
> analog front end binding and driver like we already have for RTDs and
> (linear) temperature transducers. This seems more sensible to me rather
> than having to re-implement such a thing in each ADC that could be used
> with a thermistor.
Agreed. That would cover this case. I'll be honest I thought we had
one already ;)
>
> >
> >> + };
> >> + };
> >> + };
> >
> >
>
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Geert Uytterhoeven @ 2026-06-22 9:52 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marc Zyngier, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Fri, 19 Jun 2026 at 00:04, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The GIC600 implementation is now known to be used on multiple 64-bit
> SoCs, where it has address width for AXI or APB interface configured
> to 32 bit, and it can access only the first 4GiB of physical address
> space.
>
> Rework the handling of the quirk to work around this limitation such
> that new entries can be added purely as new compatible strings, with
> no need to add additional functions or new its_quirk array entries.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_32bit_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
__maybe_unused can be dropped...
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_32bit_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4968,14 +4975,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
... as the #ifdef is removed.
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 2/8] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
From: Qiang Yu @ 2026-06-22 9:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260622-legendary-graceful-goat-3b5d56@quoll>
On Mon, Jun 22, 2026 at 09:32:34AM +0200, Krzysztof Kozlowski wrote:
> On Sun, Jun 21, 2026 at 10:11:25PM -0700, Qiang Yu wrote:
> > Mahua shares the same QREF TX/RPT/RX component naming as Glymur, but
> > has a different topology: a single QREF block fed by REFGEN3 only,
> > rather than the two independent blocks fed by REFGEN3 and REFGEN4 on
> > Glymur.
> >
> > Add qcom,mahua-tcsr compatible and document its required supply
> > properties.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > .../bindings/clock/qcom,glymur-tcsr.yaml | 68 ++++++++++++++++------
> > 1 file changed, 50 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> > index 16fc6ab87f9b..2b6422627165 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> > @@ -20,7 +20,9 @@ description: |
> > properties:
> > compatible:
> > items:
> > - - const: qcom,glymur-tcsr
> > + - enum:
> > + - qcom,glymur-tcsr
>
> You could have made this enum in the first patch, so you would avoid
> changing the same line twice. Usually adding line in patch #1 and then
> removing it in patch #2 is indication of something to improve.
>
Okay, will use
- enum:
- qcom,glymur-tcsr
in the first patch in next version.
- Qiang Yu
> > + - qcom,mahua-tcsr
> > - const: syscon
> >
> > clocks:
> > @@ -41,9 +43,11 @@ properties:
> > vdda-qrefrpt2-0p9-supply: true
> > vdda-qrefrpt3-0p9-supply: true
> > vdda-qrefrpt4-0p9-supply: true
> > + vdda-qrefrpt5-0p9-supply: true
> > vdda-qrefrx0-0p9-supply: true
> > vdda-qrefrx1-0p9-supply: true
> > vdda-qrefrx2-0p9-supply: true
> > + vdda-qrefrx3-0p9-supply: true
> > vdda-qrefrx4-0p9-supply: true
> > vdda-qrefrx5-0p9-supply: true
> > vdda-qreftx0-0p9-supply: true
> > @@ -54,26 +58,54 @@ properties:
> > vdda-refgen4-0p9-supply: true
> > vdda-refgen4-1p2-supply: true
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: qcom,glymur-tcsr
> > + then:
> > + required:
> > + - vdda-qrefrpt0-0p9-supply
> > + - vdda-qrefrpt1-0p9-supply
> > + - vdda-qrefrpt2-0p9-supply
> > + - vdda-qrefrpt3-0p9-supply
> > + - vdda-qrefrpt4-0p9-supply
> > + - vdda-qrefrx0-0p9-supply
> > + - vdda-qrefrx1-0p9-supply
> > + - vdda-qrefrx2-0p9-supply
> > + - vdda-qrefrx4-0p9-supply
> > + - vdda-qrefrx5-0p9-supply
> > + - vdda-qreftx0-0p9-supply
> > + - vdda-qreftx0-1p2-supply
> > + - vdda-qreftx1-0p9-supply
> > + - vdda-refgen3-0p9-supply
> > + - vdda-refgen3-1p2-supply
> > + - vdda-refgen4-0p9-supply
> > + - vdda-refgen4-1p2-supply
>
> It is fine, although this you could as well keep like that in first
> patch and mention in commit msg, that binding will grow, thus you
> already define if:then: block to accommodate future changes.
>
Okay, I will add the if:then: block in first patch and add some
description in commit msg. Then I also don't need to remove 'Mark the
relevant supplies as required per compatible using allOf/if/then
conditionals' in commit msg of first patch.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH v4 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: sashiko-bot @ 2026-06-22 9:48 UTC (permalink / raw)
To: Yu-Chun Lin; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260622092335.1166876-4-eleanor.lin@realtek.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incorrect hardware configuration and filtering for IRQ_TYPE_EDGE_BOTH causes missed falling edges and spurious double-interrupts.
- [High] Unmapped level interrupts are not masked, causing an infinite interrupt storm.
- [High] Clearing the hardware interrupt status in the .irq_unmask callback causes lost edge interrupts.
- [Medium] The driver uses a global raw_spinlock_irqsave for all register accesses, causing severe unnecessary contention.
--
commit 2c67ad7ec485f951d81fe09ef1853cbf7ebd2d95
Author: Tzuyi Chang <tychang@realtek.com>
gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
The RTD1625 introduces a per-pin register architecture with a dedicated
32-bit control register per GPIO line. Interrupt support is optional.
> diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> new file mode 100644
> index 0000000000000..409e540bf40b3
> --- /dev/null
> +++ b/drivers/gpio/gpio-rtd1625.c
[ ... ]
> +static int rtd1625_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
> +{
> + struct rtd1625_gpio *data = gpiochip_get_data(chip);
> + u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
> +
> + if (value)
> + val |= RTD1625_GPIO_OUT;
> +
> + guard(raw_spinlock_irqsave)(&data->lock);
> +
> + writel_relaxed(val, data->base + GPIO_CONTROL(offset));
> +
> + return 0;
> +}
> +
> +static int rtd1625_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct rtd1625_gpio *data = gpiochip_get_data(chip);
> + u32 val;
> +
> + guard(raw_spinlock_irqsave)(&data->lock);
> +
> + val = readl_relaxed(data->base + GPIO_CONTROL(offset));
[Severity: Medium]
Since the RTD1625 hardware features a dedicated control register per GPIO
line and uses a Write-Enable bitmask design, do we need this global raw
spinlock?
It seems updates to individual bits are independent and atomic, and
readl_relaxed is inherently an atomic bus operation. Does wrapping these
operations in a single global lock across all 166 GPIOs unnecessarily
serialize all GPIO operations globally?
[ ... ]
> +static void rtd1625_gpio_irq_handle(struct irq_desc *desc)
> +{
[ ... ]
> + for_each_set_bit(j, &status, 32) {
> + hwirq = i + j;
> + girq = irq_find_mapping(domain, hwirq);
> + irq_type = irq_get_trigger_type(girq);
[Severity: High]
If a level interrupt fires on a pin that has no mapping (for example, if it
was left enabled by the bootloader), irq_find_mapping() returns 0 and
generic_handle_domain_irq() will return -EINVAL.
Because the child handler is never invoked, the active level interrupt is
never cleared or masked. Once the parent IRQ is unmasked, will the pending
level interrupt immediately re-trigger and cause an interrupt storm?
> +
> + /*
> + * Filter out the hardware-forced de-assert interrupt unless
> + * the user explicitly requested IRQ_TYPE_EDGE_BOTH.
> + */
> + if (irq == data->irqs[RTD1625_IRQ_DEASSERT] &&
> + irq_type != IRQ_TYPE_EDGE_BOTH)
> + continue;
> +
> + generic_handle_domain_irq(domain, hwirq);
> + }
[Severity: High]
For IRQ_TYPE_EDGE_BOTH, does this filter intentionally let the duplicate
de-assert interrupt through?
Due to the hardware quirk where a single edge triggers both the assert and
de-assert IRQ lines, it appears this would cause generic_handle_domain_irq()
to be called twice sequentially for the exact same physical rising edge.
[ ... ]
> +static void rtd1625_gpio_enable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
> +{
> + int gpda_reg_offset = rtd1625_gpio_gpda_offset(data, hwirq);
> + int gpa_reg_offset = rtd1625_gpio_gpa_offset(data, hwirq);
> + u32 clr_mask = BIT(hwirq % 32);
> + u32 val;
> +
> + guard(raw_spinlock_irqsave)(&data->lock);
> +
> + writel_relaxed(clr_mask, data->irq_base + gpa_reg_offset);
> + writel_relaxed(clr_mask, data->irq_base + gpda_reg_offset);
> + val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
> + writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
> +}
[Severity: High]
This explicitly clears any pending hardware interrupts. Since this function
is called via the irq_unmask callback (mapped to rtd1625_gpio_enable_irq),
will this cause edge interrupts to be permanently lost if a hardware edge
occurs while the IRQ is temporarily masked?
Could status clearing be restricted to irq_startup or irq_ack?
[ ... ]
> +static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
> +{
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_RISING:
> + return rtd1625_gpio_irq_set_edge_type(d, 1);
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + return rtd1625_gpio_irq_set_edge_type(d, 0);
> +
> + case IRQ_TYPE_EDGE_BOTH:
> + return rtd1625_gpio_irq_set_edge_type(d, 1);
[Severity: High]
Does this map IRQ_TYPE_EDGE_BOTH to the exact same hardware polarity
configuration as IRQ_TYPE_EDGE_RISING?
It seems the hardware will only detect rising edges and completely miss
falling edges. When combined with the filter in rtd1625_gpio_irq_handle(),
does EDGE_BOTH miss all falling edges and duplicate all rising edges?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622092335.1166876-1-eleanor.lin@realtek.com?part=3
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: install DT overlays via dtbs_install
From: Neil Armstrong @ 2026-06-22 9:47 UTC (permalink / raw)
To: Vishwas Udupa, krzk
Cc: andersson, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, vudupa
In-Reply-To: <20260615162739.787779-1-vishwas.udupa@oss.qualcomm.com>
Hi Vishwas or Claude ?
On 6/15/26 18:27, Vishwas Udupa wrote:
> EL2 DTBOs are used at build time to construct DTBs corresponding to
> an EL2 (hypervisor-enabled) boot configuration. These DTBs are included in
> distributions [1] as complete boot configurations (e.g. EL1 and EL2).
>
> The EL2 configuration is not enabled by default and is typically selected
> after the initial boot by updating a UEFI runtime variable from userspace.
> Once set, firmware selects the prebuilt EL2 DTB on subsequent boots.
>
> Although EL2 DTBOs are not used directly at runtime during initial boot,
> they are required to generate and package the EL2 DTBs in the image so that
> firmware can switch to EL2 when the configuration variable is enabled. Hence, el2 dtbo's
> need to be retained.
>
> 1: https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/qcom-next-fitimage.its#L273
Pretty sure we can directly ask the question to an AI assistant ourselves,
and I'm rather sure Krzysztof which is maintaining and reviewing DT for years doesn't
need a lesson from Claude or any AI assistant you use to assist you.
Neil
^ permalink raw reply
* Re: [PATCH 2/5] iio: adc: Add ti-ads1262 driver
From: Jonathan Cameron @ 2026-06-22 9:47 UTC (permalink / raw)
To: Kurt Borja
Cc: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, Bartosz Golaszewski, David Lechner,
Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, linux-gpio
In-Reply-To: <DJF5ATR2RPDJ.3LSN8DY58E6RO@gmail.com>
On Sun, 21 Jun 2026 19:18:33 -0500
"Kurt Borja" <kuurtb@gmail.com> wrote:
> On Sun Jun 21, 2026 at 9:33 AM -05, Jonathan Cameron wrote:
> > On Mon, 15 Jun 2026 06:30:28 +0200
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> >> On 14/06/2026 22:56, Kurt Borja wrote:
> >> > On Sat Jun 13, 2026 at 1:59 PM -05, Krzysztof Kozlowski wrote:
> >> >
> >> > [...]
> >> >
> >> >> Functions used by probe() should be before probe(), not somewhere in the
> >> >> middle of the code. IOW, entire probe is together.
> >> >
> >> > I they all are, it's just that regmap stuff takes a huge chunk. I'll
> >> > check how to reorganize.
> >> >
> >> > [...]
> >> >
> >> >>> +static const struct of_device_id ads1262_of_match[] = {
> >> >>> + { .compatible = "ti,ads1262" },
> >> >>> + { .compatible = "ti,ads1263" },
> >> >>
> >> >> So devices are fully compatible? Then it should be expressed in the
> >> >> binding and drop one entry here.
> >> >
> >> > Not fully compatible as Jonathan said. One is a subset of the other.
> >>
> >> This is THE meaning of compatible!
> >
> > This one I'm in agreement with. It is a strict subset, so should be
> > using a fallback. If the fallback is used, you just get support of the
> > stuff in the simpler chip (or if you can override it with a chip ID
> > you might still 'upgrade' to the more complex driver support).
> > If you do end up with properties that only apply to 'new' parts of
> > the more complex chip then they should be verified as part of the
> > binding (assuming you can do that without the verifier complaining
> > - I haven't checked!)
>
> In v1 I had the "adc" subnode which was specific to ADS1263. Then I
> agreed to drop the subnode but I'm having second thoughts...
>
> If we dropped it, then we would still have some specific stuff.
> #io-channel-cells would be "const: 2" in ADS1263 chips. Also ADS1263's
> channels would have an extra ti,vref-adc2 prop, for ADC2 voltage
> reference selection. I should maybe also add a vref-adc2-supply.
>
> Maybe it's better to keep the subnode or, again, go for something like:
>
> spi {
> multi-adc@0 {
> adc@0 {
> ...
> vref-suppy = <&adc1-vref>;
>
> channel@0 {
> ...
> reference-source = <ADS1262_VREF_AIN0_AIN1>;
> };
> };
> adc@1 {
> ...
> vref-suppy = <&adc2-vref>;
>
> channel@0 {
> ...
> reference-source = <ADS1262_VREF_AIN2_AIN3>;
> };
> };
> };
> };
>
> In this case we would have to kinda duplicate channel description, but I
> don't think it's that bad.
>
> Jonathan, Krzysztof, David, thoughts?
>
> IMO the ADC2 specific voltage reference stuff is a strong argument for a
> subnode or the above solution.
Given you end up with channel specific stuff that differs I think it probably
makes sense - though I do wonder a bit if that is real. What's the use case
for using a different reference for the monitoring / debug than the main one?
I could imagine some dynamic use where you want to sanity check against
a wider reference range, but maybe that needs userspace control rather than
in here?
Jonathan
>
> >
> > The SLF3F discussion is about (to me) less obvious case of not a strict
> > subset, but rather being detectable parts with different channel related
> > properties. In that case the ID match is necessary for anything to work.
> > Anyhow, that discussion is in a different thread and not really relevant
> > here.
> >
> > Jonathan
> >
> >>
> >>
> >> Best regards,
> >> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: sashiko-bot @ 2026-06-22 9:39 UTC (permalink / raw)
To: Yu-Chun Lin; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260622092335.1166876-2-eleanor.lin@realtek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding defines the GPIO controller as an interrupt controller but fails to include `interrupt-controller` and `#interrupt-cells` in the `required` list.
--
commit c069bdfb1e6325b567084e608f2dc45bf15e2fcf
Author: Tzuyi Chang <tychang@realtek.com>
dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
This commit adds the device tree bindings for the Realtek DHC RTD1625 GPIO
controllers. It introduces support for a new per-pin register architecture
that includes separate register blocks for configuration and interrupt control.
> diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
> new file mode 100644
> index 0000000000000..f13c910b73c69
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
[ ... ]
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + gpio-ranges: true
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - gpio-ranges
> + - gpio-controller
> + - "#gpio-cells"
[Severity: Medium]
Since this binding defines the hardware as an interrupt controller, should
interrupt-controller and #interrupt-cells be included in this required list?
Omitting these provider properties might allow incomplete device tree nodes
to pass schema validation, which could then cause runtime failures for
drivers attempting to use the undocumented functionality.
> +
> +additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622092335.1166876-1-eleanor.lin@realtek.com?part=1
^ permalink raw reply
* [PATCH v1] arm64: dts: freescale: imx95-toradex-smarc: add alias for lpuart5
From: Francesco Dolcini @ 2026-06-22 9:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, devicetree, imx, linux-arm-kernel,
linux-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add alias for lpuart5 so the UART gets a stable line number.
Without this alias, the lpuart driver fails:
fsl-lpuart 42590000.serial: failed to get alias id, errno -19
This prevents the Bluetooth controller connected to this UART from
working.
Fixes: 104a391bb6ff ("arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7d760470201f..a6c5398a81e3 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -24,6 +24,7 @@ aliases {
serial1 = &lpuart1;
serial2 = &lpuart6;
serial3 = &lpuart3;
+ serial4 = &lpuart5;
};
chosen {
--
2.47.3
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Krzysztof Kozlowski
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add the device tree bindings for the Realtek DHC (Digital Home Center)
RTD1625 GPIO controllers.
The RTD1625 GPIO controller features a per-pin register architecture
that differs significantly from previous generations. It utilizes
separate register blocks for GPIO configuration and interrupt control.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v4:
- None.
---
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
new file mode 100644
index 000000000000..f13c910b73c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/realtek,rtd1625-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1625 GPIO controller
+
+maintainers:
+ - Tzuyi Chang <tychang@realtek.com>
+
+description: |
+ GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
+ architecture that differs significantly from earlier RTD series controllers.
+ Each GPIO has dedicated registers for configuration (direction, input/output
+ values, debounce), and interrupt control supporting edge and level detection
+ modes.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1625-iso-gpio
+ - realtek,rtd1625-isom-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Interrupt number of the assert GPIO interrupt, which is
+ triggered when there is a rising edge.
+ - description: Interrupt number of the deassert GPIO interrupt, which is
+ triggered when there is a falling edge.
+ - description: Interrupt number of the level-sensitive GPIO interrupt,
+ triggered by a configured logic level.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-ranges: true
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-ranges
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ interrupt-parent = <&iso_m_irq_mux>;
+ interrupts = <0>, <1>, <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Bartosz Golaszewski
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
Add the GPIO node for the Realtek RTD1625 SoC.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v4:
- None.
---
arch/arm64/boot/dts/realtek/kent.dtsi | 39 +++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index 8d4293cd4c03..228b82dfdb7a 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -151,6 +151,37 @@ uart0: serial@7800 {
status = "disabled";
};
+ gpio: gpio@31000 {
+ compatible = "realtek,rtd1625-iso-gpio";
+ reg = <0x31000 0x398>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 2>,
+ <&ve4_pinctrl 2 0 6>,
+ <&iso_pinctrl 8 0 4>,
+ <&ve4_pinctrl 12 6 2>,
+ <&main2_pinctrl 14 0 2>,
+ <&ve4_pinctrl 16 8 4>,
+ <&main2_pinctrl 20 2 3>,
+ <&ve4_pinctrl 23 12 3>,
+ <&iso_pinctrl 26 4 2>,
+ <&isom_pinctrl 28 2 2>,
+ <&ve4_pinctrl 30 15 6>,
+ <&main2_pinctrl 36 5 6>,
+ <&ve4_pinctrl 42 21 3>,
+ <&iso_pinctrl 45 6 6>,
+ <&ve4_pinctrl 51 24 1>,
+ <&iso_pinctrl 52 12 1>,
+ <&ve4_pinctrl 53 25 11>,
+ <&main2_pinctrl 64 11 28>,
+ <&ve4_pinctrl 92 36 2>,
+ <&iso_pinctrl 94 13 19>,
+ <&iso_pinctrl 128 32 4>,
+ <&ve4_pinctrl 132 38 13>,
+ <&iso_pinctrl 145 36 19>,
+ <&ve4_pinctrl 164 51 2>;
+ #gpio-cells = <2>;
+ };
+
iso_pinctrl: pinctrl@4e000 {
compatible = "realtek,rtd1625-iso-pinctrl";
reg = <0x4e000 0x1a4>;
@@ -161,6 +192,14 @@ main2_pinctrl: pinctrl@4f200 {
reg = <0x4f200 0x50>;
};
+ iso_m_gpio: gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ #gpio-cells = <2>;
+ };
+
isom_pinctrl: pinctrl@146200 {
compatible = "realtek,rtd1625-isom-pinctrl";
reg = <0x146200 0x34>;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
which manages pins via shared bank registers, the RTD1625 introduces
a per-pin register architecture. Each GPIO line now has its own
dedicated 32-bit control register to manage configuration independently,
including direction, output value, input value, interrupt enable, and
debounce. Therefore, this distinct hardware design requires a separate
driver.
Additionally, the RTD1625 GPIO controller has a specific hardware quirk:
it fires both 'assert' and 'de-assert' interrupts simultaneously on any
edge toggle. To handle this, we utilize the polarity register to route
the requested edge (rising/falling) to the 'assert' IRQ line. The driver
then filters out the unwanted 'de-assert' interrupt in the IRQ handler
and pre-clears edge interrupts to prevent interrupt storms caused by
unhandled dropped interrupts.
Interrupt support is optional for this device, matching the dt-bindings.
If the interrupts property is not provided, the driver simply skips IRQ
initialization and operates purely as a basic GPIO controller.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes between v2 and v4:
IRQ Handling Fix
- Added enum rtd1625_irq_index with named constants to replace magic array
indices 0/1/2.
- Documented hardware quirk.
Coding style & cleanup:
- In rtd1625_gpio_irq_set_type(), using return directly in each switch case.
- Changed int loop counters to unsigned int.
- Replaced devm_kzalloc() with devm_kcalloc() in probe.
- Moved of_device_id table closer to its user.
- Added static to DEFINE_NOIRQ_DEV_PM_OPS.
- Formatting consistency: zero-padded hex constants.
New header:
- Added #include <linux/cleanup.h> (required for the guard() / scoped_guard()
macros).
Copyright year updated:
- 2023 -> 2023-2026.
---
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 611 ++++++++++++++++++++++++++++++++++++
3 files changed, 624 insertions(+)
create mode 100644 drivers/gpio/gpio-rtd1625.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed2bc3113374..f03c05288376 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -656,6 +656,18 @@ config GPIO_RTD
Say yes here to support GPIO functionality and GPIO interrupt on
Realtek DHC SoCs.
+config GPIO_RTD1625
+ tristate "Realtek DHC RTD1625 GPIO support"
+ depends on ARCH_REALTEK || COMPILE_TEST
+ default ARCH_REALTEK
+ select GPIOLIB_IRQCHIP
+ help
+ This option enables support for the GPIO controller on Realtek
+ DHC (Digital Home Center) RTD1625 SoC.
+
+ Say yes here to support both basic GPIO line functionality
+ and GPIO interrupt handling capabilities for this platform.
+
config GPIO_SAMA5D2_PIOBU
tristate "SAMA5D2 PIOBU GPIO support"
depends on OF
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4d0e900402fc..fa14581e3995 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
obj-$(CONFIG_GPIO_REG) += gpio-reg.o
obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
+obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
new file mode 100644
index 000000000000..409e540bf40b
--- /dev/null
+++ b/drivers/gpio/gpio-rtd1625.c
@@ -0,0 +1,611 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek DHC RTD1625 gpio driver
+ *
+ * Copyright (c) 2023-2026 Realtek Semiconductor Corp.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/gpio/driver.h>
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define RTD1625_GPIO_DIR BIT(0)
+#define RTD1625_GPIO_OUT BIT(2)
+#define RTD1625_GPIO_IN BIT(4)
+#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
+#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
+#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
+#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
+#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
+#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
+
+#define RTD1625_GPIO_WREN(x) ((x) << 1)
+
+/* Write-enable masks for all GPIO configs and reserved hardware bits */
+#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
+#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
+
+#define RTD1625_GPIO_DEBOUNCE_1US 0
+#define RTD1625_GPIO_DEBOUNCE_10US 1
+#define RTD1625_GPIO_DEBOUNCE_100US 2
+#define RTD1625_GPIO_DEBOUNCE_1MS 3
+#define RTD1625_GPIO_DEBOUNCE_10MS 4
+#define RTD1625_GPIO_DEBOUNCE_20MS 5
+#define RTD1625_GPIO_DEBOUNCE_30MS 6
+#define RTD1625_GPIO_DEBOUNCE_50MS 7
+
+#define GPIO_CONTROL(gpio) ((gpio) * 4)
+
+enum rtd1625_irq_index {
+ RTD1625_IRQ_ASSERT,
+ RTD1625_IRQ_DEASSERT,
+ RTD1625_IRQ_LEVEL,
+ RTD1625_MAX_IRQS
+};
+
+/**
+ * struct rtd1625_gpio_info - Specific GPIO register information
+ * @num_gpios: The number of GPIOs
+ * @irq_type_support: Supported IRQ types
+ * @gpa_offset: Offset for GPIO assert interrupt status registers
+ * @gpda_offset: Offset for GPIO deassert interrupt status registers
+ * @level_offset: Offset of level interrupt status register
+ * @write_en_all: Write-enable mask for all configurable bits
+ */
+struct rtd1625_gpio_info {
+ unsigned int num_gpios;
+ unsigned int irq_type_support;
+ unsigned int base_offset;
+ unsigned int gpa_offset;
+ unsigned int gpda_offset;
+ unsigned int level_offset;
+ unsigned int write_en_all;
+};
+
+struct rtd1625_gpio {
+ struct gpio_chip gpio_chip;
+ const struct rtd1625_gpio_info *info;
+ void __iomem *base;
+ void __iomem *irq_base;
+ unsigned int irqs[RTD1625_MAX_IRQS];
+ raw_spinlock_t lock;
+ unsigned int *save_regs;
+};
+
+static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpa_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpda_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->level_offset + ((offset / 32) * 4);
+}
+
+static int rtd1625_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+ unsigned int debounce)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u8 deb_val;
+ u32 val;
+
+ switch (debounce) {
+ case 1:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1US;
+ break;
+ case 10:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10US;
+ break;
+ case 100:
+ deb_val = RTD1625_GPIO_DEBOUNCE_100US;
+ break;
+ case 1000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1MS;
+ break;
+ case 10000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10MS;
+ break;
+ case 20000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_20MS;
+ break;
+ case 30000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_30MS;
+ break;
+ case 50000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_50MS;
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ val = FIELD_PREP(RTD1625_GPIO_DEBOUNCE, deb_val) | RTD1625_GPIO_DEBOUNCE_WREN;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ u32 debounce;
+
+ if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE) {
+ debounce = pinconf_to_config_argument(config);
+ return rtd1625_gpio_set_debounce(chip, offset, debounce);
+ }
+
+ return gpiochip_generic_config(chip, offset, config);
+}
+
+static int rtd1625_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
+
+ if (value)
+ val |= RTD1625_GPIO_OUT;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return !!(val & RTD1625_GPIO_OUT);
+ else
+ return !!(val & RTD1625_GPIO_IN);
+}
+
+static int rtd1625_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return GPIO_LINE_DIRECTION_OUT;
+
+ return GPIO_LINE_DIRECTION_IN;
+}
+
+static int rtd1625_gpio_set_direction(struct gpio_chip *chip, unsigned int offset, bool out)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_DIR);
+
+ if (out)
+ val |= RTD1625_GPIO_DIR;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ return rtd1625_gpio_set_direction(chip, offset, false);
+}
+
+static int rtd1625_gpio_direction_output(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ rtd1625_gpio_set(chip, offset, value);
+
+ return rtd1625_gpio_set_direction(chip, offset, true);
+}
+
+static void rtd1625_gpio_irq_handle(struct irq_desc *desc)
+{
+ unsigned int (*get_reg_offset)(struct rtd1625_gpio *gpio, unsigned int offset);
+ struct rtd1625_gpio *data = irq_desc_get_handler_data(desc);
+ struct irq_domain *domain = data->gpio_chip.irq.domain;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int irq = irq_desc_get_irq(desc);
+ unsigned long status;
+ unsigned int reg_offset, i, j;
+ unsigned int girq;
+ irq_hw_number_t hwirq;
+ u32 irq_type;
+
+ if (irq == data->irqs[RTD1625_IRQ_ASSERT])
+ get_reg_offset = &rtd1625_gpio_gpa_offset;
+ else if (irq == data->irqs[RTD1625_IRQ_DEASSERT])
+ get_reg_offset = &rtd1625_gpio_gpda_offset;
+ else if (irq == data->irqs[2])
+ get_reg_offset = &rtd1625_gpio_level_offset;
+ else
+ return;
+
+ chained_irq_enter(chip, desc);
+
+ for (i = 0; i < data->info->num_gpios; i += 32) {
+ reg_offset = get_reg_offset(data, i);
+ status = readl_relaxed(data->irq_base + reg_offset);
+
+ /*
+ * Hardware quirk: The controller fires both "assert" and "de-assert"
+ * interrupts simultaneously on any edge toggle.
+ * We must pre-clear edge interrupts here. If we drop an unwanted
+ * de-assert interrupt below, it will never reach the IRQ core
+ * (generic_handle_domain_irq), meaning ->irq_ack() won't be called.
+ * Failing to clear it here leads to an interrupt storm.
+ */
+ if (irq != data->irqs[RTD1625_IRQ_LEVEL])
+ writel_relaxed(status, data->irq_base + reg_offset);
+
+ for_each_set_bit(j, &status, 32) {
+ hwirq = i + j;
+ girq = irq_find_mapping(domain, hwirq);
+ irq_type = irq_get_trigger_type(girq);
+
+ /*
+ * Filter out the hardware-forced de-assert interrupt unless
+ * the user explicitly requested IRQ_TYPE_EDGE_BOTH.
+ */
+ if (irq == data->irqs[RTD1625_IRQ_DEASSERT] &&
+ irq_type != IRQ_TYPE_EDGE_BOTH)
+ continue;
+
+ generic_handle_domain_irq(domain, hwirq);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static void rtd1625_gpio_ack_irq(struct irq_data *d)
+{
+ struct rtd1625_gpio *data = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+ u32 bit_mask = BIT(hwirq % 32);
+ int reg_offset;
+
+ if (irq_type & IRQ_TYPE_LEVEL_MASK) {
+ reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ writel_relaxed(bit_mask, data->irq_base + reg_offset);
+ }
+}
+
+static void rtd1625_gpio_enable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int gpda_reg_offset = rtd1625_gpio_gpda_offset(data, hwirq);
+ int gpa_reg_offset = rtd1625_gpio_gpa_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + gpa_reg_offset);
+ writel_relaxed(clr_mask, data->irq_base + gpda_reg_offset);
+ val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int level_reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + level_reg_offset);
+ val = RTD1625_GPIO_LEVEL_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ gpiochip_enable_irq(gc, hwirq);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_enable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_enable_level_irq(data, hwirq);
+}
+
+static void rtd1625_gpio_disable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_disable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_disable_level_irq(data, hwirq);
+
+ gpiochip_disable_irq(gc, hwirq);
+}
+
+static int rtd1625_gpio_irq_set_level_type(struct irq_data *d, bool level)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK))
+ return -EINVAL;
+
+ if (level)
+ val |= RTD1625_GPIO_LEVEL_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_level_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_edge_type(struct irq_data *d, bool polarity)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_EDGE_BOTH))
+ return -EINVAL;
+
+ if (polarity)
+ val |= RTD1625_GPIO_EDGE_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_edge_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ switch (type & IRQ_TYPE_SENSE_MASK) {
+ case IRQ_TYPE_EDGE_RISING:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_EDGE_FALLING:
+ return rtd1625_gpio_irq_set_edge_type(d, 0);
+
+ case IRQ_TYPE_EDGE_BOTH:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_LEVEL_HIGH:
+ return rtd1625_gpio_irq_set_level_type(d, 0);
+
+ case IRQ_TYPE_LEVEL_LOW:
+ return rtd1625_gpio_irq_set_level_type(d, 1);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static struct irq_chip rtd1625_iso_gpio_irq_chip = {
+ .name = "rtd1625-gpio",
+ .irq_ack = rtd1625_gpio_ack_irq,
+ .irq_mask = rtd1625_gpio_disable_irq,
+ .irq_unmask = rtd1625_gpio_enable_irq,
+ .irq_set_type = rtd1625_gpio_irq_set_type,
+ .flags = IRQCHIP_IMMUTABLE | IRQCHIP_SKIP_SET_WAKE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
+static int rtd1625_gpio_setup_irq(struct platform_device *pdev, struct rtd1625_gpio *data)
+{
+ struct gpio_irq_chip *irq_chip;
+ unsigned int num_irqs;
+ int irq;
+
+ /*
+ * Interrupt support is optional. All IRQs must be provided together.
+ * If index 0 is missing, we assume no interrupts are configured in DT
+ * and fall back to basic GPIO operation.
+ */
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq == -ENXIO)
+ return 0;
+ if (irq < 0)
+ return irq;
+
+ num_irqs = (data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK) ? 3 : 2;
+ data->irqs[RTD1625_IRQ_ASSERT] = irq;
+
+ for (unsigned int i = 1; i < num_irqs; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return irq;
+ data->irqs[i] = irq;
+ }
+
+ irq_chip = &data->gpio_chip.irq;
+ irq_chip->handler = handle_bad_irq;
+ irq_chip->default_type = IRQ_TYPE_NONE;
+ irq_chip->parent_handler = rtd1625_gpio_irq_handle;
+ irq_chip->parent_handler_data = data;
+ irq_chip->num_parents = num_irqs;
+ irq_chip->parents = data->irqs;
+
+ gpio_irq_chip_set_chip(irq_chip, &rtd1625_iso_gpio_irq_chip);
+
+ return 0;
+}
+
+static int rtd1625_gpio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rtd1625_gpio *data;
+ void __iomem *irq_base;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->info = device_get_match_data(dev);
+ if (!data->info)
+ return -EINVAL;
+
+ raw_spin_lock_init(&data->lock);
+
+ irq_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(irq_base))
+ return PTR_ERR(irq_base);
+
+ data->irq_base = irq_base;
+ data->base = irq_base + data->info->base_offset;
+
+ data->save_regs = devm_kcalloc(dev, data->info->num_gpios, sizeof(*data->save_regs),
+ GFP_KERNEL);
+ if (!data->save_regs)
+ return -ENOMEM;
+
+ data->gpio_chip.label = dev_name(dev);
+ data->gpio_chip.base = -1;
+ data->gpio_chip.ngpio = data->info->num_gpios;
+ data->gpio_chip.request = gpiochip_generic_request;
+ data->gpio_chip.free = gpiochip_generic_free;
+ data->gpio_chip.get_direction = rtd1625_gpio_get_direction;
+ data->gpio_chip.direction_input = rtd1625_gpio_direction_input;
+ data->gpio_chip.direction_output = rtd1625_gpio_direction_output;
+ data->gpio_chip.set = rtd1625_gpio_set;
+ data->gpio_chip.get = rtd1625_gpio_get;
+ data->gpio_chip.set_config = rtd1625_gpio_set_config;
+ data->gpio_chip.parent = dev;
+
+ ret = rtd1625_gpio_setup_irq(pdev, data);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, data);
+
+ return devm_gpiochip_add_data(dev, &data->gpio_chip, data);
+}
+
+static const struct rtd1625_gpio_info rtd1625_iso_gpio_info = {
+ .num_gpios = 166,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH,
+ .base_offset = 0x100,
+ .gpa_offset = 0x000,
+ .gpda_offset = 0x020,
+ .write_en_all = RTD1625_ISO_GPIO_WREN_ALL,
+};
+
+static const struct rtd1625_gpio_info rtd1625_isom_gpio_info = {
+ .num_gpios = 4,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_LOW |
+ IRQ_TYPE_LEVEL_HIGH,
+ .base_offset = 0x20,
+ .gpa_offset = 0x00,
+ .gpda_offset = 0x04,
+ .level_offset = 0x18,
+ .write_en_all = RTD1625_ISOM_GPIO_WREN_ALL,
+};
+
+static int rtd1625_gpio_suspend(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ data->save_regs[i] = readl_relaxed(data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static int rtd1625_gpio_resume(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ writel_relaxed(data->save_regs[i] | info->write_en_all,
+ data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static DEFINE_NOIRQ_DEV_PM_OPS(rtd1625_gpio_pm_ops, rtd1625_gpio_suspend, rtd1625_gpio_resume);
+
+static const struct of_device_id rtd1625_gpio_of_matches[] = {
+ { .compatible = "realtek,rtd1625-iso-gpio", .data = &rtd1625_iso_gpio_info },
+ { .compatible = "realtek,rtd1625-isom-gpio", .data = &rtd1625_isom_gpio_info },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rtd1625_gpio_of_matches);
+
+static struct platform_driver rtd1625_gpio_platform_driver = {
+ .driver = {
+ .name = "gpio-rtd1625",
+ .of_match_table = rtd1625_gpio_of_matches,
+ .pm = pm_sleep_ptr(&rtd1625_gpio_pm_ops),
+ },
+ .probe = rtd1625_gpio_probe,
+};
+module_platform_driver(rtd1625_gpio_platform_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Realtek Semiconductor Corporation");
+MODULE_DESCRIPTION("Realtek DHC SoC RTD1625 gpio driver");
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/4] gpio: realtek: Add support for Realtek DHC RTD1625
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
This series adds GPIO support for the Realtek DHC RTD1625 SoC.
Unlike the existing driver (gpio-rtd.c) which uses shared bank registers,
the RTD1625 features a per-pin register architecture where each GPIO line
is managed by its own dedicated 32-bit control register. This distinct
hardware design requires a new, separate driver.
Best Regards,
Yu-Chun Lin
---
Patches 1-3 (fix, dt-bindings, and driver) are targeted for the GPIO tree.
Patch 4 (dts) will be taken via the Realtek SoC tree later. It is included
here for context.
Changes in v4:
- Reverted to the v2 approach (without gpio-regmap integration).
As a result, dropped patches 2, 3, and 4 from the v3 series.
Changes in Patch 3 (driver) since v2:
- IRQ handling fixes:
- Added enum rtd1625_irq_index with named constants.
- Documented the hardware quirk.
- Code cleanup and coding style improvements.
- Included the <linux/cleanup.h> header.
- Updated the copyright year.
- Retained Linus Walleij's Reviewed-by tag from v1, as the recent updates are
cleanups and fixes rather than major feature changes.
(Linus, please let me know if you have any concerns regarding this).
v3: https://lore.kernel.org/lkml/20260512033317.1602537-1-eleanor.lin@realtek.com/
v2: https://lore.kernel.org/lkml/20260408025243.1155482-1-eleanor.lin@realtek.com/
v1: https://lore.kernel.org/lkml/20260331113835.3510341-1-eleanor.lin@realtek.com/
Tzuyi Chang (2):
dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Yu-Chun Lin (2):
gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
arm64: dts: realtek: Add GPIO support for RTD1625
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 ++
arch/arm64/boot/dts/realtek/kent.dtsi | 39 ++
drivers/gpio/Kconfig | 14 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 611 ++++++++++++++++++
5 files changed, 735 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
create mode 100644 drivers/gpio/gpio-rtd1625.c
--
2.43.0
^ permalink raw reply
* [PATCH v4 2/4] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
Replace "default y" with "default ARCH_REALTEK" to avoid bloating the build
for non-Realtek platforms when COMPILE_TEST is enabled on other platforms.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v4:
- None.
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 28cf6d2e83c2..ed2bc3113374 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -646,7 +646,7 @@ config GPIO_ROCKCHIP
config GPIO_RTD
tristate "Realtek DHC GPIO support"
depends on ARCH_REALTEK || COMPILE_TEST
- default y
+ default ARCH_REALTEK
select GPIOLIB_IRQCHIP
help
This option enables support for GPIOs found on Realtek DHC(Digital
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: Konrad Dybcio @ 2026-06-22 9:33 UTC (permalink / raw)
To: Jason Pettit, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V
In-Reply-To: <20260620-glymur-send-v1-2-fc4a2cfd107c@oss.qualcomm.com>
On 6/21/26 6:50 AM, Jason Pettit wrote:
> Add board support for the HP EliteBook X G2q 14" Next Gen AI PC
> (product SKU C4JG0AV, board 8E91), a Snapdragon X2 Elite (Glymur)
> laptop, using the "hp,elitebook-x-g2q" / "qcom,glymur" compatible.
>
> Enabled by this device tree:
>
> - internal eDP panel (samsung,atna33xc20)
> - 2x USB Type-C with DisplayPort alt-mode and USB
> - chassis HDMI output
> - chassis USB-A host port (usb_mp multiport controller)
> - internal eUSB2 host with the Elan fingerprint reader
> - NVMe SSD on PCIe5
> - Wi-Fi and Bluetooth
> - HID-over-I2C keyboard, touchpad, touchscreen; lid switch
> - Adreno GPU and GMU (Freedreno GL on Mesa)
> - audio playback and capture
[...]
> + /* Left side display-adjacent port */
> + connector@0 {
> + compatible = "usb-c-connector";
> + reg = <0>;
> + power-role = "dual";
> + data-role = "dual";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pmic_glink_hs_in: endpoint {
> + remote-endpoint = <&usb_0_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + pmic_glink_ss_in: endpoint {
> + remote-endpoint = <&usb_0_qmpphy_out>;
> + };
> + };
> + };
> + };
> +
> + /* Left side user-adjacent port */
"left/right side port?"
https://support.hp.com/pl-pl/document/ish_14499364-14499440-16
[...]
> +&apps_rsc {
> + regulators-0 {
> + compatible = "qcom,pmh0101-rpmh-regulators";
> + qcom,pmic-id = "B_E0";
> +
> + vreg_l1b_e0_1p8: ldo1 {
I find these voltage suffixes not very useful (although you're free to
keep them if you prefer)
[...]
> +&i2c0 {
> + clock-frequency = <400000>;
> +
> + status = "okay";
> +
> + keyboard@3a {
> + compatible = "hid-over-i2c";
> + reg = <0x3a>;
> +
> + hid-descr-addr = <0x1>;
> + interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>;
> +
> + pinctrl-0 = <&kybd_default>;
> + pinctrl-names = "default";
> +
> + wakeup-source;
> + };
> +
> + touchpad@2c {
> + compatible = "hid-over-i2c";
> + reg = <0x2c>;
Let's sort these nodes by address (i.e. touchpad@2c < keyboard@3a)
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: dac: Add AD5529R DAC driver support
From: Jonathan Cameron @ 2026-06-22 9:31 UTC (permalink / raw)
To: Philipp Zabel
Cc: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil
In-Reply-To: <9c5104eb504e390c2267e0a17762fdb6d73d75a4.camel@pengutronix.de>
On Mon, 22 Jun 2026 11:12:19 +0200
Philipp Zabel <p.zabel@pengutronix.de> wrote:
> On Di, 2026-05-19 at 17:42 +0200, Janani Sunil wrote:
> > Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
> >
> > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/iio/dac/Kconfig | 17 ++
> > drivers/iio/dac/Makefile | 1 +
> > drivers/iio/dac/ad5529r.c | 527 ++++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 546 insertions(+)
> >
> [...]
> > diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
> > new file mode 100644
> > index 000000000000..9bb63030db95
> > --- /dev/null
> > +++ b/drivers/iio/dac/ad5529r.c
> > @@ -0,0 +1,527 @@
> [...]
> > +static int ad5529r_reset(struct ad5529r_state *st)
> > +{
> > + struct reset_control *rst;
> > + int ret;
> > +
> > + rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
>
> Consider using devm_reset_control_get_optional_exclusive_deasserted()
> to save a few lines, and to make sure the reset line is asserted again
> when the driver is unbound.
Given we can't assume it's a gpio reset at this level (it is but meh,
we shouldn't use the API that way), we can't guarantee it was ever asserted
so we probably have to do a dance of assert then deassert.
This is one of Sashiko's favourite things to complain about so
we ended up doing some digging into that path a few weeks back.
I'd really like that not to be the case so maybe that analysis is wrong.
Jonathan
>
> > + if (IS_ERR(rst))
> > + return PTR_ERR(rst);
> > +
> > + if (rst) {
> > + ret = reset_control_deassert(rst);
> > + if (ret)
> > + return ret;
>
> This branch could then be removed.
>
> > + } else {
> > + ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
> > + AD5529R_INTERFACE_CONFIG_A_SW_RESET);
> > + if (ret)
> > + return ret;
> > + }
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH 2/5] media: i2c: vd55g1: Remove spurious pad format update on init_state()
From: Jacopo Mondi @ 2026-06-22 9:30 UTC (permalink / raw)
To: Benjamin Mugnier
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <20260428-vd55g4_and_fixes-v1-2-4f745a83b87e@foss.st.com>
Hi Benjamin
On Tue, Apr 28, 2026 at 10:40:56AM +0200, Benjamin Mugnier wrote:
> vd55g1_update_pad_fmt() is called in vd55g1_init_state(). But
> vd55g1_set_pad_fmt(), called at the end of vd55g1_init_state(), also
> calls vd55g1_update_pad_fmt() itself.
>
> Enhance readability and clear confusion by only preparing the format in
> vd55g1_init_state() and let vd55g1_set_pad_fmt() update it instead,
> effectively calling it only 1 time instead of 2.
>
> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
Does this qualify as a fix ?
I think you could maybe squash it with the previous one if you want
also this change to be backported as part of a larger fix
>
> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Thanks
j
> ---
> drivers/media/i2c/vd55g1.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index 1e9db21322e3..e44174056ace 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -1366,9 +1366,9 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
> code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
> else
> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
> - vd55g1_update_pad_fmt(sensor,
> - &vd55g1_supported_modes[VD55G1_MODE_IDX_DEF],
> - vd55g1_get_fmt_code(sensor, code), &fmt.format);
> + fmt.format.code = vd55g1_get_fmt_code(sensor, code);
> + fmt.format.width = vd55g1_supported_modes[VD55G1_MODE_IDX_DEF].width;
> + fmt.format.height = vd55g1_supported_modes[VD55G1_MODE_IDX_DEF].height;
>
> return vd55g1_set_pad_fmt(sd, sd_state, &fmt);
> }
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH 1/5] media: i2c: vd55g1: Fix media bus code initialization
From: Jacopo Mondi @ 2026-06-22 9:28 UTC (permalink / raw)
To: Benjamin Mugnier
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <20260428-vd55g4_and_fixes-v1-1-4f745a83b87e@foss.st.com>
Hi Benjamin
On Tue, Apr 28, 2026 at 10:40:55AM +0200, Benjamin Mugnier wrote:
> In the driver initialization, the index of the default media bus code
> from the supported media bus code array is passed directly to the
> vd55g1_get_fmt_code() function instead of the proper media bus code.
>
> This works correctly as a proper media bus code is set after
> initialization but could not have been the case. This also resulted in
> mutliple "Unsupported mbus format" error messages.
>
> Retrieve the media bus code from the media bus code array, and pass this
> media bus code to vd55g1_get_fmt_code() instead of the code index.
>
> Rename VD55G1_MBUS_CODE_DEF to VD55G1_MBUS_CODE_IDX_DEF and
> VD55G1_MODE_DEF to VD55G1_MODE_IDX_DEF while at it to avoid future
> confusions. Display the guilty error code in warning message.
>
> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
>
You should cc stable for fixes
Cc: stable@vger.kernel.org
The CI should have flagged that, but for some reason it didn't run
properly on your series
https://gitlab.freedesktop.org/linux-media/users/patchwork/-/pipelines/1655147
> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
> ---
> drivers/media/i2c/vd55g1.c | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index 78d18c028154..1e9db21322e3 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -114,9 +114,9 @@
>
> #define VD55G1_WIDTH 804
> #define VD55G1_HEIGHT 704
> -#define VD55G1_MODE_DEF 0
> +#define VD55G1_MODE_IDX_DEF 0
> #define VD55G1_NB_GPIOS 4
> -#define VD55G1_MBUS_CODE_DEF 0
> +#define VD55G1_MBUS_CODE_IDX_DEF 0
> #define VD55G1_DGAIN_DEF 256
> #define VD55G1_AGAIN_DEF 19
> #define VD55G1_EXPO_MAX_TERM 64
> @@ -634,7 +634,7 @@ static u32 vd55g1_get_fmt_code(struct vd55g1 *sensor, u32 code)
Unrelated, but it seems you now have 2 codes for MONO. Does
if (sensor->id == VD55G1_MODEL_ID_VD55G1)
return code;
need an update ?
> goto adapt_bayer_pattern;
> }
> }
> - dev_warn(sensor->dev, "Unsupported mbus format\n");
> + dev_warn(sensor->dev, "Unsupported mbus format: 0x%x\n", code);
>
> return code;
>
> @@ -1347,6 +1347,7 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
> {
> struct vd55g1 *sensor = to_vd55g1(sd);
> struct v4l2_subdev_format fmt = { 0 };
> + int code;
> struct v4l2_subdev_route routes[] = {
> { .flags = V4L2_SUBDEV_ROUTE_FL_ACTIVE }
> };
> @@ -1361,9 +1362,13 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
> if (ret)
> return ret;
>
> - vd55g1_update_pad_fmt(sensor, &vd55g1_supported_modes[VD55G1_MODE_DEF],
> - vd55g1_get_fmt_code(sensor, VD55G1_MBUS_CODE_DEF),
> - &fmt.format);
> + if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> + code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
> + else
> + code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
Being this a multi-dimensional array, I don't seem much value in
defining VD55G1_MBUS_CODE_IDX_DEF if this is the only place where it
is used. What's the meaning of VD55G1_MBUS_CODE_IDX_DEF for
vd55g1_mbus_formats_bayer ? Does it represent the bitwidth or does it
represent the bayer pattern ?
I would rather define a
VD55G1_DEF_MBUS_CODE_MONO MEDIA_BUS_FMT_Y8_1X8
VD55G1_DEF_MBUS_CODE_BAYER MEDIA_BUS_FMT_SRGGB8_1X8
Or maybe do
code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF]
[VD55G1_MBUS_CODE_IDX_DEF];
if easier.
I understand it's a minor, so up to you.
> + vd55g1_update_pad_fmt(sensor,
> + &vd55g1_supported_modes[VD55G1_MODE_IDX_DEF],
> + vd55g1_get_fmt_code(sensor, code), &fmt.format);
>
> return vd55g1_set_pad_fmt(sd, sd_state, &fmt);
> }
>
> --
> 2.43.0
>
>
^ 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