linux-kernel - Re: [PATCH 2/5] dt-bindings: add Canaan K230 boards compatible strings

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 4 Mar 2024 11:27:19 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Yangyu Chen <cyy@...self.name>, linux-riscv@...ts.infradead.org
Cc: Conor Dooley <conor@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Guo Ren <guoren@...nel.org>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] dt-bindings: add Canaan K230 boards compatible
 strings

On 04/03/2024 09:51, Yangyu Chen wrote:
> On 2024/3/4 16:11, Krzysztof Kozlowski wrote:
>> On 03/03/2024 14:26, Yangyu Chen wrote:
>>> Since K230 was released, K210 is no longer the only SoC in the Kendryte
>>> series, so remove the K210 string from the description. Also, add two
>>> boards based on k230 to compatible strings to allow them to be used in the
>>> dt.
>>>
>>> Signed-off-by: Yangyu Chen <cyy@...self.name>
>>> ---
>>>   Documentation/devicetree/bindings/riscv/canaan.yaml | 13 ++++++++++++-
>>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
>>> index 41fd11f70a49..444758db964e 100644
>>> --- a/Documentation/devicetree/bindings/riscv/canaan.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
>>> @@ -10,7 +10,7 @@ maintainers:
>>>     - Damien Le Moal <dlemoal@...nel.org>
>>>   
>>>   description:
>>> -  Canaan Kendryte K210 SoC-based boards
>>> +  Canaan Kendryte SoC-based boards
>>>   
>>>   properties:
>>>     $nodename:
>>> @@ -42,6 +42,17 @@ properties:
>>>         - items:
>>>             - const: canaan,kendryte-k210
>>>   
>>> +      - items:
>>> +          - const: canaan,k230-usip-lp3-evb
>>> +          - const: canaan,kendryte-k230
>>> +
>>> +      - items:
>>> +          - const: canaan,canmv-k230
>>
>> Why this is not part of previous entry in an enum?
>>
>>> +          - const: canaan,kendryte-k230
>>> +
>>> +      - items:
>>> +          - const: canaan,kendryte-k230
>>
>> Usually you cannot run SoCs alone. What does it represent (in real life)?
>>
> 
> I'm not sure what it means.
> 
> If you wonder why should I add a compatible string for soc, that is 
> although we cannot run SoCs alone, adding a soc compatible will allow 
> some bootloaders or SBI on RISC-V to choose an errata for a soc. Such as 
> this opensbi patch. [1]

No, this piece of code will not allow this. They choose errata
regardless of this change.

> 
> If you wonder why I should allow a soc-compatible string with soc alone, 
> that is because k210 did it previously. And provide a k210_generic.dts 

I don't remember background behind k210_generic. Any SoC-compatible
alone is exception, so needs serious justification. Drop it or provide
proper rationale.

> to use it. I haven't provided generic dts now but allowing only 
> soc-compatible string alone would also be acceptable I think.

No, it is not. Stop making own rules.


Best regards,
Krzysztof