[v3,03/13] riscv: dts: allwinner: Add xtheadvector to the D1/D1s devicetree

Commit Message

Charlie Jenkins June 19, 2024, 11:57 p.m. UTC

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 <[e-mail]>
Reviewed-by: Conor Dooley <[e-mail]>
---
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Chen-Yu Tsai June 20, 2024, 10:06 a.m. UTC | #1

On Thu, Jun 20, 2024 at 7:57 AM Charlie Jenkins <[e-mail]> 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 <[e-mail]>
> Reviewed-by: Conor Dooley <[e-mail]>

Acked-by: Chen-Yu Tsai <[e-mail]>

If the RISC-V maintainers want to take the whole series.

> ---
>  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 3 ++-
>  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";
>                         riscv,isa-base = "rv64i";
>                         riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -                                              "zifencei", "zihpm";
> +                                              "zifencei", "zihpm", "xtheadvector";
> +                       thead,vlenb = <128>;
>                         #cooling-cells = <2>;
>
>                         cpu0_intc: interrupt-controller {
>
> --
> 2.34.1
>

Samuel Holland July 1, 2024, 3:27 p.m. UTC | #2

Hi Charlie,

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 <[e-mail]>
> Reviewed-by: Conor Dooley <[e-mail]>
> ---
>  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

>  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.

Regards,
Samuel

>  			riscv,isa-base = "rv64i";
>  			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -					       "zifencei", "zihpm";
> +					       "zifencei", "zihpm", "xtheadvector";
> +			thead,vlenb = <128>;
>  			#cooling-cells = <2>;
>  
>  			cpu0_intc: interrupt-controller {
>

Conor Dooley July 1, 2024, 4:07 p.m. UTC | #3

On Mon, Jul 01, 2024 at 10:27:01AM -0500, Samuel Holland wrote:
> Hi Charlie,
> 
> 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 <[e-mail]>
> > Reviewed-by: Conor Dooley <[e-mail]>
> > ---
> >  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/[e-mail]/

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.

Thanks,
Conor.

Samuel Holland July 1, 2024, 4:11 p.m. UTC | #4

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 <[e-mail]>
>>> Reviewed-by: Conor Dooley <[e-mail]>
>>> ---
>>>  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/[e-mail]/
> 
> 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

Conor Dooley July 1, 2024, 4:31 p.m. UTC | #5

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 <[e-mail]>
> >>> Reviewed-by: Conor Dooley <[e-mail]>
> >>> ---
> >>>  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/[e-mail]/
> > 
> > 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);
 	}
 }

Yu-Chien Peter Lin July 2, 2024, 9:46 a.m. UTC | #6

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 <[e-mail]>
> To: Samuel Holland <[e-mail]>
> Cc: Charlie Jenkins <[e-mail]>,
>  [e-mail], [e-mail],
>  [e-mail], [e-mail],
>  [e-mail], [e-mail], Conor Dooley
>  <[e-mail]>, Rob Herring <[e-mail]>, Krzysztof
>  Kozlowski <[e-mail]>, Paul Walmsley <[e-mail]>,
>  Palmer Dabbelt <[e-mail]>, Albert Ou <[e-mail]>,
>  Jisheng Zhang <[e-mail]>, Chen-Yu Tsai <[e-mail]>, Jernej
>  Skrabec <[e-mail]>, Samuel Holland <[e-mail]>,
>  Jonathan Corbet <[e-mail]>, Shuah Khan <[e-mail]>, Guo Ren
>  <[e-mail]>, Evan Green <[e-mail]>, Andy Chiu
>  <[e-mail]>, Jessica Clarke <[e-mail]>,
>  [e-mail]
> 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 <[e-mail]>
> > >>> Reviewed-by: Conor Dooley <[e-mail]>
> > >>> ---
> > >>>  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/[e-mail]/
> > > 
> > > 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

Conor Dooley July 2, 2024, 3:39 p.m. UTC | #7

On Tue, Jul 02, 2024 at 05:46:42PM +0800, Yu-Chien Peter Lin wrote:
> On Mon, Jul 01, 2024 at 05:31:01PM +0100, Conor Dooley wrote:
> > 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:
> > > >>> 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/[e-mail]/
> > > > 
> > > > 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.

Great, that's good to know - thanks!

Patch

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";
 			riscv,isa-base = "rv64i";
 			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
-					       "zifencei", "zihpm";
+					       "zifencei", "zihpm", "xtheadvector";
+			thead,vlenb = <128>;
 			#cooling-cells = <2>;
 
 			cpu0_intc: interrupt-controller {