Date: Mon, 1 Jul 2024 11:11:55 -0500
From: Samuel Holland <samuel.holland@...ive.com>
To: Conor Dooley <conor@...nel.org>, Charlie Jenkins <charlie@...osinc.com>
Cc: linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-sunxi@...ts.linux.dev,
 linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
 Conor Dooley <conor.dooley@...rochip.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Jisheng Zhang <jszhang@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
 Jernej Skrabec <jernej.skrabec@...il.com>,
 Samuel Holland <samuel@...lland.org>, Jonathan Corbet <corbet@....net>,
 Shuah Khan <shuah@...nel.org>, Guo Ren <guoren@...nel.org>,
 Evan Green <evan@...osinc.com>, Andy Chiu <andy.chiu@...ive.com>,
 Jessica Clarke <jrtc27@...c27.com>, peterlin@...estech.com
Subject: Re: [PATCH v3 03/13] riscv: dts: allwinner: Add xtheadvector to the
 D1/D1s devicetree

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@...osinc.com>
>>> Reviewed-by: Conor Dooley <conor.dooley@...rochip.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-9a43f1fdcbb9@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.

Regards,
Samuel

Powered by blists - more mailing lists