Received-SPF: pass (google.com: domain of linux-kernel+bounces-90399-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 4 Mar 2024 10:11:45 +0000
From: Conor Dooley <conor.dooley@microchip.com>
To: Yangyu Chen <cyy@cyyself.name>
CC: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	<linux-riscv@lists.infradead.org>, Conor Dooley <conor@kernel.org>, Rob
 Herring <robh+dt@kernel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@linaro.org>, Paul Walmsley
	<paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/5] dt-bindings: add Canaan K230 boards compatible
 strings
Message-ID: <20240304-wharf-safely-8167b9641821@wendy>
References: <tencent_E15F8FE0B6769E6338AE690C7F4844A31706@qq.com>
 <tencent_D5188EA5B85A31AC21588DBD7C7482ACDA08@qq.com>
 <7c3c578a-d662-4485-ad15-47250ad0e935@linaro.org>
 <tencent_BF607C338244DA7F8EB2B8F2314A218B8D08@qq.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="sMeZDBbqBAeg1clN"
Content-Disposition: inline
In-Reply-To: <tencent_BF607C338244DA7F8EB2B8F2314A218B8D08@qq.com>

--sMeZDBbqBAeg1clN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 Kendry=
te
> > > 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 i=
n the
> > > dt.
> > >=20
> > > Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> > > ---
> > >   Documentation/devicetree/bindings/riscv/canaan.yaml | 13 ++++++++++=
++-
> > >   1 file changed, 12 insertions(+), 1 deletion(-)
> > >=20
> > > diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Do=
cumentation/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
> >=20
> > Why this is not part of previous entry in an enum?
> >=20
> > > +          - const: canaan,kendryte-k230
> > > +
> > > +      - items:
> > > +          - const: canaan,kendryte-k230
> >=20
> > Usually you cannot run SoCs alone. What does it represent (in real life=
)?
> >=20
>=20
> 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 altho=
ugh
> 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
=66rom 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-compatib=
le
> 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.

--sMeZDBbqBAeg1clN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZeWeYQAKCRB4tDGHoIJi
0l7sAP47uOhYd1DCwmJBkxO8TaMhAQS5Yf1og9jIrnGIqxlXVgD/Y4GmbTvJfOfh
M8suFJ9UmnJ3S0rikA5KJgnrXlJZ7gA=
=TfqN
-----END PGP SIGNATURE-----

--sMeZDBbqBAeg1clN--