[v1,6/9] RISC-V: add single letter extensions to riscv_isa_ext

  So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single
letter extensions, add them to it. riscv_isa_ext_data grows a new
member, signifying whether an extension is multi-letter & thus requiring
special handling.
As a result, what gets spat out in /proc/cpuinfo will become borked, as
single letter extensions will be printed as part of the base extensions
and while printing from riscv_isa_arr. Take the opportunity to unify the
printing of the isa string, using the new member of riscv_isa_ext_data
in the process.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/include/asm/hwcap.h |  1 +
 arch/riscv/kernel/cpu.c        | 36 ++++++----------------
 arch/riscv/kernel/cpufeature.c | 56 +++++++++++++++++++++-------------
 3 files changed, 46 insertions(+), 47 deletions(-)
  

On Mon, Jun 26, 2023 at 12:19:44PM +0100, Conor Dooley wrote:
> So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single
> letter extensions, add them to it. riscv_isa_ext_data grows a new
> member, signifying whether an extension is multi-letter & thus requiring
> special handling.
> As a result, what gets spat out in /proc/cpuinfo will become borked, as
> single letter extensions will be printed as part of the base extensions
> and while printing from riscv_isa_arr. Take the opportunity to unify the
> printing of the isa string, using the new member of riscv_isa_ext_data
> in the process.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  arch/riscv/include/asm/hwcap.h |  1 +
>  arch/riscv/kernel/cpu.c        | 36 ++++++----------------
>  arch/riscv/kernel/cpufeature.c | 56 +++++++++++++++++++++-------------
>  3 files changed, 46 insertions(+), 47 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index a35bee219dd7..6ad896dc4342 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -77,6 +77,7 @@ unsigned long riscv_get_elf_hwcap(void);
>  struct riscv_isa_ext_data {
>  	const unsigned int id;
>  	const char *name;
> +	const bool multi_letter;
>  };
>  
>  extern const struct riscv_isa_ext_data riscv_isa_ext[];
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index beb8b16bbf87..046d9d3dac16 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -160,41 +160,25 @@ arch_initcall(riscv_cpuinfo_init);
>  
>  #ifdef CONFIG_PROC_FS
>  
> -static void print_isa_ext(struct seq_file *f)
> -{
> -	for (int i = 0; i < riscv_isa_ext_count; i++) {
> -		const struct riscv_isa_ext_data *edata = &riscv_isa_ext[i];
> -		if (!__riscv_isa_extension_available(NULL, edata->id))
> -			continue;
> -
> -		seq_printf(f, "_%s", edata->name);
> -	}
> -}
> -
> -/*
> - * These are the only valid base (single letter) ISA extensions as per the spec.
> - * It also specifies the canonical order in which it appears in the spec.
> - * Some of the extension may just be a place holder for now (B, K, P, J).
> - * This should be updated once corresponding extensions are ratified.
> - */
> -static const char base_riscv_exts[13] = "imafdqcbkjpvh";
> -
>  static void print_isa(struct seq_file *f)
>  {
> -	int i;
> -
>  	seq_puts(f, "isa\t\t: ");
> +
>  	if (IS_ENABLED(CONFIG_32BIT))
>  		seq_write(f, "rv32", 4);
>  	else
>  		seq_write(f, "rv64", 4);
>  
> -	for (i = 0; i < sizeof(base_riscv_exts); i++) {
> -		if (__riscv_isa_extension_available(NULL, base_riscv_exts[i] - 'a'))
> -			/* Print only enabled the base ISA extensions */
> -			seq_write(f, &base_riscv_exts[i], 1);
> +	for (int i = 0; i < riscv_isa_ext_count; i++) {
> +		if (!__riscv_isa_extension_available(NULL, riscv_isa_ext[i].id))
> +			continue;
> +
> +		if (riscv_isa_ext[i].multi_letter)
> +			seq_puts(f, "_");
> +
> +		seq_printf(f, "%s", riscv_isa_ext[i].name);
>  	}
> -	print_isa_ext(f);
> +
>  	seq_puts(f, "\n");
>  }
>  
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index b5e23506c4f0..5405d8a58537 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -99,9 +99,10 @@ static bool riscv_isa_extension_check(int id)
>  	return true;
>  }
>  
> -#define __RISCV_ISA_EXT_DATA(_name, _id) {	\
> -	.name = #_name,				\
> -	.id = _id,				\
> +#define __RISCV_ISA_EXT_DATA(_name, _id, _multi) {	\
> +	.name = #_name,					\
> +	.id = _id,					\
> +	.multi_letter = _multi,				\
>  }
>  
>  /*
> @@ -144,24 +145,37 @@ static bool riscv_isa_extension_check(int id)
>   * New entries to this struct should follow the ordering rules described above.
>   */
>  const struct riscv_isa_ext_data riscv_isa_ext[] = {
> -	__RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
> -	__RISCV_ISA_EXT_DATA(zicboz, RISCV_ISA_EXT_ZICBOZ),
> -	__RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
> -	__RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
> -	__RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
> -	__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
> -	__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
> -	__RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA),
> -	__RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> -	__RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS),
> -	__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
> -	__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
> -	__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
> -	__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
> -	__RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
> -	__RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
> -	__RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
> -	__RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
> +	__RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i, false),
> +	__RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m, false),
> +	__RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a, false),
> +	__RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f, false),
> +	__RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d, false),
> +	__RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q, false),
> +	__RISCV_ISA_EXT_DATA(c, RISCV_ISA_EXT_c, false),
> +	__RISCV_ISA_EXT_DATA(b, RISCV_ISA_EXT_b, false),
> +	__RISCV_ISA_EXT_DATA(k, RISCV_ISA_EXT_k, false),
> +	__RISCV_ISA_EXT_DATA(j, RISCV_ISA_EXT_j, false),
> +	__RISCV_ISA_EXT_DATA(p, RISCV_ISA_EXT_p, false),
> +	__RISCV_ISA_EXT_DATA(v, RISCV_ISA_EXT_v, false),
> +	__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h, false),
> +	__RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM, true),
> +	__RISCV_ISA_EXT_DATA(zicboz, RISCV_ISA_EXT_ZICBOZ, true),
> +	__RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR, true),
> +	__RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR, true),
> +	__RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI, true),
> +	__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE, true),
> +	__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM, true),
> +	__RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA, true),
> +	__RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB, true),
> +	__RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS, true),
> +	__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA, true),
> +	__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA, true),
> +	__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF, true),
> +	__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC, true),
> +	__RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL, true),
> +	__RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT, true),
> +	__RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT, true),
> +	__RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX, true),
>  };
>  
>  const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
> -- 
> 2.40.1
>

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
  

