On Sat, May 30, 2026 at 08:42:29AM +0800, Guodong Xu wrote: > On Thu, May 28, 2026 at 12:35 AM Andrew Jones > > Sashiko points out a few things about this patch which I think I > > agree with > > > > https://sashiko.dev/#/patchset/20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc%40riscstar.com?part=8 > > Quote the following from Sashiko.dev: > > Should this mask specify the individual subset extensions required by the > > profile instead of the superset extensions like RISCV_ISA_EXT_B, > > RISCV_ISA_EXT_C, and RISCV_ISA_EXT_V? > > My preference is to leave the mask on B/C/V (and A) as-is. I'd prefer to > keep matching on the single-letter, rather than expanding them. Here is why: > > - The RVA23 profile lists A, B, C and V as single-letter mandatory > extensions; it doesn't enumerate Zaamo/Zalrsc, Zba/Zbb/Zbs, Zc* or the > Zve*/Zvl* subsets in the mandatory set. > > - In current merged code, hwprobe_isa_ext0() is already using > riscv_isa_extension_available() signle letter checking for C and V. > > PS: > B maybe a special one, just in case anybody raise it. As the community > discussed when I adding it into the bindings, because B comes later than > its sub-components zba/zbb/zbs, so, when I added B, I cleaned up all > in-tree dts files which declared zba/zbb/zbs but not B and made them declare > both. > > Link: > https://lore.kernel.org/linux-riscv/[email protected]/ > [1] > > Also, in the bindings: extensions.yaml, a schema rule is added which requires > a node listing zba, zbb and zbs to also list b (and the reverse). Moving on, > new dtsi/dts fils, a node with only the subsets fails dtbs_check. > > One may argue that the schema check doesn't cover ACPI path. But again, > shouldn't the vendor who publishs RVA23 hardware be conformant to the > extensions wording in RVA23 v1.0 spec? > > What do you think? >
I certainly see a case for the kernel staying out of the extension dependency validation game. I think it makes sense for an ISA string validation tool to exist for vendors to do sanity checks on their ISA strings, but that's not the kernel's role. OTOH, whether or not the kernel wants to try and detect inconsistencies with the ISA string in order to build confidence in using what it sees there and publishing what it sees there to usermode, through hwprobe, might still be worth debating. Without CPUID / ID_* registers for Linux to be able to check an authoritative source of truth about what is and isn't supported by the CPU, riscv Linux has to decide to either blindly trust the hardware description or do sanity checks / probes in order to confirm what it sees there. Maybe we can assume that any extension used by the kernel will trip over itself quickly, alerting vendors to fix their ISA strings, but I'm not sure we can make that assumption for usermode extensions that Linux doesn't use, but does expose through hwprobe. What apps need to run in testing to exercise them? How long will those apps need to run before they trip over something? The more I think I about it, the more I think the lack of CPUID / ID_* registers puts Linux in a tight spot. If Linux trustingly publishes what firmware tells it to to userspace and userspace blows up, Linux will have to share some of the blame for having misled it. So, should Linux validate everything it publishes somehow? Or, should it at least do relatively cheap sanity checks on everything it publishes in order to build some confidence? Thanks, drew
