[PATCH] Documentation: RISC-V: Define Xlinuxs{s,m}aia

[Conor Dooley]

On Wed, Feb 08, 2023 at 07:52:06AM -0800, Palmer Dabbelt wrote:
> On Thu, 02 Feb 2023 23:32:47 PST (-0800), Conor Dooley wrote:
> > 
> > 
> > On 3 February 2023 00:12:01 GMT, Palmer Dabbelt <palmer at rivosinc.com> wrote:
> > > The AIA specification was only partially frozen, but provides no way to
> > > refer to the subset of behavior that has been frozen.
> > 
> > Ahh, wonderful.
> > 
> > > It seems like
> > > there's not a whole lot of interest in the non-frozen behavior, so let's
> > > just define an extension that only consists of the frozen behavior
> > 
> > > 
> > > Signed-off-by: Palmer Dabbelt <palmer at rivosinc.com>
> > > ---
> > > Documentation/riscv/extensions.rst | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > > create mode 100644 Documentation/riscv/extensions.rst
> > > 
> > > diff --git a/Documentation/riscv/extensions.rst b/Documentation/riscv/extensions.rst
> > > new file mode 100644
> > > index 000000000000..c12bd3780520
> > > --- /dev/null
> > > +++ b/Documentation/riscv/extensions.rst
> > > @@ -0,0 +1,10 @@
> > > +.. SPDX-License-Identifier: GPL-2.0
> > > +
> > > +Custom RISC-V Extensions
> > > +========================
> > > +
> > > +* The `Xlinuxsmaia` and `Xlinuxssaia` extensions coorespond to the standard
> > 
> > Typo: correspond
> > 
> > > +  `Smaia` and `Ssaia` extensions as defined by version 1.0-RC2 of the RISC-V
> > > +  Advanced Interrupt Architecture (AIA) specification, with the difference that
> > > +  chapters 5 (Duo-PLIC) and 9 (IOMMU Support for MSIs to Virtual Machines) do
> > > +  not exist.
> > 
> > Perhaps this document needs an intro section specifying what you expect to go in it.
> > Is this for any custom stuff, or just places where Linux has to work around RVI?
> 
> > From talking on the patchwork call, it sounds like 1.0.0-rc2 may not be
> what's going to be ratified.  If the plan really is to remove the draft
> chapters when the spec is ratified, which does sometimes happen, then those
> might just solve the problem -- but sometimes things marked as drafts get
> ratified, so we really just have no idea what the spec is going to be.  It's
> going to be pretty much imposible to get everyone on the same page until we
> can see the spec that's going to be ratified.  So I think until that gets
> sorted out, there's not really a whole lot more we can do here.
> 
> The other option would be to just properly commit to moving away from ISA
> strings in the DT interface.  We've sort of soft-forked already, but we're
> at least trying to keep things looking similar.  Properly forking would
> really make everyone happy, as we'd no longer need to worry about the specs
> getting the details right.

So reading between the lines (based on that patchwork call), this is a
self-NAK for this patch and a NAK for adding the regular variants of
these extensions to the ISA string in the first place.
Perhaps it'd be worth noting that on [1] where the CC list is both
broader and more specific? (Apologies if you already indended doing so
there & I'm just preempting you).

Thanks,
Conor.

1 - https://lore.kernel.org/linux-riscv/CAK9=C2XAaB0GXh1tO060dWxZR2pSAVJhejUaa+W=Q+9nk_gYKA@mail.gmail.com/T/#ma126fa3fcd97af944a659ad544753020fac7b89d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230208/5b85aa30/attachment.sig>