linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Marc Zyngier <maz@kernel.org>,
	Rongwei Wang <rongwei.wang@linux.alibaba.com>,
	Will Deacon <will@kernel.org>,
	joey.gouly@arm.com, Mark Rutland <mark.rutland@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] arm64: improve display about CPU architecture in cpuinfo
Date: Tue, 8 Mar 2022 17:18:07 +0000	[thread overview]
Message-ID: <YiePz/KpcE/S1+RR@arm.com> (raw)
In-Reply-To: <9296f97c-f894-001c-53e6-41bbfe36ce71@arm.com>

On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote:
> On 2022-03-07 19:30, Arnd Bergmann wrote:
> > On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > 
> > > And arguably it's not even too late, because 10 years ago this *did* say
> > > "AArch64". I don't remember all the exact details behind commit
> > > 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
> > > of a memory to go and look up the git history - but I don't think we
> > > changed any of those fields without a real reason.
> > > 
> > 
> > The patch description does state that this was done for compatibility with
> > 32-bit architectures, which does make some sense. I suppose for similar
> > reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
> > 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
> > 
> > The part that I find more annoying is how we leave out the one bit
> > of information that people are generally looking for in /proc/cpuinfo:
> > the name of the processor. Even though we already know the
> > exact processor type in order to handle the CPU errata, this is
> > always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
> > and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
> > with the revision being the least important bit of information here...
> 
> Eh, it's hardly impossible to recompose a MIDR value from the implementer,
> part, variant and revision fields if one actually needs to. Maybe we could
> null-terminate the raw MIDR value and print it as a string of
> largely-unprintable characters in the "model name" field... I guess that
> might satisfy the crowd who want parity* with x86 CPUID, at least :)

You can get the MIDR from
/sys/devices/system/cpu/cpu*/regs/identification/midr_el1.

As for printing the actual names, we thought we'd leave it to tools like
lscpu. I'm not keen on maintaining a dictionary of MIDR to CPU marketing
names in the kernel, deal with rebranding and so on. For x86 you can get
the name from the CPU itself IIUC, that's not the case for arm.

-- 
Catalin

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

  reply	other threads:[~2022-03-08 17:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07  3:04 [PATCH RFC] arm64: improve display about CPU architecture in cpuinfo Rongwei Wang
2022-03-07  8:43 ` Catalin Marinas
2022-03-07  8:45 ` Marc Zyngier
2022-03-07 12:13   ` Rongwei Wang
2022-03-07 12:23     ` Marc Zyngier
2022-03-07 16:48       ` Robin Murphy
2022-03-07 19:30         ` Arnd Bergmann
2022-03-07 20:05           ` Robin Murphy
2022-03-08 17:18             ` Catalin Marinas [this message]
2022-03-08 17:47               ` Robin Murphy
2022-03-08 17:57             ` Russell King (Oracle)
2022-03-08 19:09               ` Robin Murphy
2022-03-08 17:55           ` Russell King (Oracle)

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=YiePz/KpcE/S1+RR@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rongwei.wang@linux.alibaba.com \
    --cc=will@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).