Hi Conor, On Mon, Jul 01, 2024 at 05:31:01PM +0100, Conor Dooley wrote: > [EXTERNAL MAIL]
> Date: Mon, 1 Jul 2024 17:31:01 +0100 > From: Conor Dooley <co...@kernel.org> > To: Samuel Holland <samuel.holl...@sifive.com> > Cc: Charlie Jenkins <char...@rivosinc.com>, > linux-ri...@lists.infradead.org, devicet...@vger.kernel.org, > linux-ker...@vger.kernel.org, linux-su...@lists.linux.dev, > linux-...@vger.kernel.org, linux-kselftest@vger.kernel.org, Conor Dooley > <conor.doo...@microchip.com>, Rob Herring <r...@kernel.org>, Krzysztof > Kozlowski <krzk...@kernel.org>, Paul Walmsley <paul.walms...@sifive.com>, > Palmer Dabbelt <pal...@dabbelt.com>, Albert Ou <a...@eecs.berkeley.edu>, > Jisheng Zhang <jszh...@kernel.org>, Chen-Yu Tsai <w...@csie.org>, Jernej > Skrabec <jernej.skra...@gmail.com>, Samuel Holland <sam...@sholland.org>, > Jonathan Corbet <cor...@lwn.net>, Shuah Khan <sh...@kernel.org>, Guo Ren > <guo...@kernel.org>, Evan Green <e...@rivosinc.com>, Andy Chiu > <andy.c...@sifive.com>, Jessica Clarke <jrt...@jrtc27.com>, > peter...@andestech.com > Subject: Re: [PATCH v3 03/13] riscv: dts: allwinner: Add xtheadvector to > the D1/D1s devicetree > > On Mon, Jul 01, 2024 at 11:11:55AM -0500, Samuel Holland wrote: > > Hi Conor, Charlie, > > > > On 2024-07-01 11:07 AM, Conor Dooley wrote: > > > On Mon, Jul 01, 2024 at 10:27:01AM -0500, Samuel Holland wrote: > > >> On 2024-06-19 6:57 PM, Charlie Jenkins wrote: > > >>> The D1/D1s SoCs support xtheadvector so it can be included in the > > >>> devicetree. Also include vlenb for the cpu. > > >>> > > >>> Signed-off-by: Charlie Jenkins <char...@rivosinc.com> > > >>> Reviewed-by: Conor Dooley <conor.doo...@microchip.com> > > >>> --- > > >>> arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 3 ++- > > >> > > >> The other C906/C910/C920-based SoCs need devicetree updates as well, > > >> although > > >> they don't necessarily need to be part of this series: > > >> > > >> - sophgo/cv18xx.dtsi > > >> - sophgo/sg2042-cpus.dtsi > > >> - thead/th1520.dtsi > > > > > > Yeah, I think I pointed that out before with the same "escape hatch" of > > > it not needing to be in the same series. > > > > > >> > > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > > >>> > > >>> diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi > > >>> b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi > > >>> index 64c3c2e6cbe0..6367112e614a 100644 > > >>> --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi > > >>> +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi > > >>> @@ -27,7 +27,8 @@ cpu0: cpu@0 { > > >>> riscv,isa = "rv64imafdc"; > > >> > > >> The ISA string should be updated to keep it in sync with > > >> riscv,isa-extensions. > > > > > > This probably looks like this cos I said that the kernel shouldn't parse > > > vendor extensions from "riscv,isa". My rationale was that we have > > > basically no control of what a vendor extension means in riscv,isa so > > > we shouldn't parse them from it (so marginally worse than standard > > > extensions, where it means what the spec says except when it doesn't). > > > > > > Given how we implement the parsing, it also meant we weren't implying > > > meanings for vendor extensions ACPI-land, where we also can't ensure the > > > meanings or that they remain stable. That change is in a different > > > series: > > > https://patchwork.kernel.org/project/linux-riscv/patch/20240609-support_vendor_extensions-v2-1-9a43f1fdc...@rivosinc.com/ > > > > > > Although now that I think about it, this might break xandespmu... I > > > dunno if the Andes guys switched over to using the new property outside > > > of the single dts in the kernel tree using their SoC. We could > > > potentially special-case that extension if they haven't - but my > > > position on this mostly is that if you want to use vendor extensions you > > > should not be using riscv,isa (even if the regex doesn't complain if you > > > add them). I'd like to leave the code in the other patch as-is if we can > > > help it. > > > > > > I added Yu Chien Peter Lin here, maybe they can let us know what they're > > > doing. > > > > OK, that makes sense to me. Then please ignore my original comment. > > Should the xandespmu thing be an issue, I'd suggest we just do something > like the following, in place of the new switch arm added by Charlie: > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index ec4bff7a827c..bb99b4055ec2 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -628,6 +628,17 @@ static void __init riscv_parse_isa_string(const char > *isa, unsigned long *bitmap > if (unlikely(ext_err)) > continue; > > + if (*ext == 'x' && acpi_disabled) { > + /* > + * xandespmu predates this "rule", so special case it > for > + * hysterical raisins > + */ > + if (strncasecmp(ext, "xandespmu", ext_end - ext)) { > + pr_warn_once("Vendor extensions are ignored in > riscv,isa. Use riscv,isa-extensions instead."); > + break; > + } > + } > + > match_isa_ext(ext, ext_end, bitmap); > } > } > Thanks for the hands-up! We don't use the deprecated riscv,isa to specify xandespmu, so no need to address this special case. Regards, Peter Lin