[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