arm64: cpuinfo: Add "model name" in /proc/cpuinfo for 64bit tasks also

From: Sumit Gupta <[email protected]>

Removed restriction of displaying model name for 32 bit tasks only. This can be used for 64 bit tasks as well, and it's useful for some tools that already parse this, such as coreutils uname -p, Ubuntu model name display etc.

It should be like this:

```
$ cat '/proc/cpuinfo' | grep 'model name' | head -n 1
model name : ARMv8 Processor rev X (v8l)
```

---
 arch/arm64/kernel/cpuinfo.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

index 77605aec25fe..d69b4e486098 100644
@@ -148,8 +148,7 @@ static int c_show(struct seq_file *m, void *v)
 		 * "processor".  Give glibc what it expects.
 		 */
 		seq_printf(m, "processor\t: %d\n", i);
-		if (compat)
-			seq_printf(m, "model name\t: ARMv8 Processor rev %d (%s)\n",
+		seq_printf(m, "model name\t: ARMv8 Processor rev %d (%s)\n",
 				   MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);
 
 		seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",

2.17.1

The thread above already has arguments against this patch. Has anything changed since?

Catalin

From reply of the upstream patch:
https://lore.kernel.org/linux-arm-kernel/[email protected]/

Brian Norris wrote:

```
What's the status on this patch? The previous patch (which was accepted
already) is indeed confusing, because ARM32 processes on an ARM64 system
are not necessarily setting PER_LINUX32.

I'm also curious, why was 'model name' removed from ARM64 in the first
place? Plenty of other architectures support a similar property, and
it's useful for some tools that already parse this, such as coreutils
`uname -p` on Gentoo (and presumably others -- my Ubuntu machine must be
similarly patched, as it supports `uname -p` on x86_64).
```

However, the restriction seems not so fairly:
Firstly, the ARM32, which is the purpose of the author making the code works for,
with this restriction, even doesn't work in some cases. Secondly, as the code works for both ARM32 and ARM64, what's the significance of setting
such a restriction?
Thirdly, there're many tools and systems which parse this, so the field actually makes sense.
For example, like what we have written in cpuinfo.c#L148, "Give glibc what it expects".

So, in my option, it's fine to remove the restriction and let it work for both architectures.

How exactly is it useful? It clearly isn't necessary for compatibility, since AArch64 userspace has apparently been running quite happily for 8 years without it. It also doesn't convey anything meaningful to the user, since they already know they're on an Armv8-compatible processor by the fact that they're running AArch64 userspace at all.

Robin.