All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel
@ 2022-04-14 17:30 Niklas Cassel
  2022-05-21 20:46 ` Palmer Dabbelt
  0 siblings, 1 reply; 4+ messages in thread
From: Niklas Cassel @ 2022-04-14 17:30 UTC (permalink / raw)
  To: Paul Walmsley, Palmer Dabbelt, Albert Ou; +Cc: Niklas Cassel, linux-riscv

Currently on a 64-bit kernel built without CONFIG_MMU, /proc/cpuinfo will
show the current MMU mode as sv57.

While the device tree property "mmu-type" does have a value "riscv,none" to
describe a CPU without a MMU, since commit 73c7c8f68e72 ("riscv: Use
pgtable_l4_enabled to output mmu_type in cpuinfo"), we no longer rely on
device tree to output the MMU mode. (Not even for CONFIG_32BIT.)

Therefore, instead of readding code to look at the "mmu-type" device tree
property, let's continue with the existing convention to use fixed values
for configurations where we don't determine the MMU mode at runtime.

Add a new fixed value for !CONFIG_MMU in order to output the correct
MMU mode in cpuinfo.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
---
 arch/riscv/kernel/cpu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index ccb617791e56..ecfb3e85ffb2 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -138,6 +138,7 @@ static void print_mmu(struct seq_file *f)
 {
 	char sv_type[16];
 
+#ifdef CONFIG_MMU
 #if defined(CONFIG_32BIT)
 	strncpy(sv_type, "sv32", 5);
 #elif defined(CONFIG_64BIT)
@@ -148,6 +149,9 @@ static void print_mmu(struct seq_file *f)
 	else
 		strncpy(sv_type, "sv39", 5);
 #endif
+#else
+	strncpy(sv_type, "none", 5);
+#endif /* CONFIG_MMU */
 	seq_printf(f, "mmu\t\t: %s\n", sv_type);
 }
 
-- 
2.35.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel
  2022-04-14 17:30 [PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel Niklas Cassel
@ 2022-05-21 20:46 ` Palmer Dabbelt
  2022-05-22  8:25   ` Atish Patra
  2022-05-23 15:29   ` Niklas Cassel
  0 siblings, 2 replies; 4+ messages in thread
From: Palmer Dabbelt @ 2022-05-21 20:46 UTC (permalink / raw)
  To: niklas.cassel; +Cc: Paul Walmsley, aou, niklas.cassel, linux-riscv

