Re: [PATCH RFC] arm64: improve display about CPU architecture in cpuinfo

[Robin Murphy]

On 2022-03-07 19:30, Arnd Bergmann wrote:
> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <robin.murphy@xxxxxxx> 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 :)

Robin.


* Of course this is a complete lie, because every time that comes up 
it's always really about the microarchitecture (which Arm's CPU core 
marketing names represent), where x86 is perfectly on par with arm64 
with its equivalently-inscrutable "cpu family" and "model" numbers, 
rather than cool microarchitecture names like "Sausage Lake" or whatever...