Nathan Lynch [off-list ref] writes:

Michael Ellerman [off-list ref] writes:

quoted

Create a hardware description string, which we will use to record
various details of the hardware platform we are running on.

Print the accumulated description at boot, and use it to set the generic
description which is printed in oopses.

To begin with add ppc_md.name, aka the "machine description".

Example output at boot with the full series applied:

  Linux version 6.0.0-rc2-gcc-11.1.0-00199-g893f9007a5ce-dirty (michael@alpine1-p1) (powerpc64-linux-gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #844 SMP Thu Sep 29 22:29:53 AEST 2022
  Hardware name: model:'IBM pSeries (emulated by qemu)' cpu:'POWER8 (raw)' pvr:0x4d0200 lpvr:0xf000004 of:'SLOF,HEAD' machine:pSeries
  printk: bootconsole [udbg0] enabled

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/include/asm/setup.h   |  2 ++
 arch/powerpc/kernel/setup-common.c | 19 ++++++++++++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

v2: Print the string at boot as suggested by Nathan.

Thanks!

I've booted the series on P8 and P9 LPARs:

Hardware name: model:'IBM,8408-E8E' cpu:'POWER8E (raw)' pvr:0x4b0201 lpvr:0xf000004 of:'IBM,FW860.50 (SV860_146)' hv:'phyp' machine:pSeries

Hardware name: model:'IBM,9040-MR9' cpu:'POWER9 (raw)' pvr:0x4e2102 lpvr:0xf000005 of:'IBM,FW950.01 (VM950_047)' hv:'phyp' machine:pSeries

Not on objection but just an FYI: we're already very close to exceeding
the arch description buffer's size on PowerVM. Both of the above are
over 120 bytes.

Hmm yeah that's a good point.

I was tossing up whether the tags (model:, cpu: etc) are worth the space
they consume.

I erred on the side of keeping them because although I know what the raw
values mean, I figured other folks might not.

But given we are getting tight for space I might change my mind on that
and just use the values with no tags. It will make the value harder to
parse programmatically, but we will probably never do that anyway.

It also occurs to me that we'll want to rebuild the arch description
string after partition migration. Probably immediately after processing
the device tree updates.

OK I hadn't thought of that.

It won't be entirely straight forward because the existing code wants to
build the value up incrementally, so we have as much info as possible at
any point during the boot.

But we can probably just have a pseries specific routine that
reconstructs the value in a similar format to the existing one after
migration.

cheers