From: "Heiko Stübner" <heiko@sntech.de>
To: Conor Dooley <conor@kernel.org>, Andrew Jones <ajones@ventanamicro.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org,
Conor Dooley <conor.dooley@microchip.com>,
aou@eecs.berkeley.edu, corbet@lwn.net, guoren@kernel.org,
paul.walmsley@sifive.com, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v1 2/3] RISC-V: resort all extensions in consistent orders
Date: Thu, 01 Dec 2022 11:47:04 +0100 [thread overview]
Message-ID: <46873028.fMDQidcC6G@diego> (raw)
In-Reply-To: <20221201090041.525op4sateq5wq4y@kamzik>
Am Donnerstag, 1. Dezember 2022, 10:00:41 CET schrieb Andrew Jones:
> On Wed, Nov 30, 2022 at 11:41:25PM +0000, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Ordering between each and every list of extensions is wildly
> > inconsistent. Per discussion on the lists pick the following policy:
> >
> > - The array defining order in /proc/cpuinfo follows a narrow
> > interpretation of the ISA specifications, described in a comment
> > immediately presiding it.
> >
> > - All other lists of extensions are sorted alphabetically.
> >
> > This will hopefully allow for easier review & future additions, and
> > reduce conflicts between patchsets as the number of extensions grows.
> >
> > Link: https://lore.kernel.org/all/20221129144742.2935581-2-conor.dooley@microchip.com/
> > Suggested-by: Andrew Jones <ajones@ventanamicro.com>
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > I could not decide between adding an alphabetical comment to each
> > alphabetical site or not. I did it anyway. Scream if you hate it!
> >
> > I also moved a static branch thingy in this version, but that should not
> > matter, right? riightt?
>
> riiighttt. And it goes away with [1] anyway.
>
> [1] https://lore.kernel.org/all/20221006070818.3616-1-jszhang@kernel.org/
I'm not sure what became of that series since mid october, though noting
that tightly coupling the patching to extensions alone might cause issues [2]
which some of the "features" like fast-unaligned access, that are not directly
bound to a isa-extension but to an implementation detail
[2] https://lore.kernel.org/all/1991071.yIU609i1g2@phil/
>
> > ---
> > arch/riscv/include/asm/hwcap.h | 12 +++++++-----
> > arch/riscv/kernel/cpu.c | 4 ++--
> > arch/riscv/kernel/cpufeature.c | 6 ++++--
> > 3 files changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> > index b22525290073..ce522aad641a 100644
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@ -51,14 +51,15 @@ 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.
> > + * Entries are sorted alphabetically.
> > */
> > enum riscv_isa_ext_id {
> > RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE,
> > + RISCV_ISA_EXT_SSTC,
> > + RISCV_ISA_EXT_SVINVAL,
> > RISCV_ISA_EXT_SVPBMT,
> > RISCV_ISA_EXT_ZICBOM,
> > RISCV_ISA_EXT_ZIHINTPAUSE,
> > - RISCV_ISA_EXT_SSTC,
> > - RISCV_ISA_EXT_SVINVAL,
> > RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
> > };
>
> Unrelated to this patch, but every time I look at this enum I want to post
> the diff below, but I haven't bothered, because this enum also goes away
> with [1].
>
> @@ -59,8 +59,9 @@ enum riscv_isa_ext_id {
> RISCV_ISA_EXT_ZIHINTPAUSE,
> RISCV_ISA_EXT_SSTC,
> RISCV_ISA_EXT_SVINVAL,
> - RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
> + RISCV_ISA_EXT_ID_MAX
> };
> +static_assert(RISCV_ISA_EXT_ID_MAX <= RISCV_ISA_EXT_MAX);
that sounds like a very reasonable idea ... what's keeping you? :-)
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Conor Dooley <conor@kernel.org>, Andrew Jones <ajones@ventanamicro.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org,
Conor Dooley <conor.dooley@microchip.com>,
aou@eecs.berkeley.edu, corbet@lwn.net, guoren@kernel.org,
paul.walmsley@sifive.com, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v1 2/3] RISC-V: resort all extensions in consistent orders
Date: Thu, 01 Dec 2022 11:47:04 +0100 [thread overview]
Message-ID: <46873028.fMDQidcC6G@diego> (raw)
In-Reply-To: <20221201090041.525op4sateq5wq4y@kamzik>
Am Donnerstag, 1. Dezember 2022, 10:00:41 CET schrieb Andrew Jones:
> On Wed, Nov 30, 2022 at 11:41:25PM +0000, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Ordering between each and every list of extensions is wildly
> > inconsistent. Per discussion on the lists pick the following policy:
> >
> > - The array defining order in /proc/cpuinfo follows a narrow
> > interpretation of the ISA specifications, described in a comment
> > immediately presiding it.
> >
> > - All other lists of extensions are sorted alphabetically.
> >
> > This will hopefully allow for easier review & future additions, and
> > reduce conflicts between patchsets as the number of extensions grows.
> >
> > Link: https://lore.kernel.org/all/20221129144742.2935581-2-conor.dooley@microchip.com/
> > Suggested-by: Andrew Jones <ajones@ventanamicro.com>
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > I could not decide between adding an alphabetical comment to each
> > alphabetical site or not. I did it anyway. Scream if you hate it!
> >
> > I also moved a static branch thingy in this version, but that should not
> > matter, right? riightt?
>
> riiighttt. And it goes away with [1] anyway.
>
> [1] https://lore.kernel.org/all/20221006070818.3616-1-jszhang@kernel.org/
I'm not sure what became of that series since mid october, though noting
that tightly coupling the patching to extensions alone might cause issues [2]
which some of the "features" like fast-unaligned access, that are not directly
bound to a isa-extension but to an implementation detail
[2] https://lore.kernel.org/all/1991071.yIU609i1g2@phil/
>
> > ---
> > arch/riscv/include/asm/hwcap.h | 12 +++++++-----
> > arch/riscv/kernel/cpu.c | 4 ++--
> > arch/riscv/kernel/cpufeature.c | 6 ++++--
> > 3 files changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> > index b22525290073..ce522aad641a 100644
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@ -51,14 +51,15 @@ 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.
> > + * Entries are sorted alphabetically.
> > */
> > enum riscv_isa_ext_id {
> > RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE,
> > + RISCV_ISA_EXT_SSTC,
> > + RISCV_ISA_EXT_SVINVAL,
> > RISCV_ISA_EXT_SVPBMT,
> > RISCV_ISA_EXT_ZICBOM,
> > RISCV_ISA_EXT_ZIHINTPAUSE,
> > - RISCV_ISA_EXT_SSTC,
> > - RISCV_ISA_EXT_SVINVAL,
> > RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
> > };
>
> Unrelated to this patch, but every time I look at this enum I want to post
> the diff below, but I haven't bothered, because this enum also goes away
> with [1].
>
> @@ -59,8 +59,9 @@ enum riscv_isa_ext_id {
> RISCV_ISA_EXT_ZIHINTPAUSE,
> RISCV_ISA_EXT_SSTC,
> RISCV_ISA_EXT_SVINVAL,
> - RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
> + RISCV_ISA_EXT_ID_MAX
> };
> +static_assert(RISCV_ISA_EXT_ID_MAX <= RISCV_ISA_EXT_MAX);
that sounds like a very reasonable idea ... what's keeping you? :-)
Heiko
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-12-01 10:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 23:41 [PATCH v1 0/3] Putting some basic order on isa extension lists Conor Dooley
2022-11-30 23:41 ` Conor Dooley
2022-11-30 23:41 ` [PATCH v1 1/3] RISC-V: clarify ISA string ordering rules in cpu.c Conor Dooley
2022-11-30 23:41 ` Conor Dooley
2022-12-01 8:27 ` Andrew Jones
2022-12-01 8:27 ` Andrew Jones
2022-12-01 8:48 ` Conor Dooley
2022-12-01 8:48 ` Conor Dooley
2022-11-30 23:41 ` [PATCH v1 2/3] RISC-V: resort all extensions in consistent orders Conor Dooley
2022-11-30 23:41 ` Conor Dooley
2022-12-01 9:00 ` Andrew Jones
2022-12-01 9:00 ` Andrew Jones
2022-12-01 10:47 ` Heiko Stübner [this message]
2022-12-01 10:47 ` Heiko Stübner
2022-12-01 11:38 ` Andrew Jones
2022-12-01 11:38 ` Andrew Jones
2022-12-01 12:29 ` Conor Dooley
2022-12-01 12:29 ` Conor Dooley
2022-12-01 12:37 ` Conor.Dooley
2022-12-01 12:37 ` Conor.Dooley
2022-12-01 10:48 ` Heiko Stübner
2022-12-01 10:48 ` Heiko Stübner
2022-11-30 23:41 ` [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Conor Dooley
2022-11-30 23:41 ` Conor Dooley
2022-11-30 23:46 ` Conor Dooley
2022-11-30 23:46 ` Conor Dooley
2022-12-01 3:05 ` Bagas Sanjaya
2022-12-01 3:05 ` Bagas Sanjaya
2022-12-01 8:17 ` Conor Dooley
2022-12-01 8:17 ` Conor Dooley
2022-12-02 2:14 ` Bagas Sanjaya
2022-12-02 2:14 ` Bagas Sanjaya
2022-12-02 11:37 ` Conor Dooley
2022-12-02 11:37 ` Conor Dooley
2022-12-01 9:14 ` Andrew Jones
2022-12-01 9:14 ` Andrew Jones
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=46873028.fMDQidcC6G@diego \
--to=heiko@sntech.de \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=corbet@lwn.net \
--cc=guoren@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.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.