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@rivosinc.com Reviewed-by: Conor Dooley conor.dooley@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_vend...
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