[PATCH] riscv: Work to remove kernel dependence on the M-extension

[Pavel Machek]

Hi!

> >>That'd be wonderful, but unfortunately we're trending the other way --
> >>we're at the point where "words in the specification have meaning" is
> >>controversial, so trying to talk about which flavors of the
> >>specification are standard is just meaningless.  I obviously hope that
> >>gets sorted out, as we've clearly been pointed straight off a cliff for
> >>a while now, but LMKL isn't the place to have that discussion.  We've
> >>all seen this before, nobody needs to be convinced this leads to a mess.
> >>
> >>Until we get to the point where "I wrote 'RISC-V' on that potato I found
> >>in my couch" can be conclusively determined not compliant with the spec,
> >>it's just silly to try and talk about what is.
> >
> >I would argue that codifying the required extensions through kernel source
> 
> The problem here isn't the required extensions, it's that vendors can claim
> to implement an extension on hardware that doesn't exhibit any of the
> behavior the specification expresses that systems with those extensions must
> have.  The D1 is a very concrete example of this.

Sounds like someone interested should make a webpage listing available
CPUs that claim RISC-V compatibility but far short of advertised
claims?

I'd like to get RISC-V board to play with sometime soon, and some help
in what board to get would be welcome...

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20220402/49f80ea3/attachment.sig>