linux-kernel - Re: [RFC PATCH v2 1/6] dt-bindings: pinctrl: starfive: Add JH8100 pinctrl

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]

Message-ID: <6CB89570-8BBE-4323-AB75-4D0582AD1058@kernel.org>
Date: Wed, 28 Feb 2024 19:34:58 +0000
From: Conor Dooley <conor@...nel.org>
To: Rob Herring <robh@...nel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Alex Soo <yuklin.soo@...rfivetech.com>,
 Linus Walleij <linus.walleij@...aro.org>,
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
 Hal Feng <hal.feng@...rfivetech.com>,
 Ley Foon Tan <leyfoon.tan@...rfivetech.com>,
 Jianlong Huang <jianlong.huang@...rfivetech.com>,
 Emil Renner Berthing <kernel@...il.dk>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Drew Fustini <drew@...gleboard.org>,
 linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
 Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>
Subject: Re: [RFC PATCH v2 1/6] dt-bindings: pinctrl: starfive: Add JH8100 pinctrl



On 28 February 2024 17:03:38 GMT, Rob Herring <robh@...nel.org> 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. The only idea I have is passing 
>> > > SystemReady cert, but that's an Arm thing.
>> 
>> I don't know jack about SystemReady
>
>AIUI, Risc-V is working on something similar... 

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

>
>The primary intent of it is to enable installing off-the-shelf OSs.
>
>> - I had it in my head that it was a
>> system level certification. 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).
>
>There's a lot of pieces, but I'll stick to the DT aspects (which is 
>SystemReady IR band). Certification applies to a specific firmware build 
>(which includes the DTB) on a specific board. The testing requirements 
>at the moment (for 2.x) are every binding (compatible) must have a 
>schema, but warnings are allowed. 
>
>So a "stable" tag would apply to a DTS as a whole. That of course 
>implies that everything within the DTS is stable too. 

Right, so it would be on a per-compatible basis then. I guess not altogether different from marking a compatible deprecated.

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

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