[RFC PATCH 1/6] riscv: Add a custom, simplified version of Svpbmt "XPbmtUC"

[Conor Dooley]

On Fri, Mar 13, 2026 at 10:06:42PM -0700, Bo Gan wrote:
> > To be honest, I'm not completely dead-set opposed to a property that has
> > the bit positioning, but any property being added for what is
> > effectively an erratum needs to pass a high bar when the info could be
> > gathered in another way. That the eic7700 one depends on firmware for
> > what the bit may be is points in your favour, since firmware variability
> > is part of what dt is there to do. The jh7110 is points against, since
> > it could be fished out of the errata handling code.
> > 
> Even for JH7110, I don't think it can be handled through the errata. It
> describes the errata of the core (if I'm not mistaken), and there can be
> other SoCs using the same core with the same archid/impid, but maps the
> peripherals differently, and the UC bit position doesn't apply there. I
> think you are probably looking for "SoC level errata" handling. It's not
> there AFAIK. Hence I guess both SoC cases point in favor of the dt prop?

I dunno, nothing wrong with checking the devicetree during the errata
"probe" code. Checks are not limited to imp/arch ids, can do ecalls etc
etc in there too, so looking at the root compatible would be possible.

Either way, if people like what you've done here generally (because
coming up with our own use of PTE bits could be controversial), and a
custom property of some sort is to be used, you need to provide a good
justification of why it is needed in the commit messages because you're
setting a precedent of being the first "extension" conjured up to suit
linux that would need that kind of functionality.
Need to demonstrate that it describes an aspect of the hardware, and
isn't being conjured up to configure software to use one out of several
possible values, that it may even be able to determine heuristically
from information already provided in the devicetree (like the root
compatible or a completely described memory node).
-------------- 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/20260314/29ceb406/attachment.sig>