Received-SPF: pass (google.com: domain of linux-kernel+bounces-85610-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 28 Feb 2024 19:34:58 +0000
From: Conor Dooley <conor@kernel.org>
To: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
 Alex Soo <yuklin.soo@starfivetech.com>,
 Linus Walleij <linus.walleij@linaro.org>,
 Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
 Hal Feng <hal.feng@starfivetech.com>,
 Ley Foon Tan <leyfoon.tan@starfivetech.com>,
 Jianlong Huang <jianlong.huang@starfivetech.com>,
 Emil Renner Berthing <kernel@esmil.dk>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
 Conor Dooley <conor+dt@kernel.org>, Drew Fustini <drew@beagleboard.org>,
 linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
 devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
 Paul Walmsley <paul.walmsley@sifive.com>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>
Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH_v2_1/6=5D_dt-bindings=3A_?= =?US-ASCII?Q?pinctrl=3A_starfive=3A_Add_JH8100_pinctrl?=
User-Agent: K-9 Mail for Android
In-Reply-To: <20240228170338.GA239206-robh@kernel.org>
References: <20240220064246.467216-1-yuklin.soo@starfivetech.com> <20240220064246.467216-2-yuklin.soo@starfivetech.com> <1a11cee2-2ef1-4ce0-8cc1-63c6cc97863f@linaro.org> <20240220-bottling-reverence-e0ee08f48ccc@spud> <cafccf8d-b8f7-44cb-bc41-3c7a908fd1e4@linaro.org> <20240223002443.GA3877354-robh@kernel.org> <caea26e2-6598-4796-b199-4ee5b1b9cd30@linaro.org> <20240224-smudgy-eldercare-d5d8640d9961@spud> <20240228170338.GA239206-robh@kernel.org>
Message-ID: <6CB89570-8BBE-4323-AB75-4D0582AD1058@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 28 February 2024 17:03:38 GMT, Rob Herring <robh@kernel=2Eorg> wrote:
>On Sat, Feb 24, 2024 at 07:20:30PM +0000, Conor Dooley wrote:
>> On Sat, Feb 24, 2024 at 09:46:53AM +0100, Krzysztof Kozlowski wrote:
>> > > I would like a solution though=2E The only idea I have is passing=
=20
>> > > SystemReady cert, but that's an Arm thing=2E
>>=20
>> I don't know jack about SystemReady
>
>AIUI, Risc-V is working on something similar=2E=2E=2E=20

Probably, but there's a few other things they need to ratify first w=2Er=
=2Et=2E booting before they're at the point of implementing something like =
SR=2E
They still seem to think they need to invent their own discovery mechanism=
, so my hopes aren't super high for what they produce=2E

>
>The primary intent of it is to enable installing off-the-shelf OSs=2E
>
>> - I had it in my head that it was a
>> system level certification=2E I am wondering how you think that
>> SystemReady certification would apply to a whole binding (I can see it
>> being a per-compatible thing, but that would be a mess I am sure)=2E
>
>There's a lot of pieces, but I'll stick to the DT aspects (which is=20
>SystemReady IR band)=2E Certification applies to a specific firmware buil=
d=20
>(which includes the DTB) on a specific board=2E The testing requirements=
=20
>at the moment (for 2=2Ex) are every binding (compatible) must have a=20
>schema, but warnings are allowed=2E=20
>
>So a "stable" tag would apply to a DTS as a whole=2E That of course=20
>implies that everything within the DTS is stable too=2E=20

Right, so it would be on a per-compatible basis then=2E I guess not altoge=
ther different from marking a compatible deprecated=2E

>One wrinkle is that SR has no direct requirement that the DTB come from=
=20
>anything upstream=2E Indirectly, the schemas must exist and be upstream=
=20
>(or acked on the lists) and various distro kernels have to actually=20
>boot=2E For that reason, if we had some tag, it would have to be=20
>distinct from SR=2E

And for the reason that other architectures may want to use it I suppose!