All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: "Hongren (Zenithal) Zheng" <i@zenithal.me>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Atish Patra <atishp@rivosinc.com>,
	Anup Patel <anup@brainfault.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>, <linux-mm@kvack.org>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<linux-api@vger.kernel.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	<linux-man@vger.kernel.org>, Jiatai He <jiatai2021@iscas.ac.cn>,
	Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT
Date: Thu, 24 Nov 2022 11:53:19 +0000	[thread overview]
Message-ID: <Y39bL1Vp8Fx7ZD6g@wendy> (raw)
In-Reply-To: <YqY0aSngjI0Hc5d4@Sun>

Hey Hongren,

On Mon, Jun 13, 2022 at 02:46:01AM +0800, Hongren (Zenithal) Zheng wrote:
> This patch parses Zb/Zk related string from DT and
> output them in cpuinfo

Could you please wrap changelogs at 72 character rather than 50?

> 
> One thing worth noting is that if DT provides zk,
> all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled.
> 
> Note that zk is a valid extension name and the current
> DT binding spec allows this.

Where is the "DT binding spec" for this?
At the time, IIRC, putting any multiletter extensions in a DT was
a violation of the dt-binding, so I am interested in seeing what spec
had covered this.

> This patch also changes the logical id of
> existing multi-letter extensions and adds a statement
> that instead of logical id compatibility, the order
> is needed.
> 
> There currently lacks a mechanism to merge them when
> producing cpuinfo. Namely if you provide a riscv,isa
> "rv64imafdc_zk_zks", the cpuinfo output would be
> "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed
> _zksh_zkt"
> 
> Tested-by: Jiatai He <jiatai2021@iscas.ac.cn>
> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me>
> ---
>  arch/riscv/include/asm/hwcap.h | 20 +++++++++++++++++++-
>  arch/riscv/kernel/cpu.c        | 14 ++++++++++++++
>  arch/riscv/kernel/cpufeature.c | 33 +++++++++++++++++++++++++++++++++
>  3 files changed, 66 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 4e2486881840..02c454a12683 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -49,9 +49,27 @@ extern unsigned long elf_hwcap;
>   * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter
>   * extensions while all the multi-letter extensions should define the next
>   * available logical extension id.
> + *
> + * The order of them should be maintained according to the riscv-isa-manual.
> + * As this is an internal API, changing the id of one extension does
> + * not affect compatibility.

Hmm, not too sure about this. See 61a41d16ad20 ("RISC-V: Print SSTC in
canonical order"), where Palmer re-sorted another one of these internal
APIs (isa_ext_arr) in a different order to what it would appear you're
proposing here.

I am really really bad when it comes to specs, manuals etc - is there a
link to the specific part of the riscv-isa-manual that we can use here
for reference? Otherwise I'd much rather stick with what I **thought**
was the "canonical order", _Sfoo_Zfoo_Xfoo.

Or are these slightly different - and fit in the "Additional Standard
Extension Names" category rather than "Machine-level Instruction-Set
Extensions"?

The only ones I see pointed out in the current table [0] are Ztso,
Zicsr, Zifencei & Zam which is what I (maybe wrongly!!) assumed to be
the exceptions to the S before Z rule.

I tried to have a look in the "bitmanip-1.0.0" pdf at [2], but I don't
see it use the word "Standard" anywhere. As I already said, this stuff
confuses me no end so some clarification would be really helpful :)

The same applies to the crypto stuff.

In other news, since Palmer did do a re-order, and its been several
months - you'll need to rebase & re-submit anyway.

Thanks,
Conor.

0 - https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L132
1 - https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L182
2 - https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0

