On Thu, Jun 04, 2026 at 10:29:19AM -0500, Andrew Jones wrote: > 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.
On the dt front, our policy is that it is not the kernel's job to check that the dt matches the hardware. It is the firmware's job to accurately report what the hardware is. There's definitely some exceptions to that already (*cough thead vector cough*) but that's in part because we failed to come up with concrete descriptions in the first place. Yesterday I commented on a patch that was adding this kind of thing: | The point of validate callbacks is twofold: checking that the kernel | configuration supports the extension and that extensions that the kernel | depends on to support the one in question are present. The latter is because you could depend on an extension that is affected by the former. Looking at the list of validate callbacks, I think there are some that actually don't follow this policy (I saw riscv_ext_zca_depends() that has no real purpose, but didn't look much further). I'm not even sure that the validate callback added in this series for zic64b should be added, it's borderline for me. I'm only really not objecting to it because it outputs a warning if someone has the retroactively added extension without the relevant dt/acpi properties and expects things to work. > 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? Part of me wants to know why we should be going to a bunch of effort to cover up for inaccurate devicetrees etc. Garbage in -> garbage out and let them keep the pieces. That said, if we were to do something with checks, we can't actually even check everything and my opinion is that either we certify that everything is VerifiedTM or we don't certify at all. Cheers, Conor.
signature.asc
Description: PGP signature
