| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <f9b6b5e2-ec9e-4208-8267-77020e0a9411@canonical.com>
Date: Wed, 17 Dec 2025 09:07:14 +0100
From: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
To: Guodong Xu <guodong@...cstar.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...ive.com>, Conor Dooley <conor@...nel.org>,
Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>,
devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, spacemit@...ts.linux.dev,
linux-serial@...r.kernel.org, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Paul Walmsley <pjw@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Alexandre Ghiti <alex@...ti.fr>, Yixun Lan <dlan@...too.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Samuel Holland <samuel.holland@...ive.com>, Anup Patel
<anup@...infault.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>, Lubomir Rintel <lkundrak@...sk>,
Yangyu Chen <cyy@...self.name>
Subject: Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of
SpacemiT K3 SoC
On 12/17/25 08:11, Guodong Xu wrote:
> On Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
> <heinrich.schuchardt@...onical.com> wrote:
>>
>> On 12/16/25 14:32, Guodong Xu wrote:
>>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
>>> Add nodes of uarts, timer and interrupt-controllers.
>>>
>>> Signed-off-by: Guodong Xu <guodong@...cstar.com>
>>> ---
>>> arch/riscv/boot/dts/spacemit/k3.dtsi | 529 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 529 insertions(+)
>>>
>>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..cb27b790716fdd6dc2bc89c28dd2588a596a5af9
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> @@ -0,0 +1,529 @@
>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>> +/*
>>> + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
>>> + * Copyright (c) 2025 Guodong Xu <guodong@...cstar.com>
>>> + */
>>> +
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +
>>> +/dts-v1/;
>>> +
>>> +/ {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + model = "SpacemiT K3";
>>> + compatible = "spacemit,k3";
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + serial2 = &uart2;
>>> + serial3 = &uart3;
>>> + serial4 = &uart4;
>>> + serial5 = &uart5;
>>> + serial6 = &uart6;
>>> + serial7 = &uart7;
>>> + serial8 = &uart8;
>>> + serial9 = &uart9;
>>> + serial10 = &uart10;
>>> + };
>>> +
>>> + cpus: cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + timebase-frequency = <24000000>;
>>> +
>>> + cpu_0: cpu@0 {
>>> + compatible = "spacemit,x100", "riscv";
>>> + device_type = "cpu";
>>> + reg = <0>;
>>> + riscv,isa-base = "rv64i";
>>> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "h",
>>> + "smaia", "smstateen", "ssaia", "sscofpmf",
>>> + "ssnpm", "sstc", "svade", "svinval", "svnapot",
>>> + "svpbmt", "zawrs", "zba", "zbb", "zbc", "zbs",
>>> + "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
>>> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
>>> + "zicntr", "zicond", "zicsr", "zifencei",
>>> + "zihintntl", "zihintpause", "zihpm", "zimop",
>>> + "zkt", "zvbb", "zvbc", "zvfbfmin", "zvfbfwma",
>>> + "zvfh", "zvfhmin", "zvkb", "zvkg", "zvkn",
>>> + "zvknc", "zvkned", "zvkng", "zvknha",
>>> + "zvknhb", "zvks", "zvksc", "zvksed",
>>> + "zvksg", "zvksh", "zvkt";
>>
>> This not the description of an RVA23S64 cpu. It is not even RVA23U64,
>> e.g. `supm` is missing.
>>
>> Is the description incomplete or is the CPU not compliant?
>
> Hi Heinrich,
>
> The SpacemiT K3 supports the mandatory extensions defined in the RVA23
> Profile (ratified Oct 2024). The list appears incomplete here only because
> I am restricting the entries to those currently supported by the Linux
> kernel Device Tree bindings.
>
> Specifically, I must adhere to
> Documentation/devicetree/bindings/riscv/extensions.yaml (and cpus.yaml for
> properties like 'riscv,sv39' which stands for the extension Sv39). If I
> add extension strings that are not yet defined in these schemas, such as
> supm, running 'make dtbs_check W=3' fails with: 'supm' is not one of
> ['i', 'm', 'a', ...], followed by "Unevaluated properties are not allowed."
If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
with respect to ratified extensions, I guess the right approach is to
amend it and not to curtail the CPU description.
Best regards
Heinrich
>
> Another angle, I found there are other reasons why Linux kernel chose to
> 'omit' some specific extension strings. For example, here are what I noticed
> so far, including the 'supm' you mentioned:
>
> supm: There is no binding string for this yet. However, in the kernel config
> (refer to arch/riscv/Kconfig), RISCV_ISA_SUPM depends on the detection of the
> underlying 'smnpm' or 'ssnpm' hardware extensions. Since 'ssnpm' is
> present in my list, it can be considered as supported and the kernel
> will enable pointer masking support automatically.
>
> Other examples:
> ssstateen: The kernel schema currently uses the smstateen string to
> cover CSR access control in all modes (H/S/VS/U/VU). I have included
> 'smstateen' to satisfy this, as there is no separate 'ssstateen' binding
> in the extensions.yaml.
>
> ziccif: This extension is also absent from the bindings, despite being
> implied by ftrace dynamic code work. Reference:
> https://lore.kernel.org/all/20250407180838.42877-12-andybnac@gmail.com/
> I intend to submit a separate patch series to formally add ziccif to
> extensions.yaml.
>
> Anyway, I have limited the x100 riscv,isa-extensions list to strictly
> validate against the current kernel schema while exposing all features
> the kernel is currently capable of parsing.
>
> I hope this explanation clarifies the situation. Please let me know if you
> agree with this approach.
>
> Best Regards,
> Guodong Xu
>
>>
>> Best regards
>>
>> Heinrich
>>
Powered by blists - more mailing lists