>   */
>  enum riscv_isa_ext_id {
> -	RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE,
> +	RISCV_ISA_EXT_ZBA = RISCV_ISA_EXT_BASE,
> +	RISCV_ISA_EXT_ZBB,
> +	RISCV_ISA_EXT_ZBC,
> +	RISCV_ISA_EXT_ZBKB,
> +	RISCV_ISA_EXT_ZBKC,
> +	RISCV_ISA_EXT_ZBKX,
> +	RISCV_ISA_EXT_ZBS,
> +	RISCV_ISA_EXT_ZKND,
> +	RISCV_ISA_EXT_ZKNE,
> +	RISCV_ISA_EXT_ZKNH,
> +	RISCV_ISA_EXT_ZKR,
> +	RISCV_ISA_EXT_ZKSED,
> +	RISCV_ISA_EXT_ZKSH,
> +	RISCV_ISA_EXT_ZKT,
> +	RISCV_ISA_EXT_SSCOFPMF,
>  	RISCV_ISA_EXT_SVPBMT,
>  	RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
>  };
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index fba9e9f46a8c..d9ff9bff3d45 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -87,6 +87,20 @@ int riscv_of_parent_hartid(struct device_node *node)
>   *    extensions by an underscore.
>   */
>  static struct riscv_isa_ext_data isa_ext_arr[] = {
> +	__RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA),
> +	__RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +	__RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC),
> +	__RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB),
> +	__RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC),
> +	__RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX),
> +	__RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS),
> +	__RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND),
> +	__RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE),
> +	__RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH),
> +	__RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR),
> +	__RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> +	__RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> +	__RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
>  	__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
>  	__RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>  	__RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index a6f62a6d1edd..0c2638365ec2 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -199,6 +199,39 @@ void __init riscv_fill_hwcap(void)
>  			} else {
>  				SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF);
>  				SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT);
> +				SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA);
> +				SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB);
> +				SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC);
> +				SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS);
> +				SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND);
> +				SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE);
> +				SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH);
> +				SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED);
> +				SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH);
> +				SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR);
> +				SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT);
>  			}
>  #undef SET_ISA_EXT_MAP
>  		}
> -- 
> 2.35.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor.dooley@microchip.com>
To: "Hongren (Zenithal) Zheng" <i@zenithal.me>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Atish Patra <atishp@rivosinc.com>,
	Anup Patel <anup@brainfault.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>, <linux-mm@kvack.org>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<linux-api@vger.kernel.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	<linux-man@vger.kernel.org>, Jiatai He <jiatai2021@iscas.ac.cn>,
	Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT
Date: Thu, 24 Nov 2022 11:53:19 +0000	[thread overview]
Message-ID: <Y39bL1Vp8Fx7ZD6g@wendy> (raw)
In-Reply-To: <YqY0aSngjI0Hc5d4@Sun>

Hey Hongren,

On Mon, Jun 13, 2022 at 02:46:01AM +0800, Hongren (Zenithal) Zheng wrote:
> This patch parses Zb/Zk related string from DT and
> output them in cpuinfo

Could you please wrap changelogs at 72 character rather than 50?

> 
> One thing worth noting is that if DT provides zk,
> all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled.
> 
> Note that zk is a valid extension name and the current
> DT binding spec allows this.

Where is the "DT binding spec" for this?
At the time, IIRC, putting any multiletter extensions in a DT was
a violation of the dt-binding, so I am interested in seeing what spec
had covered this.

> This patch also changes the logical id of
> existing multi-letter extensions and adds a statement
> that instead of logical id compatibility, the order
> is needed.
> 
> There currently lacks a mechanism to merge them when
> producing cpuinfo. Namely if you provide a riscv,isa
> "rv64imafdc_zk_zks", the cpuinfo output would be
> "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed
> _zksh_zkt"
> 
> Tested-by: Jiatai He <jiatai2021@iscas.ac.cn>
> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me>
> ---
>  arch/riscv/include/asm/hwcap.h | 20 +++++++++++++++++++-
>  arch/riscv/kernel/cpu.c        | 14 ++++++++++++++
>  arch/riscv/kernel/cpufeature.c | 33 +++++++++++++++++++++++++++++++++
>  3 files changed, 66 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 4e2486881840..02c454a12683 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -49,9 +49,27 @@ extern unsigned long elf_hwcap;
>   * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter
>   * extensions while all the multi-letter extensions should define the next
>   * available logical extension id.
> + *
> + * The order of them should be maintained according to the riscv-isa-manual.
> + * As this is an internal API, changing the id of one extension does
> + * not affect compatibility.

Hmm, not too sure about this. See 61a41d16ad20 ("RISC-V: Print SSTC in
canonical order"), where Palmer re-sorted another one of these internal
APIs (isa_ext_arr) in a different order to what it would appear you're
proposing here.

I am really really bad when it comes to specs, manuals etc - is there a
link to the specific part of the riscv-isa-manual that we can use here
for reference? Otherwise I'd much rather stick with what I **thought**
was the "canonical order", _Sfoo_Zfoo_Xfoo.

Or are these slightly different - and fit in the "Additional Standard
Extension Names" category rather than "Machine-level Instruction-Set
Extensions"?

The only ones I see pointed out in the current table [0] are Ztso,
Zicsr, Zifencei & Zam which is what I (maybe wrongly!!) assumed to be
the exceptions to the S before Z rule.

I tried to have a look in the "bitmanip-1.0.0" pdf at [2], but I don't
see it use the word "Standard" anywhere. As I already said, this stuff
confuses me no end so some clarification would be really helpful :)

The same applies to the crypto stuff.

