[PATCH] riscv: Don't output a bogus mmu-type on a no MMU kernel

Niklas Cassel Niklas.Cassel at wdc.com
Mon May 23 08:29:24 PDT 2022


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 at 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


More information about the linux-riscv mailing list