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

[Bo Gan <ganboing@gmail.com>]

On 3/14/26 05:17, Conor Dooley wrote:
> 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).

Got your point. I've moved away from DT and "extension" in v2 and made
it a sifive "errata", given that mapping memory twice through front/sys
port is more of a sifive concept, not something generic to other core
vendors. The DT is kept untouched, and the detection logic is done by
a LUT and sbi ecalls if not predefined. Link:

https://lore.kernel.org/linux-riscv/20260316060328.1173634-1-ganboing@gmail.com

Bo