On Mon, Jun 26, 2023 at 4:21 AM Conor Dooley <conor.dooley@microchip.com> wrote:
>
> So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single
> letter extensions, add them to it. riscv_isa_ext_data grows a new
> member, signifying whether an extension is multi-letter & thus requiring
> special handling.
> As a result, what gets spat out in /proc/cpuinfo will become borked, as
> single letter extensions will be printed as part of the base extensions
> and while printing from riscv_isa_arr. Take the opportunity to unify the
> printing of the isa string, using the new member of riscv_isa_ext_data
> in the process.
>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  arch/riscv/include/asm/hwcap.h |  1 +
>  arch/riscv/kernel/cpu.c        | 36 ++++++----------------
>  arch/riscv/kernel/cpufeature.c | 56 +++++++++++++++++++++-------------
>  3 files changed, 46 insertions(+), 47 deletions(-)
>
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index a35bee219dd7..6ad896dc4342 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -77,6 +77,7 @@ unsigned long riscv_get_elf_hwcap(void);
>  struct riscv_isa_ext_data {
>         const unsigned int id;
>         const char *name;
> +       const bool multi_letter;

Instead of defining a new member, could we just infer this by making a
macro like #define MULTI_LETTER(name) (name[0] && name[1])?
  

On Wed, Jun 28, 2023 at 10:33:20AM -0700, Evan Green wrote:
> On Mon, Jun 26, 2023 at 4:21 AM Conor Dooley <conor.dooley@microchip.com> wrote:
> >
> > So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single
> > letter extensions, add them to it. riscv_isa_ext_data grows a new
> > member, signifying whether an extension is multi-letter & thus requiring
> > special handling.
> > As a result, what gets spat out in /proc/cpuinfo will become borked, as
> > single letter extensions will be printed as part of the base extensions
> > and while printing from riscv_isa_arr. Take the opportunity to unify the
> > printing of the isa string, using the new member of riscv_isa_ext_data
> > in the process.
> >
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> >  arch/riscv/include/asm/hwcap.h |  1 +
> >  arch/riscv/kernel/cpu.c        | 36 ++++++----------------
> >  arch/riscv/kernel/cpufeature.c | 56 +++++++++++++++++++++-------------
> >  3 files changed, 46 insertions(+), 47 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> > index a35bee219dd7..6ad896dc4342 100644
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@ -77,6 +77,7 @@ unsigned long riscv_get_elf_hwcap(void);
> >  struct riscv_isa_ext_data {
> >         const unsigned int id;
> >         const char *name;
> > +       const bool multi_letter;
> 
> Instead of defining a new member, could we just infer this by making a
> macro like #define MULTI_LETTER(name) (name[0] && name[1])?

Or don't even try to be clever like this and just call strnlen on the
name & check if it is 1? It's only used in 2 places.
  

On Wed, Jun 28, 2023 at 10:43 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Wed, Jun 28, 2023 at 10:33:20AM -0700, Evan Green wrote:
> > On Mon, Jun 26, 2023 at 4:21 AM Conor Dooley <conor.dooley@microchip.com> wrote:
> > >
> > > So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single
> > > letter extensions, add them to it. riscv_isa_ext_data grows a new
> > > member, signifying whether an extension is multi-letter & thus requiring
> > > special handling.
> > > As a result, what gets spat out in /proc/cpuinfo will become borked, as
> > > single letter extensions will be printed as part of the base extensions
> > > and while printing from riscv_isa_arr. Take the opportunity to unify the
> > > printing of the isa string, using the new member of riscv_isa_ext_data
> > > in the process.
> > >
> > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > > ---
> > >  arch/riscv/include/asm/hwcap.h |  1 +
> > >  arch/riscv/kernel/cpu.c        | 36 ++++++----------------
> > >  arch/riscv/kernel/cpufeature.c | 56 +++++++++++++++++++++-------------
> > >  3 files changed, 46 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> > > index a35bee219dd7..6ad896dc4342 100644
> > > --- a/arch/riscv/include/asm/hwcap.h
> > > +++ b/arch/riscv/include/asm/hwcap.h
> > > @@ -77,6 +77,7 @@ unsigned long riscv_get_elf_hwcap(void);
> > >  struct riscv_isa_ext_data {
> > >         const unsigned int id;
> > >         const char *name;
> > > +       const bool multi_letter;
> >
> > Instead of defining a new member, could we just infer this by making a
> > macro like #define MULTI_LETTER(name) (name[0] && name[1])?
>
> Or don't even try to be clever like this and just call strnlen on the
> name & check if it is 1? It's only used in 2 places.

Sounds good to me!