On Thu, 14 Apr 2022 10:30:36 PDT (-0700), niklas.cassel@wdc.com wrote:
> Currently on a 64-bit kernel built without CONFIG_MMU, /proc/cpuinfo will
> show the current MMU mode as sv57.
>
> While the device tree property "mmu-type" does have a value "riscv,none" to
> describe a CPU without a MMU, since commit 73c7c8f68e72 ("riscv: Use
> pgtable_l4_enabled to output mmu_type in cpuinfo"), we no longer rely on
> device tree to output the MMU mode. (Not even for CONFIG_32BIT.)
>
> Therefore, instead of readding code to look at the "mmu-type" device tree
> property, let's continue with the existing convention to use fixed values
> for configurations where we don't determine the MMU mode at runtime.
>
> Add a new fixed value for !CONFIG_MMU in order to output the correct
> MMU mode in cpuinfo.

There's really two ideas as to what /proc/cpuinfo should be: do we show 
what the HW has, or what we userspace sees.  This sort of thing is a 
perfect example of that split.  We've been kind of vague about this in 
the past, but IMO putting what userspace sees in /proc/cpuinfo (and 
HWCAP, etc) is the right way to go.  That does hide a bit from userspace 
WRT what hardware it's running on, but it's more in line with the design 
of RISC-V (ie, a lot is hidden from userspace).

I've put this on for-next.

Thanks!

> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> ---
>  arch/riscv/kernel/cpu.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index ccb617791e56..ecfb3e85ffb2 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -138,6 +138,7 @@ static void print_mmu(struct seq_file *f)
>  {
>  	char sv_type[16];
>
> +#ifdef CONFIG_MMU
>  #if defined(CONFIG_32BIT)
>  	strncpy(sv_type, "sv32", 5);
>  #elif defined(CONFIG_64BIT)
> @@ -148,6 +149,9 @@ static void print_mmu(struct seq_file *f)
>  	else
>  		strncpy(sv_type, "sv39", 5);
>  #endif
> +#else
> +	strncpy(sv_type, "none", 5);
> +#endif /* CONFIG_MMU */
>  	seq_printf(f, "mmu\t\t: %s\n", sv_type);
>  }

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel
  2022-05-21 20:46 ` Palmer Dabbelt
@ 2022-05-22  8:25   ` Atish Patra
  2022-05-23 15:29   ` Niklas Cassel
  1 sibling, 0 replies; 4+ messages in thread
From: Atish Patra @ 2022-05-22  8:25 UTC (permalink / raw)
  To: Palmer Dabbelt; +Cc: niklas.cassel, Paul Walmsley, Albert Ou, linux-riscv

On Sat, May 21, 2022 at 1:47 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Thu, 14 Apr 2022 10:30:36 PDT (-0700), niklas.cassel@wdc.com wrote:
> > Currently on a 64-bit kernel built without CONFIG_MMU, /proc/cpuinfo will
> > show the current MMU mode as sv57.
> >
> > While the device tree property "mmu-type" does have a value "riscv,none" to
> > describe a CPU without a MMU, since commit 73c7c8f68e72 ("riscv: Use
> > pgtable_l4_enabled to output mmu_type in cpuinfo"), we no longer rely on
> > device tree to output the MMU mode. (Not even for CONFIG_32BIT.)
> >
> > Therefore, instead of readding code to look at the "mmu-type" device tree
> > property, let's continue with the existing convention to use fixed values
> > for configurations where we don't determine the MMU mode at runtime.
> >
> > Add a new fixed value for !CONFIG_MMU in order to output the correct
> > MMU mode in cpuinfo.
>
> There's really two ideas as to what /proc/cpuinfo should be: do we show
> what the HW has, or what we userspace sees.  This sort of thing is a
> perfect example of that split.  We've been kind of vague about this in
> the past, but IMO putting what userspace sees in /proc/cpuinfo (and
> HWCAP, etc) is the right way to go.  That does hide a bit from userspace
> WRT what hardware it's running on, but it's more in line with the design
> of RISC-V (ie, a lot is hidden from userspace).
>

How about vendor id, arch id & implementation id ? Looking at the
/proc/cpuinfo output on arm64/x86,
it seems to print related information there.
---------------------------------------------------
/proc/cpuinfo output in x86
---------------------------------------------------
processor       : 31
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Gold 6246R CPU @ 3.40GHz
---------------------------------------------------
/proc/cpuinfo output in aarm64
---------------------------------------------------
ubuntu@ubuntu:~$ cat /proc/cpuinfo
processor       : 0
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0xd07
CPU revision    : 0
---------------------------------------------------


> I've put this on for-next.
>
> Thanks!
>
> > Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> > ---
> >  arch/riscv/kernel/cpu.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> > index ccb617791e56..ecfb3e85ffb2 100644
> > --- a/arch/riscv/kernel/cpu.c
> > +++ b/arch/riscv/kernel/cpu.c
> > @@ -138,6 +138,7 @@ static void print_mmu(struct seq_file *f)
> >  {
> >       char sv_type[16];
> >
> > +#ifdef CONFIG_MMU
> >  #if defined(CONFIG_32BIT)
> >       strncpy(sv_type, "sv32", 5);
> >  #elif defined(CONFIG_64BIT)
> > @@ -148,6 +149,9 @@ static void print_mmu(struct seq_file *f)
> >       else
> >               strncpy(sv_type, "sv39", 5);
> >  #endif
> > +#else
> > +     strncpy(sv_type, "none", 5);
> > +#endif /* CONFIG_MMU */
> >       seq_printf(f, "mmu\t\t: %s\n", sv_type);
> >  }
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel
  2022-05-21 20:46 ` Palmer Dabbelt
  2022-05-22  8:25   ` Atish Patra
@ 2022-05-23 15:29   ` Niklas Cassel
  1 sibling, 0 replies; 4+ messages in thread
From: Niklas Cassel @ 2022-05-23 15:29 UTC (permalink / raw)
  To: Palmer Dabbelt; +Cc: Paul Walmsley, aou, linux-riscv

On Sat, May 21, 2022 at 01:46:43PM -0700, Palmer Dabbelt wrote:
> On Thu, 14 Apr 2022 10:30:36 PDT (-0700), niklas.cassel@wdc.com wrote:
> > Currently on a 64-bit kernel built without CONFIG_MMU, /proc/cpuinfo will
> > show the current MMU mode as sv57.
> > 
> > While the device tree property "mmu-type" does have a value "riscv,none" to
> > describe a CPU without a MMU, since commit 73c7c8f68e72 ("riscv: Use
> > pgtable_l4_enabled to output mmu_type in cpuinfo"), we no longer rely on
> > device tree to output the MMU mode. (Not even for CONFIG_32BIT.)
> > 
> > Therefore, instead of readding code to look at the "mmu-type" device tree
> > property, let's continue with the existing convention to use fixed values
> > for configurations where we don't determine the MMU mode at runtime.
> > 
> > Add a new fixed value for !CONFIG_MMU in order to output the correct
> > MMU mode in cpuinfo.
> 
> There's really two ideas as to what /proc/cpuinfo should be: do we show what
> the HW has, or what we userspace sees.  This sort of thing is a perfect
> example of that split.  We've been kind of vague about this in the past, but
> IMO putting what userspace sees in /proc/cpuinfo (and HWCAP, etc) is the
> right way to go.  That does hide a bit from userspace WRT what hardware it's
> running on, but it's more in line with the design of RISC-V (ie, a lot is
> hidden from userspace).
> 
> I've put this on for-next.

Thank you Palmer!

I did send out (somewhat) related device tree binding fix:
https://lore.kernel.org/linux-riscv/YoH9TE%2F4ruFQw3fV@x1-carbon/T/#m894179b986b2e1ef8ef43dd4a865f872e2564c18

Any chance of that getting picked up as well?


Kind regards,
Niklas
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-05-23 15:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-14 17:30 [PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel Niklas Cassel
2022-05-21 20:46 ` Palmer Dabbelt
2022-05-22  8:25   ` Atish Patra
2022-05-23 15:29   ` Niklas Cassel

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.