| Message ID | tencent_D5188EA5B85A31AC21588DBD7C7482ACDA08@qq.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | riscv: add initial support for Canaan Kendryte K230 | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/vmtest-fixes-PR | fail | merge-conflict |
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@cyyself.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@kernel.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)? Best regards, Krzysztof
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@cyyself.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@kernel.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] 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 >
On Mon, Mar 04, 2024 at 04:51:05PM +0800, 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@cyyself.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@kernel.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. You have a SoC compatible but no board compatible. You cannot run a SoC without some sort of board connected to it, so this should be removed. > 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] You don't need to add an isolated compatible like this to be able to apply that "erratum", the compatible is already documented from the "usip-l3-evb" and "canmv-k230" entries. > If you wonder why I should allow a soc-compatible string with soc alone, > that is because k210 did it previously. The k210 is not really a beacon of quality in the DT department, copying from there is likely to be misleading unfortunately. > 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. To be honest, I would like to delete the generic dts for the k210, I don't think it should exist, at least not in the current form. Thanks, Conor.
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@cyyself.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@kernel.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
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@kernel.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 + - const: canaan,kendryte-k230 + + - items: + - const: canaan,kendryte-k230 + additionalProperties: true ...
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@cyyself.name> --- Documentation/devicetree/bindings/riscv/canaan.yaml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)