From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org
Cc: Conor Dooley <conor.dooley@microchip.com>,
ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org,
corbet@lwn.net, guoren@kernel.org, heiko@sntech.de,
paul.walmsley@sifive.com, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: [PATCH v1 0/3] Putting some basic order on isa extension lists
Date: Wed, 30 Nov 2022 23:41:23 +0000 [thread overview]
Message-ID: <20221130234125.2722364-1-conor@kernel.org> (raw)
From: Conor Dooley <conor.dooley@microchip.com>
I don't know for sure that I have not re-ordered something that is
sacrosanct. It seems that all of these are internal use structs, and
should be okay, barring the obvious exception of the, intentionally
re-ordered, isa_ext_arr.
With that caveat out of the way - all I did here was try to make things
consistent so that it'd be easier to point patch submitters at a "do
this order please".
I never know which of these can be moved without breaking stuff - but
they all seem to be internal use stuff since they're not in uapi?
For v2, I added another path with some uapi docs & switched to Drew's
suggested ordering of alphabetically, except in the /proc/cpuinfo array,
as per the discussion today in the pw-sync call. I also added a
sprinkling of comments around which things should be sorted in which
way.
I guess consider this an RFS, with the S being Screaming in the case of
me doing something you abhor :)
Thanks,
Conor.
CC: ajones@ventanamicro.com
CC: aou@eecs.berkeley.edu
CC: conor@kernel.org
CC: conor.dooley@microchip.com
CC: corbet@lwn.net
CC: guoren@kernel.org
CC: heiko@sntech.de
CC: palmer@dabbelt.com
CC: paul.walmsley@sifive.com
CC: linux-kernel@vger.kernel.org
CC: linux-riscv@lists.infradead.org
CC: linux-doc@vger.kernel.org
Conor Dooley (3):
RISC-V: clarify ISA string ordering rules in cpu.c
RISC-V: resort all extensions in consistent orders
Documentation: riscv: add a section about ISA string ordering in
/proc/cpuinfo
Documentation/riscv/uabi.rst | 42 +++++++++++++++++++++++++++
arch/riscv/include/asm/hwcap.h | 12 ++++----
arch/riscv/kernel/cpu.c | 53 ++++++++++++++++++++++++----------
arch/riscv/kernel/cpufeature.c | 6 ++--
4 files changed, 91 insertions(+), 22 deletions(-)
--
2.38.1
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org
Cc: Conor Dooley <conor.dooley@microchip.com>,
ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org,
corbet@lwn.net, guoren@kernel.org, heiko@sntech.de,
paul.walmsley@sifive.com, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: [PATCH v1 0/3] Putting some basic order on isa extension lists
Date: Wed, 30 Nov 2022 23:41:23 +0000 [thread overview]
Message-ID: <20221130234125.2722364-1-conor@kernel.org> (raw)
From: Conor Dooley <conor.dooley@microchip.com>
I don't know for sure that I have not re-ordered something that is
sacrosanct. It seems that all of these are internal use structs, and
should be okay, barring the obvious exception of the, intentionally
re-ordered, isa_ext_arr.
With that caveat out of the way - all I did here was try to make things
consistent so that it'd be easier to point patch submitters at a "do
this order please".
I never know which of these can be moved without breaking stuff - but
they all seem to be internal use stuff since they're not in uapi?
For v2, I added another path with some uapi docs & switched to Drew's
suggested ordering of alphabetically, except in the /proc/cpuinfo array,
as per the discussion today in the pw-sync call. I also added a
sprinkling of comments around which things should be sorted in which
way.
I guess consider this an RFS, with the S being Screaming in the case of
me doing something you abhor :)
Thanks,
Conor.
CC: ajones@ventanamicro.com
CC: aou@eecs.berkeley.edu
CC: conor@kernel.org
CC: conor.dooley@microchip.com
CC: corbet@lwn.net
CC: guoren@kernel.org
CC: heiko@sntech.de
CC: palmer@dabbelt.com
CC: paul.walmsley@sifive.com
CC: linux-kernel@vger.kernel.org
CC: linux-riscv@lists.infradead.org
CC: linux-doc@vger.kernel.org
Conor Dooley (3):
RISC-V: clarify ISA string ordering rules in cpu.c
RISC-V: resort all extensions in consistent orders
Documentation: riscv: add a section about ISA string ordering in
/proc/cpuinfo
Documentation/riscv/uabi.rst | 42 +++++++++++++++++++++++++++
arch/riscv/include/asm/hwcap.h | 12 ++++----
arch/riscv/kernel/cpu.c | 53 ++++++++++++++++++++++++----------
arch/riscv/kernel/cpufeature.c | 6 ++--
4 files changed, 91 insertions(+), 22 deletions(-)
--
2.38.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next reply other threads:[~2022-11-30 23:42 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 23:41 Conor Dooley [this message]
2022-11-30 23:41 ` [PATCH v1 0/3] Putting some basic order on isa extension lists 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
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=20221130234125.2722364-1-conor@kernel.org \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=conor.dooley@microchip.com \
--cc=corbet@lwn.net \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--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.