From: Conor Dooley <conor@kernel.org>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Conor Dooley <conor.dooley@microchip.com>,
Heiko Stuebner <heiko@sntech.de>,
Anup Patel <apatel@ventanamicro.com>,
Atish Patra <atishp@rivosinc.com>
Subject: Re: [PATCH 2/3] RISC-V: Introduce riscv_isa_extension_check
Date: Sun, 23 Oct 2022 20:32:38 +0100 [thread overview]
Message-ID: <Y1WW1v5T6IYSGN6G@spud> (raw)
In-Reply-To: <20221021105905.206385-3-ajones@ventanamicro.com>
On Fri, Oct 21, 2022 at 12:59:04PM +0200, Andrew Jones wrote:
> Currently any isa extension found in the isa string is set in the
> isa bitmap. An isa extension set in the bitmap indicates that the
> extension is present and may be used (a.k.a is enabled). However,
> when an extension cannot be used due to missing dependencies or
> errata it should not be added to the bitmap. Introduce a function
> where additional checks may be placed in order to determine if an
> extension should be enabled or not.
>
> Note, the checks may simply indicate an issue with the DT, but,
> since extensions may be used in early boot, it's not always possible
> to simply produce an error at the point the issue is determined.
> It's best to keep the extension disabled and produce an error.
Aye, agreed. Could be pretty nasty chasing down something like this...
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
> No functional change intended, as the function is only introduced
> and always returns true. A later patch will provide checks for an
> isa extension.
>
> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> ---
> arch/riscv/kernel/cpufeature.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 4677320d7e31..220be7222129 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -68,6 +68,11 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> }
> EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
>
> +static bool riscv_isa_extension_check(int id)
> +{
> + return true;
> +}
> +
> void __init riscv_fill_hwcap(void)
> {
> struct device_node *node;
> @@ -189,7 +194,8 @@ void __init riscv_fill_hwcap(void)
> #define SET_ISA_EXT_MAP(name, bit) \
> do { \
> if ((ext_end - ext == sizeof(name) - 1) && \
> - !memcmp(ext, name, sizeof(name) - 1)) \
> + !memcmp(ext, name, sizeof(name) - 1) && \
> + riscv_isa_extension_check(bit)) \
> set_bit(bit, this_isa); \
> } while (false) \
>
> @@ -198,8 +204,10 @@ void __init riscv_fill_hwcap(void)
> if (!ext_long) {
> int nr = *ext - 'a';
>
> - this_hwcap |= isa2hwcap[nr];
> - set_bit(nr, this_isa);
> + if (riscv_isa_extension_check(nr)) {
> + this_hwcap |= isa2hwcap[nr];
> + set_bit(nr, this_isa);
> + }
> } else {
> SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF);
> SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT);
> --
> 2.37.3
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-10-23 19:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 10:59 [PATCH 0/3] RISC-V: Ensure Zicbom has a valid block size Andrew Jones
2022-10-21 10:59 ` [PATCH 1/3] RISC-V: Improve use of isa2hwcap[] Andrew Jones
2022-10-23 19:28 ` Conor Dooley
2022-10-24 6:48 ` Andrew Jones
2022-10-24 7:16 ` Conor Dooley
2022-10-21 10:59 ` [PATCH 2/3] RISC-V: Introduce riscv_isa_extension_check Andrew Jones
2022-10-23 19:32 ` Conor Dooley [this message]
2022-10-21 10:59 ` [PATCH 3/3] RISC-V: Ensure Zicbom has a valid block size Andrew Jones
2022-10-23 19:38 ` Conor Dooley
2022-10-24 7:09 ` Andrew Jones
2022-10-24 8:17 ` Conor Dooley
2022-10-24 8:35 ` Andrew Jones
2022-10-24 9:26 ` Conor Dooley
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=Y1WW1v5T6IYSGN6G@spud \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=heiko@sntech.de \
--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.