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 <charlie@xxxxxxxxxxxx> >>> Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> >>> --- >>> 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-9a43f1fdcbb9@xxxxxxxxxxxx/ > > 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. Regards, Samuel