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@xxxxxxxxxxxx>
---
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@xxxxxxxxxx>
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]
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
to use it. I haven't provided generic dts now but allowing only
soc-compatible string alone would also be acceptable I think.
[1]
https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031a9399354
Thanks,
Yangyu Chen
Best regards,
Krzysztof