In other news, since Palmer did do a re-order, and its been several
months - you'll need to rebase & re-submit anyway.

Thanks,
Conor.

0 - https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L132
1 - https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L182
2 - https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0

>   */
>  enum riscv_isa_ext_id {
> -	RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE,
> +	RISCV_ISA_EXT_ZBA = RISCV_ISA_EXT_BASE,
> +	RISCV_ISA_EXT_ZBB,
> +	RISCV_ISA_EXT_ZBC,
> +	RISCV_ISA_EXT_ZBKB,
> +	RISCV_ISA_EXT_ZBKC,
> +	RISCV_ISA_EXT_ZBKX,
> +	RISCV_ISA_EXT_ZBS,
> +	RISCV_ISA_EXT_ZKND,
> +	RISCV_ISA_EXT_ZKNE,
> +	RISCV_ISA_EXT_ZKNH,
> +	RISCV_ISA_EXT_ZKR,
> +	RISCV_ISA_EXT_ZKSED,
> +	RISCV_ISA_EXT_ZKSH,
> +	RISCV_ISA_EXT_ZKT,
> +	RISCV_ISA_EXT_SSCOFPMF,
>  	RISCV_ISA_EXT_SVPBMT,
>  	RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
>  };
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index fba9e9f46a8c..d9ff9bff3d45 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -87,6 +87,20 @@ int riscv_of_parent_hartid(struct device_node *node)
>   *    extensions by an underscore.
>   */
>  static struct riscv_isa_ext_data isa_ext_arr[] = {
> +	__RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA),
> +	__RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> +	__RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC),
> +	__RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB),
> +	__RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC),
> +	__RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX),
> +	__RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS),
> +	__RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND),
> +	__RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE),
> +	__RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH),
> +	__RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR),
> +	__RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> +	__RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> +	__RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
>  	__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
>  	__RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>  	__RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index a6f62a6d1edd..0c2638365ec2 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -199,6 +199,39 @@ void __init riscv_fill_hwcap(void)
>  			} else {
>  				SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF);
>  				SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT);
> +				SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA);
> +				SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB);
> +				SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC);
> +				SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS);
> +				SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND);
> +				SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE);
> +				SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH);
> +				SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED);
> +				SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH);
> +				SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR);
> +				SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE);
> +				SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED);
> +				SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR);
> +				SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT);
>  			}
>  #undef SET_ISA_EXT_MAP
>  		}
> -- 
> 2.35.1
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2022-11-24 11:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-12 18:44 [PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Hongren (Zenithal) Zheng
2022-06-12 18:44 ` Hongren (Zenithal) Zheng
2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng
2022-06-12 18:46   ` Hongren (Zenithal) Zheng
2022-11-24  9:19   ` Samuel Ortiz
2022-11-24  9:19     ` Samuel Ortiz
2022-11-24 11:53   ` Conor Dooley [this message]
2022-11-24 11:53     ` Conor Dooley
2022-06-12 18:46 ` [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto Hongren (Zenithal) Zheng
2022-06-12 18:46   ` Hongren (Zenithal) Zheng
2022-11-24  9:30   ` Samuel Ortiz
2022-11-24  9:30     ` Samuel Ortiz
2022-11-24  9:58     ` Conor Dooley
2022-11-24  9:58       ` Conor Dooley
2022-11-24 10:47       ` Samuel Ortiz
2022-11-24 10:47         ` Samuel Ortiz
2022-11-24 11:55         ` Conor Dooley
2022-11-24 11:55           ` Conor Dooley
2022-11-24 17:12           ` Samuel Ortiz
2022-11-24 17:12             ` Samuel Ortiz
2022-11-24 17:20             ` Conor Dooley
2022-11-24 17:20               ` Conor Dooley
2022-11-24 17:34               ` Samuel Ortiz
2022-11-24 17:34                 ` Samuel Ortiz
2022-11-24 17:54                 ` Conor Dooley
2022-11-24 17:54                   ` Conor Dooley
2022-11-24 18:09                   ` Samuel Ortiz
2022-11-24 18:09                     ` Samuel Ortiz
2022-06-12 18:47 ` [PATCH v3 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT Hongren (Zenithal) Zheng
2022-06-12 18:47   ` Hongren (Zenithal) Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y39bL1Vp8Fx7ZD6g@wendy \
    --to=conor.dooley@microchip.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=atishp@rivosinc.com \
    --cc=ebiederm@xmission.com \
    --cc=heiko@sntech.de \
    --cc=i@zenithal.me \
    --cc=jiatai2021@iscas.ac.cn \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mtk.manpages@gmail.com \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.