From: Conor Dooley <conor.dooley@microchip.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: Conor Dooley <conor@kernel.org>, Yangyu Chen <cyy@cyyself.name>,
<palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>,
<linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v1 4/7] RISC-V: validate riscv,isa at boot, not during ISA string parsing
Date: Fri, 5 May 2023 08:51:59 +0100 [thread overview]
Message-ID: <20230505-division-antler-9beaf112477c@wendy> (raw)
In-Reply-To: <20230505-b0000d4928c8eedff2ae1f8d@orel>
[-- Attachment #1.1: Type: text/plain, Size: 3453 bytes --]
On Fri, May 05, 2023 at 09:40:22AM +0200, Andrew Jones wrote:
> On Thu, May 04, 2023 at 07:14:23PM +0100, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Since riscv_fill_hwcap() now only iterates over possible cpus, the
> > basic validation of whether riscv,isa contains "rv<width>" can be moved
> > to riscv_early_of_processor_hartid().
> >
> > Further, "ima" support is required by the kernel, so reject any CPU not
> > fitting the bill.
> >
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > arch/riscv/kernel/cpu.c | 8 +++++---
> > arch/riscv/kernel/cpufeature.c | 12 ++++++------
> > 2 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> > index 7030a5004f8e..b0c3ec0f2f5b 100644
> > --- a/arch/riscv/kernel/cpu.c
> > +++ b/arch/riscv/kernel/cpu.c
> > @@ -63,10 +63,12 @@ int riscv_early_of_processor_hartid(struct device_node *node, unsigned long *har
> > pr_warn("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hart);
> > return -ENODEV;
> > }
> > - if (tolower(isa[0]) != 'r' || tolower(isa[1]) != 'v') {
> > - pr_warn("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hart, isa);
> > +
> > + if (IS_ENABLED(CONFIG_32BIT) && strncasecmp(isa, "rv32ima", 7))
> > + return -ENODEV;
> > +
> > + if (IS_ENABLED(CONFIG_64BIT) && strncasecmp(isa, "rv64ima", 7))
>
> 'ima' matches the DT binding pattern requirement and the order required
> by 27.11 "Subset Naming Convention".
Aye, perhaps I should have mentioned it in my commit message that those
particular orders are required by the dt-binding. If the ACPI series
lands before this one does, since I'll have to rebase anyway, I'll add a
mention of the ACPI spec's position.
> If the spec ever squeezes more single
> letter extensions into the front of the ISA string, then we can cross
> that bridge when we get to it.
Perhaps by then we have evolved beyond needing the ISA string!
(A boy can dream)
> > return -ENODEV;
> > - }
> >
> > return 0;
> > }
> > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > index 3ae456413f79..a79c5c52a174 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -130,12 +130,12 @@ void __init riscv_fill_hwcap(void)
> > continue;
> > }
> >
> > - if (IS_ENABLED(CONFIG_32BIT) && strncasecmp(isa, "rv32", 4))
> > - continue;
> > -
> > - if (IS_ENABLED(CONFIG_64BIT) && strncasecmp(isa, "rv64", 4))
> > - continue;
> > -
> > + /*
> > + * For all possible cpus, we have already validated in
> > + * the boot process that they at least contain "rv" and
> > + * whichever of "32"/"64" this kernel supports, and so this
> > + * section can be skipped.
> > + */
> > isa += 4;
>
> When we add RV128 support this will need a tweak, but that's for another
> day.
Yeah, adding 128-bit is so far off that it's not worth considering, but
easily handled in this particular location.
> Since all ISA strings must start with rvXX per the spec, then this
> works for ACPI too, which states the isa string in its ISA string table
> must conform to the unpriv spec.
>
> >
> > bitmap_zero(this_isa, RISCV_ISA_EXT_MAX);
> > --
> > 2.39.2
> >
>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-05-05 7:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 18:14 [PATCH v1 0/7] ISA string parser cleanups++ Conor Dooley
2023-05-04 18:14 ` [PATCH v1 1/7] RISC-V: simplify register width check in ISA string parsing Conor Dooley
2023-05-05 7:04 ` Andrew Jones
2023-05-04 18:14 ` [PATCH v1 2/7] RISC-V: only iterate over possible CPUs in ISA string parser Conor Dooley
2023-05-05 7:07 ` Andrew Jones
2023-05-04 18:14 ` [PATCH v1 3/7] RISC-V: split early & late of_node to hartid mapping Conor Dooley
2023-05-04 18:14 ` [PATCH v1 4/7] RISC-V: validate riscv,isa at boot, not during ISA string parsing Conor Dooley
2023-05-05 7:40 ` Andrew Jones
2023-05-05 7:51 ` Conor Dooley [this message]
2023-05-05 12:40 ` Yangyu Chen
2023-05-05 13:04 ` Conor Dooley
2023-05-04 18:14 ` [PATCH v1 5/7] RISC-V: rework comments in ISA string parser Conor Dooley
2023-05-05 9:12 ` Andrew Jones
2023-05-04 18:14 ` [PATCH v1 6/7] RISC-V: remove decrement/increment dance " Conor Dooley
2023-05-05 11:01 ` Andrew Jones
2023-05-04 18:14 ` [PATCH v1 7/7] RISC-V: always report presence of Zicsr/Zifencei Conor Dooley
2023-05-04 20:38 ` Conor Dooley
2023-05-05 11:11 ` 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=20230505-division-antler-9beaf112477c@wendy \
--to=conor.dooley@microchip.com \
--cc=ajones@ventanamicro.com \
--cc=conor@kernel.org \
--cc=cyy@cyyself.name \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox