* Re: [PATCH] fix: clk/samsung: exynos_clkout_probe: success path leaks parent clock references from of_clk_get_by_name
From: WenTao Liang @ 2026-06-27 11:42 UTC (permalink / raw)
To: Greg KH
Cc: krzk, s.nawrocki, cw00.choi, mturquette, sboyd, alim.akhtar,
bmasney, linux-samsung-soc, linux-clk, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <2026062612-twiddling-lagged-62ac@gregkh>
> 2026年6月26日 22:24，Greg KH <gregkh@linuxfoundation.org> 写道：
>
> On Fri, Jun 26, 2026 at 08:01:35PM +0800, WenTao Liang wrote:
>> of_clk_get_by_name() acquires clock references stored in the local
>> parents[] array. All error paths correctly release these via the clks_put
>> label, but the success path returns 0 without releasing the parent
>> references. The references were only needed to obtain clock names for
>> registration and are permanently leaked after probe completes.
>>
>> Cc: stable@vger.kernel.org
>> Fixes: 9484f2cb8332 ("clk: samsung: exynos-clkout: convert to module driver")
>> Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
>> ---
>> drivers/clk/samsung/clk-exynos-clkout.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> For all of these, you are not using the normal kernel style, which means
> a LLM is generating them, which implies that you did not properly
> document what tool found/fixed all of these. So please go back and fix
> them all up and resend them properly, after telling the
> maintainers/developers that the originals should be ignored.
>
> thanks,
>
> greg k-h
Thank you for the review and guidance. I understand the issues now.
I will:
1. Study the proper kernel coding style
2. If using any automated tools, document them properly in the commit
message
3. Fix all the patches following the correct style
4. Send a v2 series with proper version history
5. Inform all maintainers that the original patches should be ignored
I apologize for the inconvenience and will ensure future submissions
follow all kernel submission guidelines properly.
Regards,
WenTao Liang
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Pengjie Zhang @ 2026-06-27 11:26 UTC (permalink / raw)
To: Vanshidhar Konda
Cc: Will Deacon, catalin.marinas, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui,
linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, ionela.voinescu, jeremy.linton
In-Reply-To: <20260625-singing-fair-guillemot-9eb79e-vanshikonda@os.amperecomputing.com>
On 6/26/2026 10:55 PM, Vanshidhar Konda wrote:
> On Wed, May 20, 2026 at 10:55:54AM +0800, Pengjie Zhang wrote:
>>
>> On 5/19/2026 6:47 PM, Will Deacon wrote:
>>> On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
>>>> Hi all,
>>>>
>>>> Gentle ping on this thread. It has been a while since I posted it.
>>>>
>>>> Could someone please take a look when you have time? If there is
>>>> anything
>>>> I should revise or any additional information needed, I'd be happy to
>>>> update it.
>>> It's hard to find active folks who have contributed meaningfully to the
>>> cppc_acpi driver... I've added Ionella and Jeremy, in case they can
>>> take
>>> a look.
>>>
>>> Will
>> Thanks Will, and thanks for adding Ionela and Jeremy.
>>
>> While waiting for further comments, I would like to add some
>> test data to make the effect of this series clearer.
>>
>> On the test platform, the maximum frequency reported by the platform
>> is 2300000. I sampled cpuinfo_cur_freq before and after applying this
>> series.
>>
>> Before applying the series, the samples showed visible transient
>> outliers.
>> ??The minimum value was 2154583 and the maximum value was 2491071.
>> There were 8 samples above 2400000 and 8 samples below 2200000.
>> The largest value exceeded the platform maximum by about 8.3%.
>>
>> After applying the series, the samples became much more stable.
>> The minimum value was 2290243 and the maximum value was 2306310.
>> There were no samples above 2400000 and no samples below 2200000.
>> The largest value exceeded the platform maximum by only about 0.27%.
>>
>> A summary of the 96 samples is:
>>
>> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? before?? ?? ?? ?? ?? after
>> min?? ?? ?? ?? ?? ?? ?? 2154583?? ?? ?? ?? ??2290243
>> max?? ?? ?? ?? ?? ?? ?? 2491071?? ?? ?? ?? ??2306310
>> range?? ?? ?? ?? ?? ?? ??336488?? ?? ?? ?? ?? ??16067
>> average?? ?? ?? ?? ?? 2298436.4?? ?? ?? ??2298479.4
>> stddev?? ?? ?? ?? ?? ?? ??55184.1?? ?? ?? ?? ?? 2868.2
>> samples > 2300000?? 26 / 96?? ?? ?? ?? ??16 / 96
>> samples > 2400000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>> samples < 2200000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>>
>> So this series does not try to clamp the value to the platform maximum.
>> ??Instead, it reduces the sampling skew between the delivered and
>> reference
>> feedback counters. The remaining small deviation around 2300000 is
>> ??much smaller than the previous transient spikes.
>>
>> One concern that may come up is that an FFH read may cause an idle
>> target CPU to be woken, depending on the platform/vendor implementation.
>> However, that behavior is not introduced by this series. It is
>> already part
>> of how FFH counter reads are implemented on such platforms. This series
>> only changes the sampling form for the FFH feedback counters: when both
>> delivered and reference counters are FFH counters, read them together
>> instead of issuing two separate FFH reads.
>>
>> If the target CPU has to be involved for an FFH read, doing one paired
>> read should be no worse than doing two separate reads, and it also
>> narrows the sampling window between the two counters.
>>
>
> I agree with this point. It reduces the number of times the idle CPU
> is woken up just to read counters.
>
>> If there is any concern about the generic hook or the arm64
>> implementation,
>> I would be happy to revise it.
>>
>> The raw data is as follows:
>> before:
>> 2303809 2294827 2300000 2293643 2290740 2300000 2297228 2296082
>> 2301707 2295354 2296601 2303163 2296766 2296543 2295412 2298394
>> 2297387 2300000 2308274 2301882 2297752 2418568 2491071 2300000
>> 2183264 2296238 2434731 2296721 2439777 2302159 2301773 2298226
>> 2300000 2305936 2301133 2297511 2300000 2300000 2294408 2298494
>> 2295011 2302721 2295955 2301505 2298064 2297419 2298933 2189595
>> 2298058 2296046 2300000 2301449 2414908 2296559 2305251 2166666
>> 2296626 2173303 2300000 2298806 2411389 2301822 2297291 2300000
>> 2423831 2297902 2300000 2435730 2302433 2295353 2298898 2296043
>> 2321868 2294907 2300000 2157841 2296052 2206530 2300000 2297811
>> 2297920 2294382 2297767 2157230 2302564 2298504 2296822 2300000
>> 2296868 2294866 2154583 2290888 2302542 2292549 2300000 2184259
>>
>> after:
>> 2303738 2296153 2298087 2295607 2301373 2298076 2300000 2295081
>> 2297788 2300000 2300000 2295238 2301449 2300000 2298488 2297911
>> 2301477 2298507 2294976 2296852 2293689 2294077 2293887 2292619
>> 2300000 2300000 2298072 2300000 2291943 2300000 2295370 2300000
>> 2301873 2304645 2300000 2296766 2300000 2300000 2290243 2297954
>> 2297183 2306310 2300000 2296889 2300000 2303800 2301970 2296888
>> 2300000 2301354 2300000 2298405 2298202 2296767 2298663 2302522
>> 2297821 2302471 2300000 2303233 2298226 2298698 2300000 2297291
>> 2296470 2300000 2298398 2300000 2295681 2300000 2300000 2296344
>> 2300000 2296008 2302375 2297977 2298447 2296519 2295565 2294866
>> 2297945 2300000 2294978 2303595 2300000 2300000 2294930 2301096
>> 2296271 2296086 2294482 2300000 2294843 2300000 2296803 2295708
>
> I tested this series on Ampere AmpereOne A192-32X.
>
> Tested-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
> Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
>
> Regards,
> Vanshidhar Konda
>
Hi Vanshidhar,
Thank you for taking the time to review and test this series, especially
on the AmpereOne A192-32X platform. It's great to know it works well there.
I will add your tags to the next version.
Thanks again,
Pengjie
>>>> On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
>>>>> The legacy CPPC feedback-counter path reads the delivered and
>>>>> reference
>>>>> performance counters separately.
>>>>>
>>>>> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
>>>>> served through a cross-CPU counter read helper. Reading the counters
>>>>> separately therefore widens the sampling window between them and can
>>>>> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under
>>>>> heavy
>>>>> load, the skew is observable as transient values that may exceed the
>>>>> platform maximum, as discussed in [1] and [2].
>>>>>
>>>>> This series adds a small generic hook for architectures that can
>>>>> obtain
>>>>> both FFH feedback counters in one operation, while preserving the
>>>>> existing per-register read path as the fallback.
>>>>>
>>>>> Patch 1 adds the generic CPPC hook and uses it from
>>>>> cppc_get_perf_ctrs().
>>>>> Patch 2 implements the hook on arm64 by sampling both AMU counters
>>>>> in a
>>>>> single operation on the target CPU.
>>>>>
>>>>> [1]
>>>>> https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
>>>>> [2]
>>>>> https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>>>>
>>>>>
>>>>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>>>>>
>>>>> Pengjie Zhang (2):
>>>>> ACPI: CPPC: add paired FFH feedback-counter read hook
>>>>> arm64: topology: read CPPC FFH feedback counters in one operation
>>>>>
>>>>> arch/arm64/kernel/topology.c | 75
>>>>> ++++++++++++++++++++++++++++++++----
>>>>> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
>>>>> include/acpi/cppc_acpi.h | 7 ++++
>>>>> 3 files changed, 127 insertions(+), 13 deletions(-)
>>>>>
>
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Pengjie Zhang @ 2026-06-27 10:50 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, rafael, lenb, robert.moore, beata.michalska,
zhenglifeng1, zhanjie9, sumitg, cuiyunhui, linux-arm-kernel,
linux-kernel, linux-acpi, acpica-devel, linuxarm,
jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5, lihuisong,
yubowen8, wangzhi12, ionela.voinescu, jeremy.linton
In-Reply-To: <443104e2-ba6e-454e-8469-909f35817a99@huawei.com>
On 5/20/2026 10:55 AM, Pengjie Zhang wrote:
>
> On 5/19/2026 6:47 PM, Will Deacon wrote:
>> On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
>>> Hi all,
>>>
>>> Gentle ping on this thread. It has been a while since I posted it.
>>>
>>> Could someone please take a look when you have time? If there is
>>> anything
>>> I should revise or any additional information needed, I'd be happy to
>>> update it.
>> It's hard to find active folks who have contributed meaningfully to the
>> cppc_acpi driver... I've added Ionella and Jeremy, in case they can take
>> a look.
>>
>> Will
> Thanks Will, and thanks for adding Ionela and Jeremy.
>
> While waiting for further comments, I would like to add some
> test data to make the effect of this series clearer.
>
> On the test platform, the maximum frequency reported by the platform
> is 2300000. I sampled cpuinfo_cur_freq before and after applying this
> series.
>
> Before applying the series, the samples showed visible transient
> outliers.
> The minimum value was 2154583 and the maximum value was 2491071.
> There were 8 samples above 2400000 and 8 samples below 2200000.
> The largest value exceeded the platform maximum by about 8.3%.
>
> After applying the series, the samples became much more stable.
> The minimum value was 2290243 and the maximum value was 2306310.
> There were no samples above 2400000 and no samples below 2200000.
> The largest value exceeded the platform maximum by only about 0.27%.
>
> A summary of the 96 samples is:
>
> before after
> min 2154583 2290243
> max 2491071 2306310
> range 336488 16067
> average 2298436.4 2298479.4
> stddev 55184.1 2868.2
> samples > 2300000 26 / 96 16 / 96
> samples > 2400000 8 / 96 0 / 96
> samples < 2200000 8 / 96 0 / 96
>
> So this series does not try to clamp the value to the platform maximum.
> Instead, it reduces the sampling skew between the delivered and
> reference
> feedback counters. The remaining small deviation around 2300000 is
> much smaller than the previous transient spikes.
>
> One concern that may come up is that an FFH read may cause an idle
> target CPU to be woken, depending on the platform/vendor implementation.
> However, that behavior is not introduced by this series. It is already
> part
> of how FFH counter reads are implemented on such platforms. This series
> only changes the sampling form for the FFH feedback counters: when both
> delivered and reference counters are FFH counters, read them together
> instead of issuing two separate FFH reads.
>
> If the target CPU has to be involved for an FFH read, doing one paired
> read should be no worse than doing two separate reads, and it also
> narrows the sampling window between the two counters.
>
> If there is any concern about the generic hook or the arm64
> implementation,
> I would be happy to revise it.
>
> The raw data is as follows:
> before:
> 2303809 2294827 2300000 2293643 2290740 2300000 2297228 2296082
> 2301707 2295354 2296601 2303163 2296766 2296543 2295412 2298394
> 2297387 2300000 2308274 2301882 2297752 2418568 2491071 2300000
> 2183264 2296238 2434731 2296721 2439777 2302159 2301773 2298226
> 2300000 2305936 2301133 2297511 2300000 2300000 2294408 2298494
> 2295011 2302721 2295955 2301505 2298064 2297419 2298933 2189595
> 2298058 2296046 2300000 2301449 2414908 2296559 2305251 2166666
> 2296626 2173303 2300000 2298806 2411389 2301822 2297291 2300000
> 2423831 2297902 2300000 2435730 2302433 2295353 2298898 2296043
> 2321868 2294907 2300000 2157841 2296052 2206530 2300000 2297811
> 2297920 2294382 2297767 2157230 2302564 2298504 2296822 2300000
> 2296868 2294866 2154583 2290888 2302542 2292549 2300000 2184259
>
> after:
> 2303738 2296153 2298087 2295607 2301373 2298076 2300000 2295081
> 2297788 2300000 2300000 2295238 2301449 2300000 2298488 2297911
> 2301477 2298507 2294976 2296852 2293689 2294077 2293887 2292619
> 2300000 2300000 2298072 2300000 2291943 2300000 2295370 2300000
> 2301873 2304645 2300000 2296766 2300000 2300000 2290243 2297954
> 2297183 2306310 2300000 2296889 2300000 2303800 2301970 2296888
> 2300000 2301354 2300000 2298405 2298202 2296767 2298663 2302522
> 2297821 2302471 2300000 2303233 2298226 2298698 2300000 2297291
> 2296470 2300000 2298398 2300000 2295681 2300000 2300000 2296344
> 2300000 2296008 2302375 2297977 2298447 2296519 2295565 2294866
> 2297945 2300000 2294978 2303595 2300000 2300000 2294930 2301096
> 2296271 2296086 2294482 2300000 2294843 2300000 2296803 2295708
To follow up on the test data and address any potential questions about
why the patched frequency doesn't clamp exactly to 2300000, I would like
to share a breakdown of the instruction-level overhead that explains this
minor jitter.
Even when pairing the reads in this series, cpu_read_constcnt() and
cpu_read_corecnt() still have intrinsic function call and execution
overheads. A simplified execution trace looks like this:
cpu_read_constcnt:
bl
mrs constcnt <-- T_const (Read timestamp)
str
ret
cpu_read_corecnt:
bl
mrs corecnt <-- T_core (Read timestamp)
str
ret
Let δ (delta) be the delay between the two reads in core cycles,
such that δ = T_core - T_const.
For two consecutive samples:
Sample 1: constcnt = A1, corecnt = B1 (with delay δ1)
Sample 2: constcnt = A2, corecnt = B2 (with delay δ2)
If we substitute these into the frequency calculation:
freq = (B2 - B1) / (A2 - A1) * cntfrq
We get:
freq = Real_Freq + [ (δ2 - δ1) / (A2 - A1) ] * cntfrq
The error term is entirely dictated by (δ2 - δ1). On modern superscalar,
out-of-order architectures like ARM64, even identical instruction sequences
experience microarchitectural jitter. Because of this, δ1 may not
be equal to δ2.
On our test platform, the maximum observed difference for (δ2 - δ1) is
roughly 40 cycles. Over a typical 2us sampling window (plus the FFH
function call overhead), this translates to a maximum theoretical error of
< 10MHz, which is less than 1%.
>>> On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
>>>> The legacy CPPC feedback-counter path reads the delivered and
>>>> reference
>>>> performance counters separately.
>>>>
>>>> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
>>>> served through a cross-CPU counter read helper. Reading the counters
>>>> separately therefore widens the sampling window between them and can
>>>> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under
>>>> heavy
>>>> load, the skew is observable as transient values that may exceed the
>>>> platform maximum, as discussed in [1] and [2].
>>>>
>>>> This series adds a small generic hook for architectures that can
>>>> obtain
>>>> both FFH feedback counters in one operation, while preserving the
>>>> existing per-register read path as the fallback.
>>>>
>>>> Patch 1 adds the generic CPPC hook and uses it from
>>>> cppc_get_perf_ctrs().
>>>> Patch 2 implements the hook on arm64 by sampling both AMU counters
>>>> in a
>>>> single operation on the target CPU.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
>>>> [2]
>>>> https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>>>
>>>>
>>>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>>>>
>>>> Pengjie Zhang (2):
>>>> ACPI: CPPC: add paired FFH feedback-counter read hook
>>>> arm64: topology: read CPPC FFH feedback counters in one operation
>>>>
>>>> arch/arm64/kernel/topology.c | 75
>>>> ++++++++++++++++++++++++++++++++----
>>>> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
>>>> include/acpi/cppc_acpi.h | 7 ++++
>>>> 3 files changed, 127 insertions(+), 13 deletions(-)
>>>>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board
From: Hrushiraj Gandhi @ 2026-06-27 10:26 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627102633.86222-1-hrushirajg23@gmail.com>
Add device tree for the Vicharak Vaaman2, a single-board computer
based on the Rockchip RK3588 SoC.
The board features:
- RK3588 SoC with 4x Cortex-A76 (big) + 4x Cortex-A55 (little)
- eMMC storage via SDHCI (HS400)
- microSD card via SDMMC
- RK806 PMIC on SPI2 providing all required power domains
- Two RK8602/RK8603 CPU regulators on I2C0 (big clusters)
- RK8602 NPU regulator on I2C1
- HYM8563 RTC on I2C0
- Status LED on GPIO2_C5 (active-low, heartbeat trigger)
- UART2 as serial console at 1500000 baud
- SARADC with 1.8V reference
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
2 files changed, 548 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 92114cb757cc..9213280d831b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-toybrick-x0.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-axon.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-vaaman2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-gameforce-ace.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
new file mode 100644
index 000000000000..9ba9688c1213
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
@@ -0,0 +1,547 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588.dtsi"
+
+/ {
+ model = "Vicharak Vaaman2";
+ compatible = "vicharak,vaaman2", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdmmc;
+ mmc1 = &sdhci;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_led: status-led {
+ gpios = <&gpio2 RK_PC5 GPIO_ACTIVE_LOW>;
+ function = LED_FUNCTION_STATUS;
+ default-state = "on";
+ retain-state-suspended;
+ linux,default-trigger = "heartbeat";
+ };
+
+ };
+
+ vcc20v_dcin: regulator-vcc20v-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc20v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <20000000>;
+ regulator-max-microvolt = <20000000>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc20v_dcin>;
+ };
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+
+&i2c0 {
+ pinctrl-0 = <&i2c0m2_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ vdd_cpu_big0_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x42>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big0_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_big1_s0: regulator@43 {
+ compatible = "rockchip,rk8603", "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x43>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big1_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtc_int>;
+ wakeup-source;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m2_xfer>;
+ status = "okay";
+
+ vdd_npu_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ reg = <0x42>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_npu_s0";
+ regulator-boot-on;
+ regulator-enable-ramp-delay = <500>;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&sdhci {
+ bus-width = <8>;
+ full-pwr-cycle-in-suspend;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ no-sd;
+ no-sdio;
+ non-removable;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vcc_1v8_s3>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <200000000>;
+ no-mmc;
+ no-sdio;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
+&spi2 {
+ assigned-clock-rates = <200000000>;
+ assigned-clocks = <&cru CLK_SPI2>;
+ num-cs = <1>;
+ pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ reg = <0>;
+ compatible = "rockchip,rk806";
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-parent = <&gpio0>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+ spi-max-frequency = <1000000>;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc5v0_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc5v0_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc5v0_sys>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ regulators {
+ vdd_gpu_s0: dcdc-reg1 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_log_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_vdenc_s0: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_2v0_pldo_s3: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-name = "vdd_2v0_pldo_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2000000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avcc_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "avcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avdd_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "avdd_1v2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "pldo6_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_ddr_pll_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ avdd_0v75_s0: nldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "avdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_0v85_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ hym8563 {
+ rtc_int: rtc-int {
+ rockchip,pins =
+ <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&saradc {
+ vref-supply = <&avcc_1v8_s0>;
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2m0_xfer>;
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: arm: rockchip: Add Vicharak Vaaman2
From: Hrushiraj Gandhi @ 2026-06-27 10:26 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627102633.86222-1-hrushirajg23@gmail.com>
Add device tree binding documentation for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index b023d4cc9842..b5a43fd5e546 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1311,6 +1311,11 @@ properties:
- const: vicharak,axon
- const: rockchip,rk3588
+ - description: Vicharak Vaaman2
+ items:
+ - const: vicharak,vaaman2
+ - const: rockchip,rk3588
+
- description: WolfVision PF5 mainboard
items:
- const: wolfvision,rk3568-pf5
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Hrushiraj Gandhi @ 2026-06-27 10:26 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
This patch series adds device tree support for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
The Vaaman2 board features include:
- RK3588 SoC
- eMMC storage and microSD support
- RK806 PMIC and multiple RK8602/RK8603 regulators
- Real-time clock and status LED
- UART serial console and SARADC
Note: This series was generated on top of the pending Vicharak Axon
board support patches (v7) and includes the Axon entry in the context
of the YAML binding patch.
Changes in v2:
- Fixed rk806 PMIC pinctrl node names to comply with dtbs_check ('-pins' suffix).
- Removed I2S audio nodes which were unneeded for minimal boot.
- Cleaned up indentation throughout the DTS.
Patch 1 adds the binding documentation for the Vaaman2 board.
Patch 2 adds the actual device tree file and Makefile entry.
Hrushiraj Gandhi (2):
dt-bindings: arm: rockchip: Add Vicharak Vaaman2
arm64: dts: rockchip: Add Vicharak Vaaman2 board
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
3 files changed, 553 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
--
2.47.3
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Heiko Stübner @ 2026-06-27 10:06 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel,
Hrushiraj Gandhi
Cc: robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <1999863.IobQ9Gjlxr@diego>
Am Samstag, 27. Juni 2026, 12:05:35 Mitteleuropäische Sommerzeit schrieb Heiko Stübner:
> Hi,
>
> Am Samstag, 27. Juni 2026, 11:48:52 Mitteleuropäische Sommerzeit schrieb Hrushiraj Gandhi:
> > This patch series adds device tree support for the Vicharak Vaaman2,
> > a single-board computer based on the Rockchip RK3588 SoC.
>
> please use proper versioning when sending new patches
>
> If I'm reading this correctly, this should be
>
> [PATCH v3 0/2] ....
correction .. v2 ;-)
The other was the Axon board.
>
> Please also provide a changelog on what changed between versions.
> See all the other patchsets on the mailinglist for reference.
>
> Heiko
>
> > The Vaaman2 board features include:
> > - RK3588 SoC
> > - eMMC storage and microSD support
> > - RK806 PMIC and multiple RK8602/RK8603 regulators
> > - Real-time clock and status LED
> > - UART serial console and SARADC
> >
> > Note: This series was generated on top of the pending Vicharak Axon
> > board support patches (v7) and includes the Axon entry in the context
> > of the YAML binding patch.
> >
> > Patch 1 adds the binding documentation for the Vaaman2 board.
> > Patch 2 adds the actual device tree file and Makefile entry.
> >
> > Hrushiraj Gandhi (2):
> > dt-bindings: arm: rockchip: Add Vicharak Vaaman2
> > arm64: dts: rockchip: Add Vicharak Vaaman2 board
> >
> > .../devicetree/bindings/arm/rockchip.yaml | 5 +
> > arch/arm64/boot/dts/rockchip/Makefile | 1 +
> > .../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
> > 3 files changed, 553 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
> >
> >
>
>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Heiko Stübner @ 2026-06-27 10:05 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel,
Hrushiraj Gandhi
Cc: robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627094854.81564-1-hrushirajg23@gmail.com>
Hi,
Am Samstag, 27. Juni 2026, 11:48:52 Mitteleuropäische Sommerzeit schrieb Hrushiraj Gandhi:
> This patch series adds device tree support for the Vicharak Vaaman2,
> a single-board computer based on the Rockchip RK3588 SoC.
please use proper versioning when sending new patches
If I'm reading this correctly, this should be
[PATCH v3 0/2] ....
Please also provide a changelog on what changed between versions.
See all the other patchsets on the mailinglist for reference.
Heiko
> The Vaaman2 board features include:
> - RK3588 SoC
> - eMMC storage and microSD support
> - RK806 PMIC and multiple RK8602/RK8603 regulators
> - Real-time clock and status LED
> - UART serial console and SARADC
>
> Note: This series was generated on top of the pending Vicharak Axon
> board support patches (v7) and includes the Axon entry in the context
> of the YAML binding patch.
>
> Patch 1 adds the binding documentation for the Vaaman2 board.
> Patch 2 adds the actual device tree file and Makefile entry.
>
> Hrushiraj Gandhi (2):
> dt-bindings: arm: rockchip: Add Vicharak Vaaman2
> arm64: dts: rockchip: Add Vicharak Vaaman2 board
>
> .../devicetree/bindings/arm/rockchip.yaml | 5 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
> 3 files changed, 553 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
>
>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board
From: Hrushiraj Gandhi @ 2026-06-27 9:48 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627094854.81564-1-hrushirajg23@gmail.com>
Add device tree for the Vicharak Vaaman2, a single-board computer
based on the Rockchip RK3588 SoC.
The board features:
- RK3588 SoC with 4x Cortex-A76 (big) + 4x Cortex-A55 (little)
- eMMC storage via SDHCI (HS400)
- microSD card via SDMMC
- RK806 PMIC on SPI2 providing all required power domains
- Two RK8602/RK8603 CPU regulators on I2C0 (big clusters)
- RK8602 NPU regulator on I2C1
- HYM8563 RTC on I2C0
- Status LED on GPIO2_C5 (active-low, heartbeat trigger)
- UART2 as serial console at 1500000 baud
- SARADC with 1.8V reference
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
2 files changed, 548 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 92114cb757cc..9213280d831b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-toybrick-x0.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-axon.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-vaaman2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-gameforce-ace.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
new file mode 100644
index 000000000000..9ba9688c1213
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
@@ -0,0 +1,547 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588.dtsi"
+
+/ {
+ model = "Vicharak Vaaman2";
+ compatible = "vicharak,vaaman2", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdmmc;
+ mmc1 = &sdhci;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_led: status-led {
+ gpios = <&gpio2 RK_PC5 GPIO_ACTIVE_LOW>;
+ function = LED_FUNCTION_STATUS;
+ default-state = "on";
+ retain-state-suspended;
+ linux,default-trigger = "heartbeat";
+ };
+
+ };
+
+ vcc20v_dcin: regulator-vcc20v-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc20v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <20000000>;
+ regulator-max-microvolt = <20000000>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc20v_dcin>;
+ };
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+
+&i2c0 {
+ pinctrl-0 = <&i2c0m2_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ vdd_cpu_big0_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x42>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big0_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_big1_s0: regulator@43 {
+ compatible = "rockchip,rk8603", "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x43>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big1_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtc_int>;
+ wakeup-source;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m2_xfer>;
+ status = "okay";
+
+ vdd_npu_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ reg = <0x42>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_npu_s0";
+ regulator-boot-on;
+ regulator-enable-ramp-delay = <500>;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&sdhci {
+ bus-width = <8>;
+ full-pwr-cycle-in-suspend;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ no-sd;
+ no-sdio;
+ non-removable;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vcc_1v8_s3>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <200000000>;
+ no-mmc;
+ no-sdio;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
+&spi2 {
+ assigned-clock-rates = <200000000>;
+ assigned-clocks = <&cru CLK_SPI2>;
+ num-cs = <1>;
+ pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ reg = <0>;
+ compatible = "rockchip,rk806";
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-parent = <&gpio0>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+ spi-max-frequency = <1000000>;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc5v0_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc5v0_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc5v0_sys>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ regulators {
+ vdd_gpu_s0: dcdc-reg1 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_log_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_vdenc_s0: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_2v0_pldo_s3: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-name = "vdd_2v0_pldo_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2000000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avcc_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "avcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avdd_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "avdd_1v2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "pldo6_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_ddr_pll_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ avdd_0v75_s0: nldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "avdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_0v85_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ hym8563 {
+ rtc_int: rtc-int {
+ rockchip,pins =
+ <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&saradc {
+ vref-supply = <&avcc_1v8_s0>;
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2m0_xfer>;
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: rockchip: Add Vicharak Vaaman2
From: Hrushiraj Gandhi @ 2026-06-27 9:48 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
In-Reply-To: <20260627094854.81564-1-hrushirajg23@gmail.com>
Add device tree binding documentation for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index b023d4cc9842..b5a43fd5e546 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1311,6 +1311,11 @@ properties:
- const: vicharak,axon
- const: rockchip,rk3588
+ - description: Vicharak Vaaman2
+ items:
+ - const: vicharak,vaaman2
+ - const: rockchip,rk3588
+
- description: WolfVision PF5 mainboard
items:
- const: wolfvision,rk3568-pf5
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Hrushiraj Gandhi @ 2026-06-27 9:48 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
Cc: heiko, robh, krzk+dt, conor+dt, Hrushiraj Gandhi
This patch series adds device tree support for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
The Vaaman2 board features include:
- RK3588 SoC
- eMMC storage and microSD support
- RK806 PMIC and multiple RK8602/RK8603 regulators
- Real-time clock and status LED
- UART serial console and SARADC
Note: This series was generated on top of the pending Vicharak Axon
board support patches (v7) and includes the Axon entry in the context
of the YAML binding patch.
Patch 1 adds the binding documentation for the Vaaman2 board.
Patch 2 adds the actual device tree file and Makefile entry.
Hrushiraj Gandhi (2):
dt-bindings: arm: rockchip: Add Vicharak Vaaman2
arm64: dts: rockchip: Add Vicharak Vaaman2 board
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
3 files changed, 553 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
--
2.47.3
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board
From: Hrushiraj Gandhi @ 2026-06-27 9:38 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel
Cc: heiko, robh+dt, krzysztof.kozlowski+dt, conor+dt,
Hrushiraj Gandhi
In-Reply-To: <20260627093831.80495-1-hrushirajg23@gmail.com>
Add device tree for the Vicharak Vaaman2, a single-board computer
based on the Rockchip RK3588 SoC.
The board features:
- RK3588 SoC with 4x Cortex-A76 (big) + 4x Cortex-A55 (little)
- eMMC storage via SDHCI (HS400)
- microSD card via SDMMC
- RK806 PMIC on SPI2 providing all required power domains
- Two RK8602/RK8603 CPU regulators on I2C0 (big clusters)
- RK8602 NPU regulator on I2C1
- HYM8563 RTC on I2C0
- Status LED on GPIO2_C5 (active-low, heartbeat trigger)
- UART2 as serial console at 1500000 baud
- SARADC with 1.8V reference
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
2 files changed, 548 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 92114cb757cc..9213280d831b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-toybrick-x0.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-axon.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-vaaman2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-gameforce-ace.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
new file mode 100644
index 000000000000..9ba9688c1213
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
@@ -0,0 +1,547 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588.dtsi"
+
+/ {
+ model = "Vicharak Vaaman2";
+ compatible = "vicharak,vaaman2", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdmmc;
+ mmc1 = &sdhci;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_led: status-led {
+ gpios = <&gpio2 RK_PC5 GPIO_ACTIVE_LOW>;
+ function = LED_FUNCTION_STATUS;
+ default-state = "on";
+ retain-state-suspended;
+ linux,default-trigger = "heartbeat";
+ };
+
+ };
+
+ vcc20v_dcin: regulator-vcc20v-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc20v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <20000000>;
+ regulator-max-microvolt = <20000000>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc20v_dcin>;
+ };
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+ cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+
+&i2c0 {
+ pinctrl-0 = <&i2c0m2_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ vdd_cpu_big0_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x42>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big0_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_big1_s0: regulator@43 {
+ compatible = "rockchip,rk8603", "rockchip,rk8602";
+ fcs,suspend-voltage-selector = <1>;
+ reg = <0x43>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1050000>;
+ regulator-min-microvolt = <550000>;
+ regulator-name = "vdd_cpu_big1_s0";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtc_int>;
+ wakeup-source;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m2_xfer>;
+ status = "okay";
+
+ vdd_npu_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ reg = <0x42>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_npu_s0";
+ regulator-boot-on;
+ regulator-enable-ramp-delay = <500>;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&sdhci {
+ bus-width = <8>;
+ full-pwr-cycle-in-suspend;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ no-sd;
+ no-sdio;
+ non-removable;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vcc_1v8_s3>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <200000000>;
+ no-mmc;
+ no-sdio;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
+&spi2 {
+ assigned-clock-rates = <200000000>;
+ assigned-clocks = <&cru CLK_SPI2>;
+ num-cs = <1>;
+ pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ reg = <0>;
+ compatible = "rockchip,rk806";
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-parent = <&gpio0>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+ spi-max-frequency = <1000000>;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc5v0_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc5v0_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc5v0_sys>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ regulators {
+ vdd_gpu_s0: dcdc-reg1 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_log_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_vdenc_s0: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_2v0_pldo_s3: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-name = "vdd_2v0_pldo_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2000000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avcc_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "avcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ avdd_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "avdd_1v2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "pldo6_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_ddr_pll_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ avdd_0v75_s0: nldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "avdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_0v85_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ hym8563 {
+ rtc_int: rtc-int {
+ rockchip,pins =
+ <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&saradc {
+ vref-supply = <&avcc_1v8_s0>;
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2m0_xfer>;
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: rockchip: Add Vicharak Vaaman2
From: Hrushiraj Gandhi @ 2026-06-27 9:38 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel
Cc: heiko, robh+dt, krzysztof.kozlowski+dt, conor+dt,
Hrushiraj Gandhi
In-Reply-To: <20260627093831.80495-1-hrushirajg23@gmail.com>
Add device tree binding documentation for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index b023d4cc9842..b5a43fd5e546 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1311,6 +1311,11 @@ properties:
- const: vicharak,axon
- const: rockchip,rk3588
+ - description: Vicharak Vaaman2
+ items:
+ - const: vicharak,vaaman2
+ - const: rockchip,rk3588
+
- description: WolfVision PF5 mainboard
items:
- const: wolfvision,rk3568-pf5
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: rockchip: Add Vicharak Vaaman2 board support
From: Hrushiraj Gandhi @ 2026-06-27 9:38 UTC (permalink / raw)
To: linux-rockchip, devicetree, linux-arm-kernel
Cc: heiko, robh+dt, krzysztof.kozlowski+dt, conor+dt,
Hrushiraj Gandhi
This patch series adds device tree support for the Vicharak Vaaman2,
a single-board computer based on the Rockchip RK3588 SoC.
The Vaaman2 board features include:
- RK3588 SoC
- eMMC storage and microSD support
- RK806 PMIC and multiple RK8602/RK8603 regulators
- Real-time clock and status LED
- UART serial console and SARADC
Note: This series was generated on top of the pending Vicharak Axon
board support patches (v7) and includes the Axon entry in the context
of the YAML binding patch.
Patch 1 adds the binding documentation for the Vaaman2 board.
Patch 2 adds the actual device tree file and Makefile entry.
Hrushiraj Gandhi (2):
dt-bindings: arm: rockchip: Add Vicharak Vaaman2
arm64: dts: rockchip: Add Vicharak Vaaman2 board
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588-vicharak-vaaman2.dts | 547 ++++++++++++++++++
3 files changed, 553 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-vaaman2.dts
--
2.47.3
^ permalink raw reply
* [PATCH] Documentation: parport-lowlevel: Fix curly bracket
From: Manuel Ebner @ 2026-06-27 9:24 UTC (permalink / raw)
To: Sudip Mukherjee, Jonathan Corbet, Shuah Khan, Andreas Faerber,
Manivannan Sadhasivam, open list:DOCUMENTATION,
moderated list:ARM/ACTIONS SEMI ARCHITECTURE,
moderated list:ARM/ACTIONS SEMI ARCHITECTURE, open list,
Randy Dunlap
Cc: Manuel Ebner
Remove needless '}'
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/driver-api/parport-lowlevel.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/driver-api/parport-lowlevel.rst b/Documentation/driver-api/parport-lowlevel.rst
index a907e279f509..af73741289c9 100644
--- a/Documentation/driver-api/parport-lowlevel.rst
+++ b/Documentation/driver-api/parport-lowlevel.rst
@@ -341,7 +341,6 @@ EXAMPLE
/* Try to detect a device on the port... */
...
}
- }
...
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] clk: rockchip: rk3588: don't disable unused I2S MCLK output gates
From: Ricardo Pardini @ 2026-06-27 7:30 UTC (permalink / raw)
To: Daniele Briguglio, Michael Turquette, Stephen Boyd,
Heiko Stuebner
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
Diederik de Haas, Nicolas Frattaroli
In-Reply-To: <20260624123914.1767374-1-hello@superkali.me>
On 24/06/2026 14:39, Daniele Briguglio wrote:
> No in-tree board references these gates yet. Boards drive the codec
> MCLK through the parent I2S*_8CH_MCLKOUT, and now that the gates are
> managed clocks, clk_disable_unused() turns them off at boot. On a board
> that relied on firmware leaving the output enabled, that cuts the MCLK
> and analog audio stops working.
>
> Mark the four gates CLK_IGNORE_UNUSED so an unreferenced gate keeps the
> state firmware left. A board that wants the kernel to own the gate can
> reference I2S*_8CH_MCLKOUT_TO_IO from DT instead.
>
> Fixes: 02b9b0bb6269 ("clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO")
> Reported-by: Diederik de Haas <diederik@cknow-tech.com>
> Closes: https://lore.kernel.org/linux-rockchip/DJGDSS875DDO.22TYPVYK5X8KZ@cknow-tech.com/
> Tested-by: Diederik de Haas <diederik@cknow-tech.com>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
I've reproduced the failure reported by Diederik on the NanoPC-T6-LTS
(indirect I2S0_8CH_MCLKOUT) without this patch, then with this patch
(which fixes it), and re-tested the R58X-Pro (out-of-tree explicit
I2S0_8CH_MCLKOUT_TO_IO consumer); it all works for me now.
Tested-by: Ricardo Pardini <ricardo@pardini.net> # on R58X-Pro+NanoPC-T6
Thanks,
-- Ricardo
> ---
> drivers/clk/rockchip/clk-rk3588.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c
> index 2ba9976654c..86953f9ffee 100644
> --- a/drivers/clk/rockchip/clk-rk3588.c
> +++ b/drivers/clk/rockchip/clk-rk3588.c
> @@ -895,7 +895,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S2_2CH_MCLKOUT, "i2s2_2ch_mclkout", i2s2_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(30), 2, 1, MFLAGS),
> GATE_GRF(I2S2_2CH_MCLKOUT_TO_IO, "i2s2_2ch_mclkout_to_io", "i2s2_2ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
>
> COMPOSITE(CLK_I2S3_2CH_SRC, "clk_i2s3_2ch_src", gpll_aupll_p, 0,
> RK3588_CLKSEL_CON(30), 8, 1, MFLAGS, 3, 5, DFLAGS,
> @@ -912,7 +912,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S3_2CH_MCLKOUT, "i2s3_2ch_mclkout", i2s3_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(32), 2, 1, MFLAGS),
> GATE_GRF(I2S3_2CH_MCLKOUT_TO_IO, "i2s3_2ch_mclkout_to_io", "i2s3_2ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> GATE(PCLK_ACDCDIG, "pclk_acdcdig", "pclk_audio_root", 0,
> RK3588_CLKGATE_CON(7), 11, GFLAGS),
> GATE(HCLK_I2S0_8CH, "hclk_i2s0_8ch", "hclk_audio_root", 0,
> @@ -942,7 +942,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S0_8CH_MCLKOUT, "i2s0_8ch_mclkout", i2s0_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(28), 2, 2, MFLAGS),
> GATE_GRF(I2S0_8CH_MCLKOUT_TO_IO, "i2s0_8ch_mclkout_to_io", "i2s0_8ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
>
> GATE(HCLK_PDM1, "hclk_pdm1", "hclk_audio_root", 0,
> RK3588_CLKGATE_CON(9), 6, GFLAGS),
> @@ -2229,7 +2229,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S1_8CH_MCLKOUT, "i2s1_8ch_mclkout", i2s1_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_PMU_CLKSEL_CON(9), 2, 2, MFLAGS),
> GATE_GRF(I2S1_8CH_MCLKOUT_TO_IO, "i2s1_8ch_mclkout_to_io", "i2s1_8ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> GATE(PCLK_PMU1, "pclk_pmu1", "pclk_pmu0_root", CLK_IS_CRITICAL,
> RK3588_PMU_CLKGATE_CON(1), 0, GFLAGS),
> GATE(CLK_DDR_FAIL_SAFE, "clk_ddr_fail_safe", "clk_pmu0", CLK_IGNORE_UNUSED,
>
> base-commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8
^ permalink raw reply
* [PATCH 2/2] media: meson: vdec: guard against NULL prev_frame in codec_vp9_set_mpred_mv()
From: Doruk Tan Ozturk @ 2026-06-27 6:55 UTC (permalink / raw)
To: Neil Armstrong, Greg Kroah-Hartman
Cc: Dan Carpenter, Mauro Carvalho Chehab, Hans Verkuil, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-media, linux-amlogic,
linux-staging, linux-arm-kernel, linux-kernel, Doruk Tan Ozturk
In-Reply-To: <20260627065534.88527-1-doruk@0sec.ai>
codec_vp9_set_mpred_mv() dereferences vp9->prev_frame unconditionally,
both when computing use_prev_frame_mvs (prev_frame->width, ->height,
->intra_only, ->show, ->type) and when programming the previous-frame
MV read registers via codec_vp9_get_frame_mv_paddr(vp9, vp9->prev_frame)
(HEVC_MPRED_MV_RD_START_ADDR, HEVC_MPRED_MV_RPTR and the RD_END_ADDR
computation).
vp9->prev_frame is only assigned (= vp9->cur_frame) after a frame has
been processed, and is NULL after allocation and after a flush. The
caller, codec_vp9_process_frame(), reaches codec_vp9_set_mpred_mv()
whenever the frame is a non-key, non-intra-only frame, without checking
that a previous frame exists. A stream whose first decoded frame is an
inter frame (malformed/adversarial input, or the first frame after a
drain) therefore triggers a NULL pointer dereference.
Disable previous-frame MV use (clear HEVC_MPRED_CTRL4 BIT(6), which the
function already does up front) and return early when prev_frame is
NULL, before any dereference. There are no previous-frame motion
vectors to consume in that case, so this is the correct behaviour as
well as the safe one.
Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Found by static analysis; not yet runtime-reproduced (Amlogic Meson
hardware required).
Fixes: 00c43088aa68 ("media: meson: vdec: add VP9 decoder support")
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
drivers/staging/media/meson/vdec/codec_vp9.c | 27 +++++++++++++++-----
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
index 5ca27930239f..1df641202687 100644
--- a/drivers/staging/media/meson/vdec/codec_vp9.c
+++ b/drivers/staging/media/meson/vdec/codec_vp9.c
@@ -993,19 +993,32 @@ static void codec_vp9_set_mpred_mv(struct amvdec_core *core,
struct codec_vp9 *vp9)
{
int mpred_mv_rd_end_addr;
- int use_prev_frame_mvs = vp9->prev_frame->width ==
- vp9->cur_frame->width &&
- vp9->prev_frame->height ==
- vp9->cur_frame->height &&
- !vp9->prev_frame->intra_only &&
- vp9->prev_frame->show &&
- vp9->prev_frame->type != KEY_FRAME;
+ int use_prev_frame_mvs;
amvdec_write_dos(core, HEVC_MPRED_CTRL3, 0x24122412);
amvdec_write_dos(core, HEVC_MPRED_ABV_START_ADDR,
vp9->workspace_paddr + MPRED_ABV_OFFSET);
amvdec_clear_dos_bits(core, HEVC_MPRED_CTRL4, BIT(6));
+
+ /*
+ * prev_frame is NULL when an inter frame is the first frame decoded
+ * (e.g. a stream starting on a non-key frame, or the first frame
+ * after a flush). There are no previous-frame motion vectors to use
+ * and every read below would dereference a NULL pointer, so leave
+ * prev-MV use disabled (BIT(6) already cleared) and bail out.
+ */
+ if (!vp9->prev_frame)
+ return;
+
+ use_prev_frame_mvs = vp9->prev_frame->width ==
+ vp9->cur_frame->width &&
+ vp9->prev_frame->height ==
+ vp9->cur_frame->height &&
+ !vp9->prev_frame->intra_only &&
+ vp9->prev_frame->show &&
+ vp9->prev_frame->type != KEY_FRAME;
+
if (use_prev_frame_mvs)
amvdec_write_dos_bits(core, HEVC_MPRED_CTRL4, BIT(6));
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] media: meson: vdec: clear stale prev_frame/cur_frame on flush
From: Doruk Tan Ozturk @ 2026-06-27 6:55 UTC (permalink / raw)
To: Neil Armstrong, Greg Kroah-Hartman
Cc: Dan Carpenter, Mauro Carvalho Chehab, Hans Verkuil, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-media, linux-amlogic,
linux-staging, linux-arm-kernel, linux-kernel, Doruk Tan Ozturk
In-Reply-To: <20260627065534.88527-1-doruk@0sec.ai>
codec_vp9_flush_output() (the .drain callback) walks ref_frames_list
and kfree()s every vp9_frame node, but never clears vp9->prev_frame
or vp9->cur_frame, which alias nodes that were just freed.
If decoding resumes after a flush with an inter (non-key) frame,
codec_vp9_process_frame() calls codec_vp9_set_mpred_mv(), which
dereferences vp9->prev_frame->{width,height,intra_only,show,type}
and feeds vp9->prev_frame to codec_vp9_get_frame_mv_paddr(). With
prev_frame still pointing at freed memory this is a use-after-free.
Clear both cached pointers once the list has been freed so a resumed
decode starts from a clean state.
Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Found by static analysis; not yet runtime-reproduced (Amlogic Meson
hardware required).
Fixes: 00c43088aa68 ("media: meson: vdec: add VP9 decoder support")
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
drivers/staging/media/meson/vdec/codec_vp9.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
index 8e80ecf84193..5ca27930239f 100644
--- a/drivers/staging/media/meson/vdec/codec_vp9.c
+++ b/drivers/staging/media/meson/vdec/codec_vp9.c
@@ -681,6 +681,16 @@ static void codec_vp9_flush_output(struct amvdec_session *sess)
list_del(&tmp->list);
kfree(tmp);
}
+
+ /*
+ * All ref_frames_list nodes have been freed above. Drop the cached
+ * pointers so a decode resuming after the flush (e.g. an inter frame
+ * following a drain) cannot dereference freed vp9_frame memory in
+ * codec_vp9_set_mpred_mv().
+ */
+ vp9->prev_frame = NULL;
+ vp9->cur_frame = NULL;
+
mutex_unlock(&vp9->lock);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] media: meson: vdec: fix two more VP9 reference-frame lifetime bugs
From: Doruk Tan Ozturk @ 2026-06-27 6:55 UTC (permalink / raw)
To: Neil Armstrong, Greg Kroah-Hartman
Cc: Dan Carpenter, Mauro Carvalho Chehab, Hans Verkuil, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-media, linux-amlogic,
linux-staging, linux-arm-kernel, linux-kernel, Doruk Tan Ozturk
While reviewing the earlier VP9 prev_frame use-after-free fix, a
Sashiko AI review of that change surfaced two further reference-frame
lifetime bugs in the same decoder, both rooted in vp9->prev_frame /
vp9->cur_frame not being managed across all decode entry points.
Patch 1 clears the cached prev_frame/cur_frame pointers in the .drain
flush path, which frees every ref_frames_list node but left those two
pointers aliasing freed memory; a decode resuming with an inter frame
would then dereference freed vp9_frame storage in
codec_vp9_set_mpred_mv() (use-after-free).
Patch 2 guards codec_vp9_set_mpred_mv() against vp9->prev_frame being
NULL, which happens when the first decoded frame is an inter frame
(malformed/adversarial input, or the first frame after a flush). The
function dereferences prev_frame unconditionally, both for the
use_prev_frame_mvs computation and for the previous-frame MV read
register programming, so the NULL case is a NULL pointer dereference.
Both issues were found by static analysis and are not yet runtime-
reproduced (Amlogic Meson hardware required).
Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Doruk Tan Ozturk (2):
media: meson: vdec: clear stale prev_frame/cur_frame on flush
media: meson: vdec: guard against NULL prev_frame in
codec_vp9_set_mpred_mv()
drivers/staging/media/meson/vdec/codec_vp9.c | 37 ++++++++++++++++----
1 file changed, 30 insertions(+), 7 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH] drm/sun4i: Remove dependency on DRM simple helpers
From: Jernej Škrabec @ 2026-06-27 6:55 UTC (permalink / raw)
To: Chen-Yu Tsai, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Samuel Holland, Diogo Silva
Cc: dri-devel, linux-arm-kernel, linux-sunxi, linux-kernel,
Diogo Silva
In-Reply-To: <20260623-sun4i_simple-v1-1-fa6696df1fad@gmail.com>
Dne torek, 23. junij 2026 ob 22:34:40 Srednjeevropski poletni čas je Diogo Silva napisal(a):
> Simple KMS helper are deprecated since they only add an intermediate
> layer between drivers and the atomic modesetting.
> This patch removes the dependency on drm simple helpers from sun4i
> DRM drivers.
>
> Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
This doesn't look as useful change. Is this tree-wide attempt? If so, it
should be done in one go in one patch series, coordinated with DRM
maintainers.
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: fail hardware init on soft-reset timeout
From: Jernej Škrabec @ 2026-06-27 6:40 UTC (permalink / raw)
To: Chen-Yu Tsai, Pengpeng Hou
Cc: pengpeng, Samuel Holland, Philipp Zabel, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260625003416.15841-1-pengpeng@iscas.ac.cn>
Dne četrtek, 25. junij 2026 ob 02:34:16 Srednjeevropski poletni čas je Pengpeng Hou napisal(a):
> sunxi_rsb_hw_init() issues a controller soft reset and waits for the reset
> bit to clear, but it ignores readl_poll_timeout()'s return value.
>
> If the controller never leaves reset, probe can continue to publish child
> devices and system resume can report success without a usable RSB
> controller.
>
> Return the timeout error, assert reset again, and disable the clock before
> leaving the hardware-init path.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* [PATCH v2] media: meson: vdec: fix use-after-free of in-use frames in codec_vp9_rm_noshow_frame()
From: Doruk Tan Ozturk @ 2026-06-27 6:39 UTC (permalink / raw)
To: Neil Armstrong, Greg Kroah-Hartman
Cc: Dan Carpenter, Mauro Carvalho Chehab, Hans Verkuil, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-media, linux-amlogic,
linux-staging, linux-arm-kernel, linux-kernel, Doruk Tan Ozturk
codec_vp9_rm_noshow_frame() frees the first non-shown reference frame on
ref_frames_list without excluding frames that are still in use. When the
previously decoded frame was a non-show (alt-ref) frame and the current
frame is a non-show inter frame, the freed object is the one
vp9->prev_frame still points to; codec_vp9_set_mpred_mv() then
dereferences the stale pointer (use_prev_frame_mvs and
codec_vp9_get_frame_mv_paddr()), a use-after-free. Freeing a frame that
is still an active reference (codec_vp9_is_ref()) or the current frame
has the same in-use-then-free shape and additionally desyncs the
reference bookkeeping in codec_vp9_sync_ref().
The sibling cleanup codec_vp9_show_frame() already guards exactly these
cases before freeing:
if (codec_vp9_is_ref(vp9, tmp) || tmp == vp9->prev_frame)
continue;
rm_noshow_frame() simply omits the same check. Add it, also skipping
cur_frame, so both cleanup paths agree on which frames are safe to free.
The fields that drive this path (show_frame, frame_type, intra_only) are
parsed from the VP9 bitstream, so a crafted stream fed to the stateless
decoder can trigger the free-then-use.
Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Found by static analysis; not yet runtime-reproduced (Amlogic Meson
hardware required).
Fixes: 00c43088aa68 ("media: meson: vdec: add VP9 decoder support")
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
v2: Per Dan Carpenter's review, also skip active reference frames
(codec_vp9_is_ref()) and cur_frame, matching codec_vp9_show_frame()
exactly — freeing an in-use altref/reference frame here also caused a
codec_vp9_sync_ref() desync, not just the prev_frame UAF.
drivers/staging/media/meson/vdec/codec_vp9.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
index 8e80ecf84193..dad75950933c 100644
--- a/drivers/staging/media/meson/vdec/codec_vp9.c
+++ b/drivers/staging/media/meson/vdec/codec_vp9.c
@@ -1238,6 +1238,8 @@ static void codec_vp9_show_existing_frame(struct codec_vp9 *vp9)
pr_debug("showing frame %u\n", param->p.frame_to_show_idx);
}
+static bool codec_vp9_is_ref(struct codec_vp9 *vp9, struct vp9_frame *frame);
+
static void codec_vp9_rm_noshow_frame(struct amvdec_session *sess)
{
struct codec_vp9 *vp9 = sess->priv;
@@ -1247,6 +1249,18 @@ static void codec_vp9_rm_noshow_frame(struct amvdec_session *sess)
if (tmp->show)
continue;
+ /*
+ * Mirror codec_vp9_show_frame(): never free an active
+ * reference frame, the previously decoded frame, or the
+ * current frame here. prev_frame is still dereferenced by the
+ * MV predictor in codec_vp9_set_mpred_mv(), and freeing an
+ * in-use altref/reference also desyncs codec_vp9_sync_ref();
+ * either is a use-after-free of an in-use frame.
+ */
+ if (codec_vp9_is_ref(vp9, tmp) || tmp == vp9->prev_frame ||
+ tmp == vp9->cur_frame)
+ continue;
+
pr_debug("rm noshow: %u\n", tmp->index);
v4l2_m2m_buf_queue(sess->m2m_ctx, tmp->vbuf);
list_del(&tmp->list);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] media: cedrus: fix memory leak in cedrus_init_ctrls()
From: Jernej Škrabec @ 2026-06-27 6:38 UTC (permalink / raw)
To: mripard, Dawei Feng
Cc: paulk, mchehab, gregkh, wens, samuel, hverkuil, linux-media,
linux-staging, linux-arm-kernel, linux-sunxi, linux-kernel,
jianhao.xu, zilin, Dawei Feng, stable
In-Reply-To: <20260624085920.578446-1-dawei.feng@seu.edu.cn>
Dne sreda, 24. junij 2026 ob 10:59:20 Srednjeevropski poletni čas je Dawei Feng napisal(a):
> In cedrus_init_ctrls(), the V4L2 control handler is initialized before
> allocating memory for ctx->ctrls. If this allocation fails, the function
> returns -ENOMEM without freeing the previously allocated handler
> resources, leading to a memory leak.
>
> Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation
> failure path.
>
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available. Manual inspection confirms that the bug is still
> present in v7.1.1.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have an
> Allwinner SoC or board with a Cedrus VPU available to test with, no
> runtime testing was able to be performed.
>
> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH] drm/sun4i: mixer: Check clock enable failures
From: Jernej Škrabec @ 2026-06-27 6:36 UTC (permalink / raw)
To: Chen-Yu Tsai, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Samuel Holland, dri-devel,
Pengpeng Hou
Cc: linux-arm-kernel, linux-sunxi, linux-kernel, Pengpeng Hou
In-Reply-To: <20260624055123.26769-1-pengpeng@iscas.ac.cn>
Dne sreda, 24. junij 2026 ob 07:51:23 Srednjeevropski poletni čas je Pengpeng Hou napisal(a):
> sun8i_mixer_bind() acquires the required bus and module clocks, but
> ignores clk_prepare_enable() failures before adding the mixer engine to
> the DRM pipeline.
>
> Check both clock enable operations and use the existing unwind labels
> when a required clock cannot be enabled.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* [PATCH v1] ARM: dts: aspeed: g6: Use KCS AST2600 compatible string
From: Haiyue Wang @ 2026-06-27 5:27 UTC (permalink / raw)
To: devicetree, Andrew Jeffery
Cc: Haiyue Wang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, moderated list:ARM/ASPEED MACHINE SUPPORT,
moderated list:ARM/ASPEED MACHINE SUPPORT, open list
As the commit 2596f6b93a60 ("ipmi: kcs: aspeed: Add AST2600 compatible
string") does, change the AST2600 DTS file to use kcs ast2600 compatible
string.
Signed-off-by: Haiyue Wang <haiyuewa@163.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 56bb3b0444f7..774d5af495fb 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -585,7 +585,7 @@ lpc: lpc@1e789000 {
ranges = <0x0 0x1e789000 0x1000>;
kcs1: kcs@24 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
+ compatible = "aspeed,ast2600-kcs-bmc";
reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
@@ -594,7 +594,7 @@ kcs1: kcs@24 {
};
kcs2: kcs@28 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
+ compatible = "aspeed,ast2600-kcs-bmc";
reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
@@ -602,7 +602,7 @@ kcs2: kcs@28 {
};
kcs3: kcs@2c {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
+ compatible = "aspeed,ast2600-kcs-bmc";
reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
@@ -610,7 +610,7 @@ kcs3: kcs@2c {
};
kcs4: kcs@114 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
+ compatible = "aspeed,ast2600-kcs-bmc";
reg = <0x114 0x1>, <0x118 0x1>, <0x11c 0x1>;
interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
--
2.54.0
^ permalink raw reply related
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