/proc/cpuinfo should just print all the isa string as an information
instead of determining what is supported or not. ELF hwcap can be
used by the userspace to figure out that.
Simplify the isa string printing by removing the unsupported isa string
print and all related code.
The relevant discussion can be found at
http://lists.infradead.org/pipermail/linux-riscv/2019-September/006702.html
Signed-off-by: Atish Patra <[email protected]>
---
arch/riscv/kernel/cpu.c | 35 ++++-------------------------------
1 file changed, 4 insertions(+), 31 deletions(-)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 7da3c6a93abd..9486c426af86 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -48,49 +48,22 @@ int riscv_of_processor_hartid(struct device_node *node)
static void print_isa(struct seq_file *f, const char *orig_isa)
{
- static const char *ext = "mafdcsu";
- const char *isa = orig_isa;
- const char *e;
-
/*
* Linux doesn't support rv32e or rv128i, and we only support booting
* kernels on harts with the same ISA that the kernel is compiled for.
*/
#if defined(CONFIG_32BIT)
- if (strncmp(isa, "rv32i", 5) != 0)
+ if (strncmp(orig_isa, "rv32i", 5) != 0)
return;
#elif defined(CONFIG_64BIT)
- if (strncmp(isa, "rv64i", 5) != 0)
+ if (strncmp(orig_isa, "rv64i", 5) != 0)
return;
#endif
- /* Print the base ISA, as we already know it's legal. */
+ /* Print the entire ISA as it is */
seq_puts(f, "isa\t\t: ");
- seq_write(f, isa, 5);
- isa += 5;
-
- /*
- * Check the rest of the ISA string for valid extensions, printing those
- * we find. RISC-V ISA strings define an order, so we only print the
- * extension bits when they're in order. Hide the supervisor (S)
- * extension from userspace as it's not accessible from there.
- */
- for (e = ext; *e != '\0'; ++e) {
- if (isa[0] == e[0]) {
- if (isa[0] != 's')
- seq_write(f, isa, 1);
-
- isa++;
- }
- }
+ seq_write(f, orig_isa, strlen(orig_isa));
seq_puts(f, "\n");
-
- /*
- * If we were given an unsupported ISA in the device tree then print
- * a bit of info describing what went wrong.
- */
- if (isa[0] != '\0')
- pr_info("unsupported ISA \"%s\" in device tree\n", orig_isa);
}
static void print_mmu(struct seq_file *f, const char *mmu_type)
--
2.21.0
On Mon, Sep 30, 2019 at 05:23:18PM -0700, Atish Patra wrote:
> /proc/cpuinfo should just print all the isa string as an information
> instead of determining what is supported or not. ELF hwcap can be
> used by the userspace to figure out that.
>
> Simplify the isa string printing by removing the unsupported isa string
> print and all related code.
>
> The relevant discussion can be found at
> http://lists.infradead.org/pipermail/linux-riscv/2019-September/006702.html
This looks good, but can you also rename the orig_isa argument to isa
now that we never modify it?
> /*
> * Linux doesn't support rv32e or rv128i, and we only support booting
> * kernels on harts with the same ISA that the kernel is compiled for.
> */
> #if defined(CONFIG_32BIT)
> - if (strncmp(isa, "rv32i", 5) != 0)
> + if (strncmp(orig_isa, "rv32i", 5) != 0)
> return;
> #elif defined(CONFIG_64BIT)
> - if (strncmp(isa, "rv64i", 5) != 0)
> + if (strncmp(orig_isa, "rv64i", 5) != 0)
> return;
> #endif
And I don't think having these checks here makes much sense. If we want
to check this at all we should do it somewhere in the boot process.
On Tue, 2019-10-01 at 00:02 -0700, Christoph Hellwig wrote:
> On Mon, Sep 30, 2019 at 05:23:18PM -0700, Atish Patra wrote:
> > /proc/cpuinfo should just print all the isa string as an
> > information
> > instead of determining what is supported or not. ELF hwcap can be
> > used by the userspace to figure out that.
> >
> > Simplify the isa string printing by removing the unsupported isa
> > string
> > print and all related code.
> >
> > The relevant discussion can be found at
> > http://lists.infradead.org/pipermail/linux-riscv/2019-September/006702.html
>
> This looks good, but can you also rename the orig_isa argument to isa
> now that we never modify it?
>
Sure. I will do that.
> > /*
> > * Linux doesn't support rv32e or rv128i, and we only support
> > booting
> > * kernels on harts with the same ISA that the kernel is
> > compiled for.
> > */
> > #if defined(CONFIG_32BIT)
> > - if (strncmp(isa, "rv32i", 5) != 0)
> > + if (strncmp(orig_isa, "rv32i", 5) != 0)
> > return;
> > #elif defined(CONFIG_64BIT)
> > - if (strncmp(isa, "rv64i", 5) != 0)
> > + if (strncmp(orig_isa, "rv64i", 5) != 0)
> > return;
> > #endif
>
> And I don't think having these checks here makes much sense.
Correct. As we are dumping the isa information as it is, we should get
rid of these checks as well.
> If we want
> to check this at all we should do it somewhere in the boot process.
riscv_of_processor_hartid() or seems to be a better candidate. We
already check if "rv" is present in isa string or not. I will extend
that to check for rv64i or rv32i. Is that okay ?
--
Regards,
Atish
On Tue, Oct 01, 2019 at 08:22:37AM +0000, Atish Patra wrote:
> riscv_of_processor_hartid() or seems to be a better candidate. We
> already check if "rv" is present in isa string or not. I will extend
> that to check for rv64i or rv32i. Is that okay ?
I'd rather lift the checks out of that into a function that is called
exactly once per hart on boot (and future cpu hotplug).
On Tue, Oct 01, 2019 at 03:10:16AM -0700, [email protected] wrote:
> On Tue, Oct 01, 2019 at 08:22:37AM +0000, Atish Patra wrote:
> > riscv_of_processor_hartid() or seems to be a better candidate. We
> > already check if "rv" is present in isa string or not. I will extend
> > that to check for rv64i or rv32i. Is that okay ?
>
> I'd rather lift the checks out of that into a function that is called
> exactly once per hart on boot (and future cpu hotplug).
Sorry that I am a bit out of date on this. Is there any related
discussion about such checks? Just want to make sure if the check
stops here and will not go any further for extensions, Xs and Zs.
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wed, 2019-10-02 at 09:53 +0800, Alan Kao wrote:
> On Tue, Oct 01, 2019 at 03:10:16AM -0700, [email protected] wrote:
> > On Tue, Oct 01, 2019 at 08:22:37AM +0000, Atish Patra wrote:
> > > riscv_of_processor_hartid() or seems to be a better candidate. We
> > > already check if "rv" is present in isa string or not. I will
> > > extend
> > > that to check for rv64i or rv32i. Is that okay ?
> >
> > I'd rather lift the checks out of that into a function that is
> > called
> > exactly once per hart on boot (and future cpu hotplug).
>
@Christoph
Do you mean to lift the checks for "rv" as well from
riscv_of_processor_hartid as well or leave that as it is?
> Sorry that I am a bit out of date on this. Is there any related
> discussion about such checks?
We are trying to remove all the checks in /proc/cpuinfo and just print
isa as it is. Here is the previous discussion.
http://lists.infradead.org/pipermail/linux-riscv/2019-
September/006702.html
> Just want to make sure if the check
> stops here and will not go any further for extensions, Xs and Zs.
>
At least not here. I don't think we need to check for optional
extensions anywhere except in the extension relevant code.
> > _______________________________________________
> > linux-riscv mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Regards,
Atish
On Wed, Oct 02, 2019 at 06:28:59AM +0000, Atish Patra wrote:
> On Wed, 2019-10-02 at 09:53 +0800, Alan Kao wrote:
> > On Tue, Oct 01, 2019 at 03:10:16AM -0700, [email protected] wrote:
> > > On Tue, Oct 01, 2019 at 08:22:37AM +0000, Atish Patra wrote:
> > > > riscv_of_processor_hartid() or seems to be a better candidate. We
> > > > already check if "rv" is present in isa string or not. I will
> > > > extend
> > > > that to check for rv64i or rv32i. Is that okay ?
> > >
> > > I'd rather lift the checks out of that into a function that is
> > > called
> > > exactly once per hart on boot (and future cpu hotplug).
> >
> @Christoph
> Do you mean to lift the checks for "rv" as well from
> riscv_of_processor_hartid as well or leave that as it is?
Sounds good to me (as a separate patch). Again it makes much more
sense to validate this once early at boot time rather than a function
that can be called many tims during run time.