Hi Atish, Am Samstag, 8. Januar 2022, 03:24:12 CET schrieb Atish Patra: > On Fri, Jan 7, 2022 at 1:58 PM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: > > > > On Fri, 24 Dec 2021 13:16:30 PST (-0800), atishp@xxxxxxxxxxxxxx wrote: > > > This series implements a generic framework to parse multi-letter ISA > > > extensions. It introduces a new DT node that can be under /cpus or > > > individual cpu depends on the platforms with homogeneous or heterogeneous > > > harts. This version of the series only allows adds support for homogeneous > > > harts as there are no platforms with heterogeneous harts yet. However, > > > the DT binding allows both. > > > > > > The patch also indicates the user space about the available ISA extensions > > > via /proc/cpuinfo. > > > > > > Here is the example output of /proc/cpuinfo: > > > (with debug patches in Qemu and Linux kernel) > > > > > > / # cat /proc/cpuinfo > > > processor : 0 > > > hart : 0 > > > isa : rv64imafdcsu > > > isa-ext : sstc,sscofpmf > > > mmu : sv48 > > > > IMO this is the wrong way to go. I get that the ISA string is very > > complicated to parse, but we've tried to come up with other > > representations of this we've ended up having that interface break when > > the ISA string rules eventually change. We should just stick to the ISA > > string for these interfaces, as that's at least something everyone can > > agree on because they're defined by the spec. > > > > Fair enough. > > > That said, we should add the spec versions into this interface. At > > least the user spec version is relevant here, but given that we're > > passing through some other priv-level details we might as well pass that > > though too. > > > > Tsukasa already has a version that extends the isa string parsing for > multi-letter extensions > and versions parsing. We just need to add the ISA bitmap support on top of it. > > I will coordinate with Tsukasa to have a complete framework based on > string parsing. > It would be good to have this series asap as all other series (perf, > svpbmt) will rely on it. out of curiosity, did this go anywhere yet in terms of the coordinated approach you wrote about? Thanks Heiko