Messages in this thread | | | Date | Thu, 9 May 2024 16:26:24 -0700 | From | Deepak Gupta <> | Subject | Re: [PATCH v3 04/29] riscv: zicfilp / zicfiss in dt-bindings (extensions.yaml) |
| |
On Thu, May 09, 2024 at 09:32:49PM +0100, Conor Dooley wrote: >On Thu, May 09, 2024 at 11:46:26AM -0700, Deepak Gupta wrote: >> On Thu, May 09, 2024 at 07:14:26PM +0100, Conor Dooley wrote: >> > On Tue, Apr 16, 2024 at 08:44:16AM -0700, Deepak Gupta wrote: >> > > On Mon, Apr 15, 2024 at 02:41:05PM -0500, Rob Herring wrote: >> > > > On Wed, Apr 10, 2024 at 02:37:21PM -0700, Deepak Gupta wrote: >> > > > > On Wed, Apr 10, 2024 at 4:58 AM Rob Herring <robh@kernel.org> wrote: >> > > > > > >> > > > > > On Wed, Apr 03, 2024 at 04:34:52PM -0700, Deepak Gupta wrote: >> > > > > > > Make an entry for cfi extensions in extensions.yaml. >> > > > > > > >> > > > > > > Signed-off-by: Deepak Gupta <debug@rivosinc.com> >> > > > > > > --- >> > > > > > > .../devicetree/bindings/riscv/extensions.yaml | 10 ++++++++++ >> > > > > > > 1 file changed, 10 insertions(+) >> > > > > > > >> > > > > > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml >> > > > > > > index 63d81dc895e5..45b87ad6cc1c 100644 >> > > > > > > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml >> > > > > > > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml >> > > > > > > @@ -317,6 +317,16 @@ properties: >> > > > > > > The standard Zicboz extension for cache-block zeroing as ratified >> > > > > > > in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. >> > > > > > > >> > > > > > > + - const: zicfilp >> > > > > > > + description: >> > > > > > > + The standard Zicfilp extension for enforcing forward edge control-flow >> > > > > > > + integrity in commit 3a20dc9 of riscv-cfi and is in public review. >> > > > > > >> > > > > > Does in public review mean the commit sha is going to change? >> > > > > > >> > > > > >> > > > > Less likely. Next step after public review is to gather comments from >> > > > > public review. >> > > > > If something is really pressing and needs to be addressed, then yes >> > > > > this will change. >> > > > > Else this gets ratified as it is. >> > > > >> > > > If the commit sha can change, then it is useless. What's the guarantee >> > > > someone is going to remember to update it if it changes? >> > > >> > > Sorry for late reply. >> > > >> > > I was following existing wordings and patterns for messaging in this file. >> > > You would rather have me remove sha and only mention that spec is in public >> > > review? >> > >> > Nope, having a commit sha is desired. None of this is mergeable until at >> > least the spec becomes frozen, so the sha can be updated at that point >> > to the freeze state - or better yet to the ratified state. Being in >> > public review is not sufficient. >> >> Spec is frozen. >> As per RVI spec lifecycle, spec freeze is a prior step to public review. >> Public review concluded on 25th April >> https://lists.riscv.org/g/tech-ss-lp-cfi/message/91 >> >> Next step is ratification whenever board meets. > >Ah, I did the "silly" thing of looking on the RVI website at extension >status (because I never know the order of things) and these two >extensions were marked on there as being in the inception phase, so I >incorrectly assumed that "public review" came before freeze. >Freeze is the standard that we have been applying so far, but if >ratification is imminent, and nothing has changed in the review period, >then it seems sane to just pick the freeze point for the definition.
Yeah I don't think wiki is that regularly updated. But take a look at Ratification-Ready list of specs here https://wiki.riscv.org/display/HOME/RISC-V+Specification+Status
> >Cheers, >Conor.
| |