* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Conor Dooley @ 2026-06-15 16:50 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260612200717.361018-2-l.scorcia@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
On Fri, Jun 12, 2026 at 10:04:06PM +0200, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the initial bindings for the MT6392 PMIC and its RTC device.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Sashiko complaint about missing regulators looks valid.
Is it?
Cheers,
Conor.
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 3cbc0dc12c31..e39e81aa9924 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -40,6 +40,10 @@ properties:
> - mediatek,mt6358
> - mediatek,mt6359
> - mediatek,mt6397
> + - items:
> + - enum:
> + - mediatek,mt6392
> + - const: mediatek,mt6323
> - items:
> - enum:
> - mediatek,mt6366
> @@ -72,6 +76,10 @@ properties:
> - mediatek,mt6331-rtc
> - mediatek,mt6358-rtc
> - mediatek,mt6397-rtc
> + - items:
> + - enum:
> + - mediatek,mt6392-rtc
> + - const: mediatek,mt6323-rtc
> - items:
> - enum:
> - mediatek,mt6359-rtc
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v4 6/9] dt-bindings: npu: rockchip,rk3588-rknn-core: Add RK3568
From: Conor Dooley @ 2026-06-15 16:49 UTC (permalink / raw)
To: MidG971
Cc: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson,
dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik,
jonas
In-Reply-To: <20260613070116.438906-7-midgy971@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Andrew Lunn @ 2026-06-15 16:48 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <ai93X/cNWHtEQsDt@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 09:24:07AM +0530, Mohd Ayaan Anwar wrote:
> Hello Andrew,
> On Thu, Jun 11, 2026 at 10:54:37PM +0200, Andrew Lunn wrote:
> > On Fri, Jun 12, 2026 at 12:06:59AM +0530, Mohd Ayaan Anwar wrote:
> > > When "rgmii-id" is selected the PHY supplies both TX and RX delays, so
> > > the MAC must not add its own. The driver currently falls through to the
> > > generic DLL initialisation path which programs it to add a delay.
> > >
> > > Power down the DLL and set DDR bypass mode for RGMII_ID, then program
> > > the IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. Also fix
> > > ethqos_set_clk_tx_rate() to not double the clock rate in bypass mode at
> > > 100M/10M, and remove RGMII_ID from the phase-shift suppression in
> > > ethqos_rgmii_macro_init() since RGMII_ID no longer reaches that path.
> >
> > I'm curious how this works at the moment? Do no boards make use of
> > RGMII ID? Are all current boards broken?
>
> Searching through the DTS, I found that we have two boards using "rgmii"
> (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
> "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
So this causes problems. We cannot break existing boards, yet it would
be good to fix the current broken behaviour.
> I don't think any of these boards have extra long wires which would add
> PCB level delay. They are against the netdev definitions for "rgmii" and
> "rgmii-txid".
>
> But the first two boards should still be working fine since the current
> driver programs the IO_MACRO to add the delay when operating in RGMII
> mode.
Which is wrong, given the current definition. No delays should be
added, by either the MAC or the PHY.
Please could you contact the Maintainers of these boards and find out
the real situation with the hardware.
It could be the best way forward is that you issue a warning when
"rgmii" is found and pass rgmii-id to the PHY. And you also change the
two boards to use rgmii-id. Lets think about the rgmii-txid case once
we better understand it.
Andrew
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: qcom: sm8650: fix soundwire ports properties
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Krzysztof Kozlowski
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org>
Since commit 9e53a66a2f2f ("soundwire: qcom: deprecate qcom,din/out-ports"),
the ports are checked against the actul hardware configuration, leading to:
qcom-soundwire 6ad0000.soundwire: din-ports (0) mismatch with controller (1)
qcom-soundwire 6d30000.soundwire: dout-ports (0) mismatch with controller (1)
Fix the ports count and properties of the corresponding soundwire
controllers.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 42 ++++++++++++++++++------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 090a4739ebc1..b1293fdb1481 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -4734,18 +4734,18 @@ swr1: soundwire@6ad0000 {
pinctrl-0 = <&rx_swr_active>;
pinctrl-names = "default";
- qcom,din-ports = <0>;
+ qcom,din-ports = <1>;
qcom,dout-ports = <11>;
- qcom,ports-sinterval = /bits/ 16 <0x03 0x1f 0x1f 0x07 0x03 0xff 0xff 0x31 0xff 0xff 0xff>;
- qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x09 0x01 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff 0xff 0xff 0x0f 0xff 0xff 0xff>;
- qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff 0xff 0xff 0x18 0xff 0xff 0xff>;
- qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff 0xff 0xff 0x01 0xff 0xff 0xff>;
- qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0x01 0x03 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00 0xff 0xff 0x01 0xff 0xff 0xff>;
+ qcom,ports-sinterval = /bits/ 16 <0x03 0x1f 0x1f 0x07 0x03 0xff 0xff 0x31 0xff 0xff 0xff 0xff>;
+ qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x09 0x01 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff 0xff 0xff 0x0f 0xff 0xff 0xff 0xff>;
+ qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff 0xff 0xff 0x18 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff 0xff 0xff 0x01 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0x01 0x03 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00 0xff 0xff 0x01 0xff 0xff 0xff 0xff>;
#address-cells = <2>;
#size-cells = <0>;
@@ -4831,17 +4831,17 @@ swr2: soundwire@6d30000 {
pinctrl-names = "default";
qcom,din-ports = <4>;
- qcom,dout-ports = <0>;
-
- qcom,ports-sinterval-low = /bits/ 8 <0x01 0x01 0x03 0x03>;
- qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x01 0x01>;
- qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x00 0x00>;
- qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-lane-control = /bits/ 8 <0x01 0x02 0x00 0x00>;
+ qcom,dout-ports = <1>;
+
+ qcom,ports-sinterval-low = /bits/ 8 <0x00 0x01 0x01 0x03 0x03>;
+ qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x00 0x01 0x01>;
+ qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x00 0x00 0x00>;
+ qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-lane-control = /bits/ 8 <0xff 0x01 0x02 0x00 0x00>;
#address-cells = <2>;
#size-cells = <0>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: qcom: sm8650: add CPU cache size properties
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Konrad Dybcio
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org>
Add the L1 cache size and its line size (cache-size and
cache-line-size) with the corresponding L1-I cache and L1-D cache.
L1 cache is unified, but clidr_el1 register (get_cache_type) tells that
L1 cache is separated (CACHE_TYPE_SEPARATE), add i-cache-line-size and
d-cache-line-size and cache-line-size of L3 cache is specified.
All cache line sizes were confirmed by checking ccsidr_el1.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 56 ++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index e8e43ddc3032..090a4739ebc1 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -75,6 +75,11 @@ cpu0: cpu@0 {
compatible = "arm,cortex-a520";
reg = <0 0>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 0>;
power-domains = <&cpu_pd0>;
@@ -103,11 +108,15 @@ l2_0: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
l3_0: l3-cache {
compatible = "cache";
cache-level = <3>;
cache-unified;
+ cache-size = <12582912>;
+ cache-line-size = <64>;
};
};
};
@@ -117,6 +126,11 @@ cpu1: cpu@100 {
compatible = "arm,cortex-a520";
reg = <0 0x100>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 0>;
power-domains = <&cpu_pd1>;
@@ -146,6 +160,11 @@ cpu2: cpu@200 {
compatible = "arm,cortex-a720";
reg = <0 0x200>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 3>;
power-domains = <&cpu_pd2>;
@@ -174,6 +193,8 @@ l2_200: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -182,6 +203,11 @@ cpu3: cpu@300 {
compatible = "arm,cortex-a720";
reg = <0 0x300>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 3>;
power-domains = <&cpu_pd3>;
@@ -210,6 +236,8 @@ l2_300: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -218,6 +246,11 @@ cpu4: cpu@400 {
compatible = "arm,cortex-a720";
reg = <0 0x400>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 3>;
power-domains = <&cpu_pd4>;
@@ -246,6 +279,8 @@ l2_400: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -254,6 +289,11 @@ cpu5: cpu@500 {
compatible = "arm,cortex-a720";
reg = <0 0x500>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 1>;
power-domains = <&cpu_pd5>;
@@ -282,6 +322,8 @@ l2_500: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -290,6 +332,11 @@ cpu6: cpu@600 {
compatible = "arm,cortex-a720";
reg = <0 0x600>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 1>;
power-domains = <&cpu_pd6>;
@@ -318,6 +365,8 @@ l2_600: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -326,6 +375,11 @@ cpu7: cpu@700 {
compatible = "arm,cortex-x4";
reg = <0 0x700>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 2>;
power-domains = <&cpu_pd7>;
@@ -354,6 +408,8 @@ l2_700: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <2097152>;
+ cache-line-size = <64>;
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/3] arm64: dts: qcom: sm8650: update the cpus capacity-dmips-mhz
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Konrad Dybcio
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org>
After some more advanced benchmarks with Integer, Floaring Point,
Encryption, Compression, NEON, ... on the A520, A720 and X4 cpus,
the median gain with the same frequency range is:
- 281% of A720 over A520
- 126% of X4 over A720
When adjusted with the frequency delta, we get better values
describing the difference in capacity, showing the weakness of
the A520 designed for very small tasks while the A720 and X4
are much more powerful.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 160ead25ecf7..e8e43ddc3032 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -153,7 +153,7 @@ cpu2: cpu@200 {
enable-method = "psci";
next-level-cache = <&l2_200>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 3>;
@@ -189,7 +189,7 @@ cpu3: cpu@300 {
enable-method = "psci";
next-level-cache = <&l2_300>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 3>;
@@ -225,7 +225,7 @@ cpu4: cpu@400 {
enable-method = "psci";
next-level-cache = <&l2_400>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 3>;
@@ -261,7 +261,7 @@ cpu5: cpu@500 {
enable-method = "psci";
next-level-cache = <&l2_500>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 1>;
@@ -297,7 +297,7 @@ cpu6: cpu@600 {
enable-method = "psci";
next-level-cache = <&l2_600>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 1>;
@@ -333,7 +333,7 @@ cpu7: cpu@700 {
enable-method = "psci";
next-level-cache = <&l2_700>;
- capacity-dmips-mhz = <1894>;
+ capacity-dmips-mhz = <3591>;
dynamic-power-coefficient = <588>;
qcom,freq-domain = <&cpufreq_hw 2>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/3] arm64: qcom: sm8650: misc enhancements
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Konrad Dybcio, Krzysztof Kozlowski
Misc enhancements for the SM8650 platform:
- update the cpus capacity-dmips-mhz
- add the CPU cache sizes
- correct the soundwire ports
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v3:
- Picked tags
- Rebased on next
- Link to v2: https://patch.msgid.link/20260420-topic-sm8650-upstream-cpu-props-v2-0-689e07d8ab8c@linaro.org
Changes in v2:
- Add review tag
- Fix l2 cache size to 512KiB
- Link to v1: https://patch.msgid.link/20260128-topic-sm8650-upstream-cpu-props-v1-0-9fbb5efe7f07@linaro.org
---
Neil Armstrong (3):
arm64: dts: qcom: sm8650: update the cpus capacity-dmips-mhz
arm64: dts: qcom: sm8650: add CPU cache size properties
arm64: dts: qcom: sm8650: fix soundwire ports properties
arch/arm64/boot/dts/qcom/sm8650.dtsi | 110 ++++++++++++++++++++++++++---------
1 file changed, 83 insertions(+), 27 deletions(-)
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260128-topic-sm8650-upstream-cpu-props-0754ccef3e01
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [RFC PATCH v4 6/9] dt-bindings: npu: rockchip,rk3588-rknn-core: Add RK3568
From: Conor Dooley @ 2026-06-15 16:48 UTC (permalink / raw)
To: sashiko-reviews; +Cc: MidG971, conor+dt, robh, devicetree, dri-devel
In-Reply-To: <20260613071113.C60751F00A3D@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 6723 bytes --]
On Sat, Jun 13, 2026 at 07:11:13AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] Double free of `rjob->tasks` leading to memory corruption triggerable from userspace.
> - [Critical] Unconditional dereference of a NULL `job->domain` triggering a kernel panic on early job submission failure.
> - [High] Permanent PM runtime reference count leak when `iommu_attach_group()` fails.
> - [High] Zero-initialized clock IDs cause the framework to fetch the same clock repeatedly, violating hardware constraints.
> - [Medium] Premature DRM device registration exposes an incomplete state to userspace.
Why is the bot complaining about drivers here?
> --
>
> commit d0d76b931ac773e3e176353cdb3ac9c590c43dc3
> Author: Midgy BALON <midgy971@gmail.com>
>
> dt-bindings: npu: rockchip, rk3588-rknn-core: Add RK3568
>
> The RK3568 carries a single core of the same NVDLA-derived NPU IP as the
> RK3588. Add its compatible.
>
> > diff --git a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
> > index caca2a4903cd1..e0b948ac47d45 100644
> > --- a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
> > +++ b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
> [ ... ]
>
> drivers/accel/rocket/rocket_device.c:rocket_device_init() {
> ...
> err = drm_dev_register(ddev, 0);
> ...
> }
>
> drivers/accel/rocket/rocket_drv.c:rocket_probe() {
> ...
> rdev->cores[core].dev = &pdev->dev;
> ...
> }
>
> [Severity: Medium]
> This is a pre-existing issue, but does this premature registration expose an
> incomplete state to userspace?
>
> drm_dev_register() is called in rocket_device_init() before rocket_probe()
> assigns rdev->cores[0].dev.
>
> As a result, the device node is briefly visible to userspace while its core
> structures remain partially uninitialized.
>
> If userspace attempts to open the DRM device during this window, rocket_open()
> passes the NULL rdev->cores[0].dev to rocket_iommu_domain_create().
>
> While the IOMMU framework safely catches the NULL device and returns -ENODEV,
> this still causes a spurious open() failure for userspace applications relying
> on udev events.
>
>
> drivers/accel/rocket/rocket_job.c:rocket_job_run() {
> ...
> ret = pm_runtime_get_sync(core->dev);
> if (ret < 0)
> return fence;
> ...
> ret = iommu_attach_group(job->domain->domain, core->iommu_group);
> if (ret < 0)
> return fence;
> ...
> }
>
> [Severity: High]
> This is a pre-existing issue, but does this cause a permanent PM runtime
> reference count leak when iommu_attach_group() fails?
>
> In rocket_job_run(), pm_runtime_get_sync() increments the PM usage count to wake
> up the NPU.
>
> If the subsequent iommu_attach_group() fails, the driver returns the allocated
> fence and exits early without calling pm_runtime_put().
>
> Because the driver exits before assigning core->in_flight_job, the subsequent
> timeout handler rocket_reset() will also skip the manual
> pm_runtime_put_noidle().
>
> This causes a permanent PM runtime reference count leak, preventing the NPU
> hardware from ever entering runtime suspend.
>
>
> drivers/accel/rocket/rocket_core.c:rocket_core_init() {
> ...
> err = devm_clk_bulk_get(dev, ARRAY_SIZE(core->clks), core->clks);
> ...
> }
>
> [Severity: High]
> This is a pre-existing issue, but do these zero-initialized clock IDs cause the
> framework to fetch the same clock repeatedly?
>
> In rocket_core_init(), the driver declares an array of clk_bulk_data but never
> initializes the .id fields, leaving them implicitly NULL.
>
> When devm_clk_bulk_get() is called, the clock framework handles the NULL IDs by
> returning the first clock defined in the device tree for the device on all four
> iterations.
>
> Consequently, rocket_device_runtime_resume() enables the exact same clock four
> times, while the remaining required clocks are left disabled.
>
> This violates physical hardware state requirements and causes unclocked NPU
> register accesses.
>
>
> drivers/accel/rocket/rocket_job.c:rocket_copy_tasks() {
> ...
> fail:
> kvfree(rjob->tasks);
> return ret;
> }
>
> drivers/accel/rocket/rocket_job.c:rocket_job_cleanup() {
> ...
> kvfree(job->tasks);
> ...
> }
>
> [Severity: Critical]
> This is a pre-existing issue, but does this lead to a double free of rjob->tasks
> that can be triggered from userspace?
>
> In rocket_copy_tasks(), if copy_from_user() fails, kvfree(rjob->tasks) is
> called, but the pointer rjob->tasks is not cleared.
>
> The function returns an error to rocket_ioctl_submit_job(), which jumps to
> out_cleanup_job and invokes rocket_job_put().
>
> When the reference count drops, rocket_job_cleanup() is executed,
> unconditionally calling kvfree(job->tasks) again on the already freed memory
> block.
>
> Since the IOCTL input is fully controlled by userspace, an unprivileged attacker
> can trigger a double free by submitting an invalid task pointer.
>
>
> drivers/accel/rocket/rocket_job.c:rocket_ioctl_submit_job() {
> ...
> rjob = kzalloc_obj(*rjob);
> ...
> ret = rocket_copy_tasks(dev, file, job, rjob);
> if (ret)
> goto out_cleanup_job;
> ...
> }
>
> drivers/accel/rocket/rocket_drv.c:rocket_iommu_domain_put() {
> ...
> kref_put(&domain->kref, rocket_iommu_domain_destroy);
> ...
> }
>
> [Severity: Critical]
> This is a pre-existing issue, but does this unconditionally dereference a NULL
> job->domain, triggering a kernel panic on early job submission failure?
>
> In rocket_ioctl_submit_job(), rjob is allocated via kzalloc_obj(), leaving
> rjob->domain initialized to NULL.
>
> If a failure occurs before the domain is assigned, such as an invalid task
> pointer in rocket_copy_tasks() or a bad BO handle in drm_gem_objects_lookup(),
> the driver jumps to the cleanup path.
>
> The cleanup handler, rocket_job_cleanup(), unconditionally passes the NULL
> domain to rocket_iommu_domain_put(), which invokes kref_put(&domain->kref, ...).
>
> Computing &domain->kref yields an offset address, and refcount_dec_and_test()
> immediately dereferences this invalid address, resulting in a kernel panic that
> can be triggered by unprivileged userspace.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260613070116.438906-1-midgy971@gmail.com?part=6
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: Add header file for ADC5 Gen3 channel macros
From: Konrad Dybcio @ 2026-06-15 16:48 UTC (permalink / raw)
To: Neil Armstrong, Jishnu Prakash, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ayyagari Ushasreevalli,
Kamal Wadhwa
In-Reply-To: <831ed020-4a1f-46af-95c6-38ef1f875fd1@linaro.org>
On 6/15/26 6:39 PM, Neil Armstrong wrote:
> Hi,
>
> On 6/15/26 17:55, Konrad Dybcio wrote:
>> On 4/30/26 10:58 AM, Jishnu Prakash wrote:
>>> Add macro definitions for virtual channels (combination of ADC channel
>>> number and PMIC SID number), to be used in devicetree by clients of ADC5
>>> GEN3 device and in the "reg" property of ADC channels.
>>>
>>> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
>>> ---
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> And what happens with my patch [1] ?
>
> I had zero feedback so far
>
> [1] https://lore.kernel.org/all/20260504-topic-sm8x50-adc5-gen3-v2-1-5cc04d6ecda0@linaro.org/
I think this approach (single generic header) is better. The existing
ADC7 bindings which your series draws inspiration from come with a ton
of boilerplate.
There are some non-trivial mappings in there though, e.g.:
+#define PM8550B_ADC5_GEN3_AMUX4_GPIO12_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_100K_PU)
but these would presumably be deducible from downstream
Konrad
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: clock: clocking-wizard: Make s_axi_aclk optional for static-config
From: Conor Dooley @ 2026-06-15 16:44 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-clk, linux-kernel, git, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Michal Simek,
devicetree, linux-arm-kernel
In-Reply-To: <20260615-squid-showy-435c9cf780a0@spud>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
On Mon, Jun 15, 2026 at 05:42:17PM +0100, Conor Dooley wrote:
>
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: not-applicable
Actually, I take this back. Patch 1 seems to be what's adding the static
configurations in the first place and then patches 2 and 3 complete that
effort. Instead, please add this static config support as one patch.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: clock: clocking-wizard: Make s_axi_aclk optional for static-config
From: Conor Dooley @ 2026-06-15 16:42 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-clk, linux-kernel, git, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Michal Simek,
devicetree, linux-arm-kernel
In-Reply-To: <20260615034845.3320286-4-shubhrajyoti.datta@amd.com>
[-- Attachment #1: Type: text/plain, Size: 77 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add ITE IT885x support
From: Conor Dooley @ 2026-06-15 16:41 UTC (permalink / raw)
To: Amber Kao
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeson Yang, Yaode Fang, Bling Chiang, Eric Su,
Doreen Lin, Heikki Krogerus, linux-usb, devicetree, linux-kernel
In-Reply-To: <20260615-ucsi-itepd-feature-v1-1-a826cfd0df6a@ite.com.tw>
[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]
On Mon, Jun 15, 2026 at 09:47:39PM +0800, Amber Kao wrote:
> Add device tree binding documentation for the ITE IT885x.
> The ITE IT885x is an I2C-based USB Type-C Power Delivery (PD) controller.
>
> Cc: Yaode Fang <Yaode.Fang@ite.com.tw>
> Cc: Jeson Yang <jeson.yang@ite.com.tw>
> Cc: Bling Chiang <Bling.Chiang@ite.com.tw>
> Cc: Eric Su <Eric.Su@ite.com.tw>
> Cc: Doreen Lin <doreen.lin@ite.com.tw>
> Signed-off-by: Amber Kao <amber.kao@ite.com.tw>
> ---
> .../devicetree/bindings/usb/ite,itepd-it885x.yaml | 109 +++++++++++++++++++++
> MAINTAINERS | 11 +++
> 2 files changed, 120 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/ite,itepd-it885x.yaml b/Documentation/devicetree/bindings/usb/ite,itepd-it885x.yaml
> new file mode 100644
> index 000000000000..59e4eaa32ff1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ite,itepd-it885x.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/ite,itepd-it885x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ITE IT885x USB Type-C Power Delivery Controller
> +
> +maintainers:
> + - Jeson Yang <jeson.yang@ite.com.tw>
> +
> +description:
> + The ITE IT885x is an I2C-based USB Type-C Power Delivery (PD) controller.
> +
> +properties:
> + compatible:
> + const: ite,itepd-it885x
> +
> + reg:
> + maxItems: 1
> +
> + gpios:
> + maxItems: 1
Sashiko comments on this and on
> +
> + interrupts:
> + maxItems: 1
> +
> + wakeup-source: true
> +
> + pinctrl-names:
> + minItems: 1
> +
> + pinctrl-0: true
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + "^connector(@[0-9a-f]+)?$":
> + $ref: /schemas/connector/usb-connector.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + itepd@40 {
(usb-pd here as the node name please)
> + compatible = "ite,itepd-it885x";
> + reg = <0x40>;
> + gpios = <&tlmm 129 GPIO_ACTIVE_LOW>;
> + interrupts-extended = <&tlmm 129 IRQ_TYPE_EDGE_FALLING>;
This double use seem valid. Either this is a gpio or an interrupt, it's
not both.
pw-bot: changes-requested
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v10 4/6] clk: Add KUnit tests for assigned-clock-sscs
From: Brian Masney @ 2026-06-15 16:40 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sudeep Holla, Cristian Marussi, Sebin Francis,
linux-kernel, linux-clk, devicetree, arm-scmi, linux-arm-kernel,
Peng Fan
In-Reply-To: <20260612-clk-v10-v10-4-eb92484eda38@nxp.com>
On Fri, Jun 12, 2026 at 04:46:26PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add KUnit test coverage for the assigned-clock-sscs DT property that
> configures spread spectrum on clocks before they are used.
>
> Extend the existing test infrastructure to support spread spectrum:
> - Add struct clk_spread_spectrum field to clk_dummy_context and a
> clk_dummy_set_spread_spectrum callback
> - Wire set_spread_spectrum into all dummy clock ops
> - Extend clk_assigned_rates_register_clk and test parameter struct
> to propagate initial SSCS values
>
> Add a new separate test suite clk_assigned_sscs with three categories:
>
> 1. clk_assigned_sscs_assigns_one — verifies that a single
> assigned-clock-sscs entry correctly configures spread spectrum
> on one clock, testing both provider and consumer paths
>
> 2. clk_assigned_sscs_assigns_multiple — verifies that multiple
> assigned-clock-sscs entries configure spread spectrum on two
> clocks, testing both provider and consumer paths
>
> 3. clk_assigned_sscs_skips — verifies that malformed DT properties
> are correctly skipped without error: missing assigned-clocks,
> zero-valued SSCS, and null phandles, tested for both provider
> and consumer scenarios
>
> New DT overlays are added for all test scenarios:
> - kunit_clk_assigned_sscs_one{,consumer} — single valid entry
> - kunit_clk_assigned_sscs_multiple{,consumer} — two valid entries
> - kunit_clk_assigned_sscs_without{,consumer} — missing assigned-clocks
> - kunit_clk_assigned_sscs_zero{,consumer} — all-zero SSCS values
> - kunit_clk_assigned_sscs_null{,consumer} — null phandle
>
> Co-developed-by: Brian Masney <bmasney@redhat.com>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Looks good to me.
It's probably not appropriate for me to also put a Reviewed-by here.
Brian
^ permalink raw reply
* Re: [PATCH V12 7/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Chris Morgan @ 2026-06-15 16:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner, jic23,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh
In-Reply-To: <ajAVI0KXkx3FM1ZX@ashevche-desk.local>
On Mon, Jun 15, 2026 at 06:07:15PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 09:51:40AM -0500, Chris Morgan wrote:
> > On Mon, Jun 15, 2026 at 02:21:05PM +0300, Andy Shevchenko wrote:
> > > On Thu, Jun 11, 2026 at 03:26:04PM -0500, Chris Morgan wrote:
>
> ...
>
> > > Please, please, use IWYU! So many headers are missing...
> > > (Same comment to all files in this series.)
> > >
> > > + array_size.h
> > > + bits.h // BIT()
> > > + cleanup.h // guard()()
> > > + device/devres.h // devm_kasprintf()
> > > + err.h // -EINVAL, IS_ERR()
> > >
> > > > +#include <linux/iio/iio.h>
> > > > +#include <linux/mutex.h>
> > > > +#include <linux/pm_runtime.h>
> > > > +#include <linux/regmap.h>
> > >
> > > + types.h // s16, __be16
> > >
> > > Also you need to have
> > >
> > > asm/byteorder.h // be16_to_cpup()
> >
> > How are you running IWYU against the builds? So far I've tried but I
> > can't seem to get it to run properly.
>
> Sorry, I meant "use IWYU principle". I don't run the tool, I just looked into
> the code.
I've done what I can then, I have added these headers where I am using
them. I'm not going to add asm/byteorder.h though because I am dropping
that in the next revision and replacing it with get_unaligned_be16() to
further simplify things. Note that I am adding linux/unaligned.h for
the files where I use that function.
The additional headers will be added in the next revision. If you see
any other obvious ones missing let me know but for now I *think* it's
correct.
>
> ...
>
> > > > + for (i = 5; i < ARRAY_SIZE(inv_icm42607_accel_odr); ++i) {
> > >
> > > Why pre-increment? Same for all other cases.
> >
> > The register starts at 5 and all values below 5 are invalid. Starting
> > this increment at 5 ensures we don't expose invalid values to
> > userspace.
>
> It doesn't explain pre-increment. Post-increment should work as is.
The array this references starts at 5, because those correspond to the
values written to the odr register. That said, I do see a bug because
the odr register is from highest to smallest and this array is
backwards in the accel and gyro code. I'll fix that.
>
> > > > + if (i == odr)
> > > > + break;
> > > > + }
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: Add header file for ADC5 Gen3 channel macros
From: Neil Armstrong @ 2026-06-15 16:39 UTC (permalink / raw)
To: Konrad Dybcio, Jishnu Prakash, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ayyagari Ushasreevalli,
Kamal Wadhwa
In-Reply-To: <60170148-2fef-4282-ad68-f784e4fdfe23@oss.qualcomm.com>
Hi,
On 6/15/26 17:55, Konrad Dybcio wrote:
> On 4/30/26 10:58 AM, Jishnu Prakash wrote:
>> Add macro definitions for virtual channels (combination of ADC channel
>> number and PMIC SID number), to be used in devicetree by clients of ADC5
>> GEN3 device and in the "reg" property of ADC channels.
>>
>> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
>> ---
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
And what happens with my patch [1] ?
I had zero feedback so far
[1] https://lore.kernel.org/all/20260504-topic-sm8x50-adc5-gen3-v2-1-5cc04d6ecda0@linaro.org/
>
> Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Conor Dooley @ 2026-06-15 16:36 UTC (permalink / raw)
To: Potin Lai
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss, linux-hwmon, devicetree, linux-kernel, Cosmo Chou,
Mike Hsieh, Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v3-1-decb4f5b0b77@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 6/7] riscv: dts: eswin: add I2C controller support
From: Conor Dooley @ 2026-06-15 16:35 UTC (permalink / raw)
To: Pinkesh Vaghela
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
devicetree, linux-kernel, linux-riscv, Min Lin, Yulin Lu,
Samuel Holland, Darshan Prajapati, Pritesh Patel
In-Reply-To: <20260615122016.1110206-7-pinkesh.vaghela@einfochips.com>
[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]
On Mon, Jun 15, 2026 at 05:50:15PM +0530, Pinkesh Vaghela wrote:
> From: Pritesh Patel <pritesh.patel@einfochips.com>
>
> Add I2C nodes for EIC7700 SoC.
> Also add nodes for corresponding slave devices in dts file and
> enable them for HiFive Premier P550 board
>
> Signed-off-by: Pritesh Patel <pritesh.patel@einfochips.com>
> Signed-off-by: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
> ---
> .../dts/eswin/eic7700-hifive-premier-p550.dts | 52 ++++++
> arch/riscv/boot/dts/eswin/eic7700.dtsi | 156 ++++++++++++++++++
> 2 files changed, 208 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> index e7bb96e14958..0f0c98474c62 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> +++ b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> @@ -130,6 +130,58 @@ &gpio111_pins {
> input-disable;
> };
>
> +&aon_i2c0 {
> + status = "okay";
> +
> + eeprom@50 {
> + compatible = "atmel,24c02";
> + reg = <0x50>;
> + };
> +};
> +
> +&aon_i2c1 {
> + status = "okay";
> +
> + pac1934@10 {
Generic node name here please. adc I think.
> + compatible = "microchip,pac1934";
> + reg = <0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@1 {
> + reg = <0x1>;
> + shunt-resistor-micro-ohms = <1000>;
> + label = "VDD_SOM";
> + };
> +
> + channel@2 {
> + reg = <0x2>;
> + shunt-resistor-micro-ohms = <1000>;
> + label = "VDD_SOC";
> + };
> +
> + channel@3 {
> + reg = <0x3>;
> + shunt-resistor-micro-ohms = <1000>;
> + label = "VDD_CPU";
> + };
> +
> + channel@4 {
> + reg = <0x4>;
> + shunt-resistor-micro-ohms = <1000>;
> + label = "VDD_LPDDR";
> + };
> + };
> +
> + ina226@44 {
And here. power-sensor.
> + compatible = "ti,ina226";
> + reg = <0x44>;
> + #io-channel-cells = <1>;
> + label = "sys_power";
> + shunt-resistor = <1000>;
> + };
> +};
> +
> &pinctrl {
> vrgmii-supply = <&vcc_1v8>;
> };
> diff --git a/arch/riscv/boot/dts/eswin/eic7700.dtsi b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> index f8caf39616b2..28706431b2c0 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> +++ b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> @@ -315,6 +315,162 @@ uart4: serial@50940000 {
> status = "disabled";
> };
>
> + i2c0: i2c@50950000 {
> + compatible = "snps,designware-i2c";
Missing a soc-specific compatible here for all i2c controllers.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7] riscv: dts: eswin: eic7700: add pinctrl support
From: Conor Dooley @ 2026-06-15 16:33 UTC (permalink / raw)
To: Pinkesh Vaghela
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
devicetree, linux-kernel, linux-riscv, Min Lin, Yulin Lu,
Samuel Holland, Darshan Prajapati, Pritesh Patel
In-Reply-To: <20260615122016.1110206-4-pinkesh.vaghela@einfochips.com>
[-- Attachment #1: Type: text/plain, Size: 4275 bytes --]
On Mon, Jun 15, 2026 at 05:50:12PM +0530, Pinkesh Vaghela wrote:
> From: Yulin Lu <luyulin@eswincomputing.com>
>
> Add pinctrl node and related pin configuration for EIC7700 SoC
>
> Co-developed-by: Pritesh Patel <pritesh.patel@einfochips.com>
> Signed-off-by: Pritesh Patel <pritesh.patel@einfochips.com>
> Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
> Signed-off-by: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
> ---
> .../dts/eswin/eic7700-hifive-premier-p550.dts | 109 +++
> .../riscv/boot/dts/eswin/eic7700-pinctrl.dtsi | 888 ++++++++++++++++++
> arch/riscv/boot/dts/eswin/eic7700.dtsi | 5 +
> 3 files changed, 1002 insertions(+)
> create mode 100644 arch/riscv/boot/dts/eswin/eic7700-pinctrl.dtsi
>
> diff --git a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> index 1fb92f0e7c55..e7bb96e14958 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> +++ b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> @@ -6,6 +6,7 @@
> /dts-v1/;
>
> #include "eic7700.dtsi"
> +#include "eic7700-pinctrl.dtsi"
>
> / {
> compatible = "sifive,hifive-premier-p550", "eswin,eic7700";
> @@ -18,6 +19,15 @@ aliases {
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + vcc_1v8: vcc1v8 {
Same here.
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> };
>
> &xtal {
> @@ -25,6 +35,105 @@ &xtal {
> clock-output-names = "xtal24m";
> };
>
> +&gpio0_pins {
> + bias-disable;
> + input-enable;
> +};
> +
> +&gpio5_pins {
> + bias-disable;
> + input-enable;
> +};
> +
> +&gpio11_pins {
> + bias-disable;
> + input-enable;
> +};
> +
> +&gpio14_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio15_pins {
> + bias-disable;
> + input-enable;
> +};
> +
> +&gpio28_pins {
> + bias-disable;
> + input-enable;
> +};
> +
> +&gpio43_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&gpio71_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio74_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio76_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&gpio77_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio79_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&gpio80_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio82_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio84_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&gpio85_pins {
> + bias-pull-up;
> + input-disable;
> +};
> +
> +&gpio94_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&gpio106_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&gpio111_pins {
> + bias-disable;
> + input-disable;
> +};
> +
> +&pinctrl {
> + vrgmii-supply = <&vcc_1v8>;
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/riscv/boot/dts/eswin/eic7700-pinctrl.dtsi b/arch/riscv/boot/dts/eswin/eic7700-pinctrl.dtsi
> new file mode 100644
> index 000000000000..7293df146aa7
> --- /dev/null
> +++ b/arch/riscv/boot/dts/eswin/eic7700-pinctrl.dtsi
> @@ -0,0 +1,888 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2025 Beijing ESWIN Computing Technology Co., Ltd.
> + *
> + * ESWIN's EIC7700 SoC pin-mux and pin-config options are listed as
> + * device tree nodes in this file.
> + *
> + * Authors: Yulin Lu <luyulin@eswincomputing.com>
> + */
> +
I don't really understand the groups here. I think you should make more
effort to put more pins in each group.
> + gpio1_pins: gpio1-pins {
> + pins = "jtag0_tck";
> + function = "gpio";
> + };
> +
> + gpio2_pins: gpio2-pins {
> + pins = "jtag0_tms";
> + function = "gpio";
> + };
> +
> + gpio3_pins: gpio3-pins {
> + pins = "jtag0_tdi";
> + function = "gpio";
> + };
> +
> + gpio4_pins: gpio4-pins {
> + pins = "jtag0_tdo";
> + function = "gpio";
> + };
Like these 4 for example, why not group these?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v19 3/3] pwm: Add OpenCores PTC PWM driver
From: Hal Feng @ 2026-06-15 15:57 UTC (permalink / raw)
To: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Emil Renner Berthing,
Palmer Dabbelt, Paul Walmsley, Albert Ou
Cc: Hal Feng, linux-pwm, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260615155759.129210-1-hal.feng@starfivetech.com>
Add PWM driver for OpenCores PTC IP core.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
---
MAINTAINERS | 6 +
drivers/pwm/Kconfig | 12 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-ocores.c | 312 +++++++++++++++++++++++++++++++++++++++
4 files changed, 331 insertions(+)
create mode 100644 drivers/pwm/pwm-ocores.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d94420eae3d..b6a004f2e6c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20035,6 +20035,12 @@ F: Documentation/i2c/busses/i2c-ocores.rst
F: drivers/i2c/busses/i2c-ocores.c
F: include/linux/platform_data/i2c-ocores.h
+OPENCORES PWM DRIVER
+M: Hal Feng <hal.feng@starfivetech.com>
+S: Supported
+F: Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
+F: drivers/pwm/pwm-ocores.c
+
OPENRISC ARCHITECTURE
M: Jonas Bonn <jonas@southpole.se>
M: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6f3147518376..dd7f3bf5c3eb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -534,6 +534,18 @@ config PWM_NTXEC
controller found in certain e-book readers designed by the original
design manufacturer Netronix.
+config PWM_OCORES
+ tristate "OpenCores PTC PWM support"
+ depends on HAS_IOMEM && OF
+ depends on COMMON_CLK
+ depends on ARCH_STARFIVE || COMPILE_TEST
+ help
+ PWM driver for OpenCores PTC IP core.
+ For details see https://opencores.org/projects/ptc.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-ocores.
+
config PWM_OMAP_DMTIMER
tristate "OMAP Dual-Mode Timer PWM support"
depends on OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0dc0d2b69025..2d47bad7bd74 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_PWM_MICROCHIP_CORE) += pwm-microchip-core.o
obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
obj-$(CONFIG_PWM_NTXEC) += pwm-ntxec.o
+obj-$(CONFIG_PWM_OCORES) += pwm-ocores.o
obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-ocores.c b/drivers/pwm/pwm-ocores.c
new file mode 100644
index 000000000000..b126933d9922
--- /dev/null
+++ b/drivers/pwm/pwm-ocores.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OpenCores PTC PWM Driver
+ *
+ * https://opencores.org/projects/ptc
+ *
+ * Copyright (C) 2018-2026 StarFive Technology Co., Ltd.
+ *
+ * Limitations:
+ * - The hardware only supports inverted polarity.
+ * - The hardware minimum period / duty_cycle of PWM is (1 / pwm_apb clock frequency).
+ * - The hardware maximum period / duty_cycle of PWM is (U32_MAX / pwm_apb clock frequency).
+ * - The output is immediately set to low when the module is disabled.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/pwm.h>
+#include <linux/reset.h>
+
+#define OCPWM_HRC 0x4
+#define OCPWM_LRC 0x8
+#define OCPWM_CTRL 0xC
+
+#define OCPWM_CTRL_EN BIT(0)
+#define OCPWM_CTRL_OE BIT(3)
+#define OCPWM_CTRL_RST BIT(7)
+
+#define OCPWM_NUM_SAVED_REGS 3
+
+struct ocores_pwm_device {
+ void __iomem *base;
+ struct clk *clk;
+ unsigned long clk_rate;
+ struct reset_control *rst;
+ u32 saved_regs[OCPWM_NUM_SAVED_REGS];
+};
+
+static int ocores_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct ocores_pwm_device *ddata = pwmchip_get_drvdata(chip);
+ u32 period_data, duty_data, ctrl_data;
+ int ret;
+
+ ret = pm_runtime_resume_and_get(pwmchip_parent(chip));
+ if (ret < 0)
+ return ret;
+
+ period_data = readl(ddata->base + OCPWM_LRC);
+ duty_data = readl(ddata->base + OCPWM_HRC);
+ ctrl_data = readl(ddata->base + OCPWM_CTRL);
+
+ state->period = DIV_ROUND_UP_ULL((u64)period_data * NSEC_PER_SEC, ddata->clk_rate);
+ state->duty_cycle = DIV_ROUND_UP_ULL((u64)duty_data * NSEC_PER_SEC, ddata->clk_rate);
+ if (state->duty_cycle > state->period)
+ state->duty_cycle = state->period;
+
+ state->polarity = PWM_POLARITY_INVERSED;
+ state->enabled = (ctrl_data & OCPWM_CTRL_EN) ? true : false;
+
+ pm_runtime_put(pwmchip_parent(chip));
+
+ return 0;
+}
+
+static int ocores_pwm_apply(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct ocores_pwm_device *ddata = pwmchip_get_drvdata(chip);
+ bool was_enabled = pwm_is_enabled(pwm);
+ u64 period_data, duty_data;
+ int ret;
+
+ if (state->polarity != PWM_POLARITY_INVERSED)
+ return -EINVAL;
+
+ if (state->enabled) {
+ if (!was_enabled) {
+ ret = pm_runtime_resume_and_get(pwmchip_parent(chip));
+ if (ret < 0)
+ return ret;
+ }
+ } else {
+ if (was_enabled) {
+ writel(0, ddata->base + OCPWM_CTRL);
+ pm_runtime_put(pwmchip_parent(chip));
+ }
+ return 0;
+ }
+
+ writel(0, ddata->base + OCPWM_CTRL);
+ writel(OCPWM_CTRL_RST, ddata->base + OCPWM_CTRL);
+
+ period_data = mul_u64_u32_div(state->period, ddata->clk_rate, NSEC_PER_SEC);
+ if (period_data > U32_MAX)
+ period_data = U32_MAX;
+
+ duty_data = mul_u64_u32_div(state->duty_cycle, ddata->clk_rate, NSEC_PER_SEC);
+ if (duty_data > U32_MAX)
+ duty_data = U32_MAX;
+
+ if (!period_data || !duty_data) {
+ if (!was_enabled)
+ pm_runtime_put(pwmchip_parent(chip));
+ return -EINVAL;
+ }
+
+ writel(period_data, ddata->base + OCPWM_LRC);
+ writel(duty_data, ddata->base + OCPWM_HRC);
+ writel(OCPWM_CTRL_OE | OCPWM_CTRL_EN, ddata->base + OCPWM_CTRL);
+
+ return 0;
+}
+
+static void ocores_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct ocores_pwm_device *ddata = pwmchip_get_drvdata(chip);
+
+ if (pwm_is_enabled(pwm)) {
+ writel(0, ddata->base + OCPWM_CTRL);
+ pm_runtime_put_sync(pwmchip_parent(chip));
+ }
+}
+
+static const struct pwm_ops ocores_pwm_ops = {
+ .get_state = ocores_pwm_get_state,
+ .apply = ocores_pwm_apply,
+ .free = ocores_pwm_free,
+};
+
+static int ocores_pwm_runtime_suspend(struct device *dev)
+{
+ struct ocores_pwm_device *ddata = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(ddata->clk);
+
+ return 0;
+}
+
+static int ocores_pwm_runtime_resume(struct device *dev)
+{
+ struct ocores_pwm_device *ddata = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(ddata->clk);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable clock\n");
+
+ return 0;
+}
+
+static int __maybe_unused ocores_pwm_suspend(struct device *dev)
+{
+ struct ocores_pwm_device *ddata = dev_get_drvdata(dev);
+ int ret, i;
+
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < OCPWM_NUM_SAVED_REGS; i++)
+ ddata->saved_regs[i] = readl(ddata->base + 4 + 4 * i);
+
+ pm_runtime_put_sync(dev);
+
+ return pm_runtime_force_suspend(dev);
+}
+
+static int __maybe_unused ocores_pwm_resume(struct device *dev)
+{
+ struct ocores_pwm_device *ddata = dev_get_drvdata(dev);
+ int ret, i;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret < 0)
+ return ret;
+
+ writel(0, ddata->base + OCPWM_CTRL);
+ writel(OCPWM_CTRL_RST, ddata->base + OCPWM_CTRL);
+ for (i = 0; i < OCPWM_NUM_SAVED_REGS; i++)
+ writel(ddata->saved_regs[i], ddata->base + 4 + 4 * i);
+
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops ocores_pwm_pm_ops = {
+ RUNTIME_PM_OPS(ocores_pwm_runtime_suspend,
+ ocores_pwm_runtime_resume, NULL)
+ SYSTEM_SLEEP_PM_OPS(ocores_pwm_suspend, ocores_pwm_resume)
+};
+
+static void ocores_pwm_pm_disable(void *data)
+{
+ struct device *dev = data;
+ struct ocores_pwm_device *ddata = dev_get_drvdata(dev);
+
+ pm_runtime_disable(dev);
+
+ if (!pm_runtime_status_suspended(dev)) {
+ /* Balance probe's pm_runtime_get_noresume() for bootloader-enabled PWM. */
+ if (readl(ddata->base + OCPWM_CTRL) & OCPWM_CTRL_EN)
+ pm_runtime_put_noidle(dev);
+
+ ocores_pwm_runtime_suspend(dev);
+ }
+
+ reset_control_assert(ddata->rst);
+}
+
+static int ocores_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ocores_pwm_device *ddata;
+ struct pwm_chip *chip;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, 1, sizeof(*ddata));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ chip->ops = &ocores_pwm_ops;
+ ddata = pwmchip_get_drvdata(chip);
+
+ ddata->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(ddata->base))
+ return dev_err_probe(dev, PTR_ERR(ddata->base),
+ "Failed to map IO resources\n");
+
+ ddata->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ddata->clk))
+ return dev_err_probe(dev, PTR_ERR(ddata->clk),
+ "Failed to get clock\n");
+
+ ddata->clk_rate = clk_get_rate(ddata->clk);
+ if (!ddata->clk_rate || ddata->clk_rate > NSEC_PER_SEC)
+ return dev_err_probe(dev, -EINVAL,
+ "Invalid clock rate: %lu\n", ddata->clk_rate);
+
+ ddata->rst = devm_reset_control_get_optional_shared(dev, NULL);
+ if (IS_ERR(ddata->rst))
+ return dev_err_probe(dev, PTR_ERR(ddata->rst),
+ "Failed to get reset\n");
+
+ platform_set_drvdata(pdev, ddata);
+
+ ret = ocores_pwm_runtime_resume(dev);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(ddata->rst);
+ if (ret)
+ goto err_clk_disable;
+
+ ret = pm_runtime_set_active(dev);
+ if (ret)
+ goto err_reset_assert;
+
+ pm_runtime_get_noresume(dev);
+ pm_runtime_enable(dev);
+
+ if (!(readl(ddata->base + OCPWM_CTRL) & OCPWM_CTRL_EN))
+ pm_runtime_put_sync(dev);
+
+ ret = devm_add_action_or_reset(dev, ocores_pwm_pm_disable, dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add pm disable action\n");
+
+ ret = devm_pwmchip_add(dev, chip);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Could not register PWM chip\n");
+
+ return 0;
+
+err_reset_assert:
+ reset_control_assert(ddata->rst);
+err_clk_disable:
+ ocores_pwm_runtime_suspend(dev);
+ return dev_err_probe(dev, ret, "Failed to init pwm power\n");
+}
+
+static const struct of_device_id ocores_pwm_of_match[] = {
+ { .compatible = "opencores,pwm-v1" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ocores_pwm_of_match);
+
+static struct platform_driver ocores_pwm_driver = {
+ .probe = ocores_pwm_probe,
+ .driver = {
+ .name = "ocores-pwm",
+ .of_match_table = ocores_pwm_of_match,
+ .pm = pm_ptr(&ocores_pwm_pm_ops),
+ },
+};
+module_platform_driver(ocores_pwm_driver);
+
+MODULE_AUTHOR("Jieqin Chen");
+MODULE_AUTHOR("Hal Feng <hal.feng@starfivetech.com>");
+MODULE_DESCRIPTION("OpenCores PTC PWM driver");
+MODULE_LICENSE("GPL");
--
2.43.2
^ permalink raw reply related
* [PATCH v19 0/3] Add OpenCores PTC PWM support
From: Hal Feng @ 2026-06-15 15:57 UTC (permalink / raw)
To: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Emil Renner Berthing,
Palmer Dabbelt, Paul Walmsley, Albert Ou
Cc: Hal Feng, linux-pwm, devicetree, linux-riscv, linux-kernel
Add OpenCores PTC PWM driver which is used in StarFive
JH7100/JH7110/JHB100 SoC.
I will maintain this pwm module in place of William.
Changes since v18:
- Address Sashiko AI review comments for the OpenCores PWM driver.
- Fix runtime PM usage count handling on probe, error paths, PWM release
and driver teardown.
- Reject period or duty cycle values below the hardware minimum.
- Restore PWM registers across system sleep resume.
- Return the real error from devm_pwmchip_alloc().
- Preserve bootloader-configured PWM state during probe and keep runtime
PM active if the PWM is already enabled.
- Use synchronous runtime PM put before possible teardown.
Changes since v17:
- Simplify the code. Make it more readable.
- Restructure the driver to register the pwm chip for one pwm channel,
because each OpenCores PTC IP core only supports one PWM channel.
Drop starfive compatibles.
Add patches to fix the dt-bindings and device tree.
- Support runtime pm and system sleep pm.
- Disable the pwm module and reset the pwm counter before updating the
period and duty cycle.
- Improve the descriptions.
- Update the dt-bindings maintainer to Hal Feng.
History:
v18: https://lore.kernel.org/all/20260515054723.25024-1-hal.feng@starfivetech.com/
v17: https://lore.kernel.org/all/20250106103540.10079-1-william.qiu@starfivetech.com/
Hal Feng (3):
dt-bindings: pwm: opencores: Update compatibles, examples and
maintainers
riscv: dts: starfive: Correct pwm nodes
pwm: Add OpenCores PTC PWM driver
.../bindings/pwm/opencores,pwm.yaml | 16 +-
MAINTAINERS | 6 +
.../boot/dts/starfive/jh7100-common.dtsi | 28 +-
arch/riscv/boot/dts/starfive/jh7100.dtsi | 67 +++-
.../boot/dts/starfive/jh7110-common.dtsi | 27 +-
.../boot/dts/starfive/jh7110-milkv-mars.dts | 6 +-
.../dts/starfive/jh7110-milkv-marscm.dtsi | 6 +-
.../dts/starfive/jh7110-pine64-star64.dts | 6 +-
.../jh7110-starfive-visionfive-2-lite.dtsi | 6 +-
.../jh7110-starfive-visionfive-2.dtsi | 6 +-
arch/riscv/boot/dts/starfive/jh7110.dtsi | 67 +++-
drivers/pwm/Kconfig | 12 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-ocores.c | 312 ++++++++++++++++++
14 files changed, 538 insertions(+), 28 deletions(-)
create mode 100644 drivers/pwm/pwm-ocores.c
base-commit: 95e56f0f293ef797123eb032f78f5b5d56a035a6
--
2.43.2
^ permalink raw reply
* [PATCH v19 2/3] riscv: dts: starfive: Correct pwm nodes
From: Hal Feng @ 2026-06-15 15:57 UTC (permalink / raw)
To: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Emil Renner Berthing,
Palmer Dabbelt, Paul Walmsley, Albert Ou
Cc: Hal Feng, linux-pwm, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260615155759.129210-1-hal.feng@starfivetech.com>
Each of the StarFive JH7100/JH7110 SoCs has 8 OpenCores PTC IP
cores. One OpenCores PTC IP core can output one PWM channel.
Change the register size to 0x10, since an OpenCores PTC IP
has only 4 32-bit registers: CNTR, HRC, LRC and CTRL.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
---
.../boot/dts/starfive/jh7100-common.dtsi | 28 ++++++--
arch/riscv/boot/dts/starfive/jh7100.dtsi | 67 ++++++++++++++++++-
.../boot/dts/starfive/jh7110-common.dtsi | 27 ++++++--
.../boot/dts/starfive/jh7110-milkv-mars.dts | 6 +-
.../dts/starfive/jh7110-milkv-marscm.dtsi | 6 +-
.../dts/starfive/jh7110-pine64-star64.dts | 6 +-
.../jh7110-starfive-visionfive-2-lite.dtsi | 6 +-
.../jh7110-starfive-visionfive-2.dtsi | 6 +-
arch/riscv/boot/dts/starfive/jh7110.dtsi | 67 ++++++++++++++++++-
9 files changed, 198 insertions(+), 21 deletions(-)
diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
index ae1a6aeb0aea..85106545090e 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
@@ -199,13 +199,23 @@ GPO_I2C2_PAD_SDA_OEN,
};
};
- pwm_pins: pwm-0 {
- pwm-pins {
+ pwm0_pins: pwm0-0 {
+ pwm0-pins {
pinmux = <GPIOMUX(7,
GPO_PWM_PAD_OUT_BIT0,
GPO_PWM_PAD_OE_N_BIT0,
- GPI_NONE)>,
- <GPIOMUX(5,
+ GPI_NONE)>;
+ bias-disable;
+ drive-strength = <35>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+ };
+
+ pwm1_pins: pwm1-0 {
+ pwm1-pins {
+ pinmux = <GPIOMUX(5,
GPO_PWM_PAD_OUT_BIT1,
GPO_PWM_PAD_OE_N_BIT1,
GPI_NONE)>;
@@ -359,9 +369,15 @@ &osc_aud {
clock-frequency = <27000000>;
};
-&pwm {
+&pwm0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins>;
+ status = "okay";
+};
+
+&pwm1 {
pinctrl-names = "default";
- pinctrl-0 = <&pwm_pins>;
+ pinctrl-0 = <&pwm1_pins>;
status = "okay";
};
diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi b/arch/riscv/boot/dts/starfive/jh7100.dtsi
index 7de0732b8eab..90438df1f74d 100644
--- a/arch/riscv/boot/dts/starfive/jh7100.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi
@@ -360,9 +360,72 @@ watchdog@12480000 {
<&rstgen JH7100_RSTN_WDT>;
};
- pwm: pwm@12490000 {
+ pwm0: pwm@12490000 {
compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
- reg = <0x0 0x12490000 0x0 0x10000>;
+ reg = <0x0 0x12490000 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@12490010 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12490010 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@12490020 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12490020 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@12490030 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12490030 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@12498000 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12498000 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@12498010 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12498010 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@12498020 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12498020 0x0 0x10>;
+ clocks = <&clkgen JH7100_CLK_PWM_APB>;
+ resets = <&rstgen JH7100_RSTN_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm7: pwm@12498030 {
+ compatible = "starfive,jh7100-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x12498030 0x0 0x10>;
clocks = <&clkgen JH7100_CLK_PWM_APB>;
resets = <&rstgen JH7100_RSTN_PWM_APB>;
#pwm-cells = <3>;
diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
index a7a1c09a2c90..64de468f2c31 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
@@ -326,9 +326,14 @@ uboot@100000 {
};
};
-&pwm {
+&pwm0 {
pinctrl-names = "default";
- pinctrl-0 = <&pwm_pins>;
+ pinctrl-0 = <&pwm0_pins>;
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm1_pins>;
};
&spi0 {
@@ -528,12 +533,22 @@ GPOEN_ENABLE,
};
};
- pwm_pins: pwm-0 {
- pwm-pins {
+ pwm0_pins: pwm0-0 {
+ pwm0-pins {
pinmux = <GPIOMUX(46, GPOUT_SYS_PWM_CHANNEL0,
GPOEN_SYS_PWM0_CHANNEL0,
- GPI_NONE)>,
- <GPIOMUX(59, GPOUT_SYS_PWM_CHANNEL1,
+ GPI_NONE)>;
+ bias-disable;
+ drive-strength = <12>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+ };
+
+ pwm1_pins: pwm1-0 {
+ pwm1-pins {
+ pinmux = <GPIOMUX(59, GPOUT_SYS_PWM_CHANNEL1,
GPOEN_SYS_PWM0_CHANNEL1,
GPI_NONE)>;
bias-disable;
diff --git a/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
index 21873612d993..54013c70f4b4 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
+++ b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
@@ -68,7 +68,11 @@ &phy0 {
motorcomm,tx-clk-adj-enabled;
};
-&pwm {
+&pwm0 {
+ status = "okay";
+};
+
+&pwm1 {
status = "okay";
};
diff --git a/arch/riscv/boot/dts/starfive/jh7110-milkv-marscm.dtsi b/arch/riscv/boot/dts/starfive/jh7110-milkv-marscm.dtsi
index 025471061d43..31afac27b86d 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-milkv-marscm.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-milkv-marscm.dtsi
@@ -87,7 +87,11 @@ &phy0 {
motorcomm,tx-clk-adj-enabled;
};
-&pwm {
+&pwm0 {
+ status = "okay";
+};
+
+&pwm1 {
status = "okay";
};
diff --git a/arch/riscv/boot/dts/starfive/jh7110-pine64-star64.dts b/arch/riscv/boot/dts/starfive/jh7110-pine64-star64.dts
index aec7ae3d1f5b..a9e82f25efde 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-pine64-star64.dts
+++ b/arch/riscv/boot/dts/starfive/jh7110-pine64-star64.dts
@@ -95,7 +95,11 @@ &phy1 {
motorcomm,tx-clk-100-inverted;
};
-&pwm {
+&pwm0 {
+ status = "okay";
+};
+
+&pwm1 {
status = "okay";
};
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dtsi b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dtsi
index f8797a666dbf..85b56a72dff7 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dtsi
@@ -74,7 +74,11 @@ &phy0 {
tx-internal-delay-ps = <1500>;
};
-&pwm {
+&pwm0 {
+ status = "okay";
+};
+
+&pwm1 {
status = "okay";
};
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
index edc8f4588133..35208f95cd3d 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -73,7 +73,11 @@ &pcie1 {
status = "okay";
};
-&pwm {
+&pwm0 {
+ status = "okay";
+};
+
+&pwm1 {
status = "okay";
};
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 9c3e4598747e..82ea63f715b0 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -846,9 +846,72 @@ i2stx1: i2s@120c0000 {
status = "disabled";
};
- pwm: pwm@120d0000 {
+ pwm0: pwm@120d0000 {
compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
- reg = <0x0 0x120d0000 0x0 0x10000>;
+ reg = <0x0 0x120d0000 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@120d0010 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d0010 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@120d0020 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d0020 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@120d0030 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d0030 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@120d8000 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d8000 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@120d8010 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d8010 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@120d8020 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d8020 0x0 0x10>;
+ clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
+ resets = <&syscrg JH7110_SYSRST_PWM_APB>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm7: pwm@120d8030 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x0 0x120d8030 0x0 0x10>;
clocks = <&syscrg JH7110_SYSCLK_PWM_APB>;
resets = <&syscrg JH7110_SYSRST_PWM_APB>;
#pwm-cells = <3>;
--
2.43.2
^ permalink raw reply related
* Re: [PATCH net-next v7 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC
From: Benjamin Larsson @ 2026-06-15 16:31 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-12-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add PCS driver for Airoha AN7581 SoC for Ethernet/PON/PCIe/USB SERDES
> and permit usage of external PHY or connected SFP cage. Supported modes
> are USXGMII, 10G-BASER, 2500BASE-X, 1000BASE-X and SGMII.
>
> The driver probe and register the various needed registers and register as
> a PCS provider for fwnode usage.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/pcs/Kconfig | 2 +
> drivers/net/pcs/Makefile | 2 +
> drivers/net/pcs/airoha/Kconfig | 12 +
> drivers/net/pcs/airoha/Makefile | 7 +
> drivers/net/pcs/airoha/pcs-airoha-common.c | 1318 ++++++++++++
> drivers/net/pcs/airoha/pcs-airoha.h | 1309 ++++++++++++
> drivers/net/pcs/airoha/pcs-an7581.c | 2093 ++++++++++++++++++++
> 7 files changed, 4743 insertions(+)
> create mode 100644 drivers/net/pcs/airoha/Kconfig
> create mode 100644 drivers/net/pcs/airoha/Makefile
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha-common.c
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha.h
> create mode 100644 drivers/net/pcs/airoha/pcs-an7581.c
Most likely there will be pcs drivers for the EN7523 platform also. Can
the common code for an7581 have an7581 in the name instead of airoha?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH 2/7] riscv: dts: eswin: add clock generator for EIC7700 SoC
From: Conor Dooley @ 2026-06-15 16:30 UTC (permalink / raw)
To: Pinkesh Vaghela
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
devicetree, linux-kernel, linux-riscv, Min Lin, Yulin Lu,
Samuel Holland, Darshan Prajapati, Pritesh Patel
In-Reply-To: <20260615122016.1110206-3-pinkesh.vaghela@einfochips.com>
[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]
On Mon, Jun 15, 2026 at 05:50:11PM +0530, Pinkesh Vaghela wrote:
> From: Pritesh Patel <pritesh.patel@einfochips.com>
>
> Add clock generator node for EIC7700 SoC.
> HiFive Premier P550 boards have 24MHz crystal oscillator to provide
> the input clock.
>
> Signed-off-by: Pritesh Patel <pritesh.patel@einfochips.com>
> Signed-off-by: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
> ---
> .../boot/dts/eswin/eic7700-hifive-premier-p550.dts | 5 +++++
> arch/riscv/boot/dts/eswin/eic7700.dtsi | 13 +++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> index 131ed1fc6b2e..1fb92f0e7c55 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> +++ b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> @@ -20,6 +20,11 @@ chosen {
> };
> };
>
> +&xtal {
> + clock-frequency = <24000000>;
> + clock-output-names = "xtal24m";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/riscv/boot/dts/eswin/eic7700.dtsi b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> index 430a210f01e6..a7ebb1115958 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> +++ b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> @@ -4,6 +4,7 @@
> */
>
> /dts-v1/;
> +#include <dt-bindings/clock/eswin,eic7700-clock.h>
> #include <dt-bindings/reset/eswin,eic7700-reset.h>
>
> / {
> @@ -203,6 +204,11 @@ pmu {
> <0x00000000 0x0000000f 0xfffffffc 0x000000ff 0x00000078>;
> };
>
> + xtal: oscillator {
Sashiko feedback here on making this clk-<hz> or clk-<something> should
be implemented.
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + };
> +
> soc {
> compatible = "simple-bus";
> ranges;
> @@ -343,6 +349,13 @@ gpioD: gpio-port@3 {
> };
> };
>
> + clk: clock-controller@51828000 {
> + compatible = "eswin,eic7700-clock";
> + reg = <0x0 0x51828000 0x0 0x300>;
> + clocks = <&xtal>;
> + #clock-cells = <1>;
> + };
> +
> reset: reset-controller@51828300 {
> compatible = "eswin,eic7700-reset";
> reg = <0x0 0x51828300 0x0 0x200>;
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: mfd: syscon: add ESWIN EIC7700 compatible
From: Conor Dooley @ 2026-06-15 16:28 UTC (permalink / raw)
To: Pinkesh Vaghela
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
devicetree, linux-kernel, linux-riscv, Min Lin, Yulin Lu,
Samuel Holland, Darshan Prajapati, Pritesh Patel
In-Reply-To: <20260615122016.1110206-5-pinkesh.vaghela@einfochips.com>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
On Mon, Jun 15, 2026 at 05:50:13PM +0530, Pinkesh Vaghela wrote:
> Document ESWIN EIC7700 SoC compatible for syscon registers.
Some detail about what this syscon does would be nice.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Signed-off-by: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
> ---
> Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index e22867088063..7d3365601249 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -62,6 +62,7 @@ select:
> - cirrus,ep7209-syscon3
> - cnxt,cx92755-uc
> - econet,en751221-chip-scu
> + - eswin,eic7700-syscfg
> - freecom,fsg-cs2-system-controller
> - fsl,imx93-aonmix-ns-syscfg
> - fsl,imx93-wakeupmix-syscfg
> @@ -175,6 +176,7 @@ properties:
> - cirrus,ep7209-syscon3
> - cnxt,cx92755-uc
> - econet,en751221-chip-scu
> + - eswin,eic7700-syscfg
> - freecom,fsg-cs2-system-controller
> - fsl,imx93-aonmix-ns-syscfg
> - fsl,imx93-wakeupmix-syscfg
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: install DT overlays via dtbs_install
From: Vishwas Udupa @ 2026-06-15 16:27 UTC (permalink / raw)
To: krzk
Cc: andersson, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, vudupa
In-Reply-To: <0f045b88-94fc-46b5-8a49-8a53235fc8fc@kernel.org>
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
^ 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