[RFC 0/6] Deprecate riscv,isa DT property?
Conor Dooley
conor at kernel.org
Fri May 12 12:40:10 PDT 2023
On Fri, May 12, 2023 at 11:01:09AM -0700, Palmer Dabbelt wrote:
> On Thu, 11 May 2023 15:38:10 PDT (-0700), Conor Dooley wrote:
> > On Thu, May 11, 2023 at 03:34:24PM -0700, Atish Patra wrote:
> > > On Thu, May 11, 2023 at 2:47 PM Conor Dooley <conor at kernel.org> wrote:
> > > > On Thu, May 11, 2023 at 02:27:44PM -0700, Atish Patra wrote:
> >
> > > > That's more than last year at this point, and nothing has changed in the
> > > > documentation! Talk's cheap, ehh?
> > > >
> > >
> > > Yup. I will poke RVI folks to check if it still is the plan or changed !!
> >
> > Sounds good, thanks!
There has been some movement on that front, shall see where it goes
:upsidedown_smile:
> > > We will likely have a vendor specific string parsing logic.
> >
> > Complicating the parsing logic is the exact sort of crap that I want
> > to avoid.
>
> Ya, I think we're reallly overcomplicating things with the ISA strings.
> Let's just deprecate them and move to something that doesn't need all the
> bespoke string parsing.
Versioning aside, although that removes a large part of the motivation,
the interface becomes quite nice:
of_property_present(node, "riscv,isa-extension-zicbom")
That also gives us the ability to define what supported vendor
extensions actually mean in a dt-binding, which to me is a big win in
terms of the aforementioned "wild west".
-------------- 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/20230512/d37e61a0/attachment.sig>
More information about the linux-riscv
mailing list