Re: [PATCH 2/2] lscpu-arm: Remove the "Ampere-1a" part.

[Paul Benoit <paul@os.amperecomputing.com>]

Thanks for your input Jeremy and Karel.

I apologize for taking so long to get back to this project.

On 7/14/2025 4:48 PM, Jeremy Linton wrote:
> On 7/14/25 7:16 AM, Karel Zak wrote:
>> On Fri, Jul 11, 2025 at 02:16:48PM -0700, Paul Benoit wrote:
>>> Remove the "Ampere-1a" part.  On newer Ampere Computing systems, the
>>> system/model name will be obtained from /sys/bus/soc/devices/soc0/ 
>>> machine,
>>> that is populated with the ARM SMC CC SOC_ID Name.
>>
>> If I understand correctly, there are old systems without
>> /sys/.../soc0/machine, right? The change will remove Ampere-1a from
>> the lscpu output. This sounds backward incompatible.
> 
> Thats a good point, but as I understand it, Ampere hasn't been happy 
> with the string that is there.
> 
> If its OK to break whatever scripts/etc might depend on it at the 
> moment, why not just update the string.

For SOCs using SMC CC compliant firmware, I do like that having lscpu
use /sys/bus/soc/devices/soc0/machine means that the name for a new
SMC SOC would be displayed without needing to update the lscpu part(s)
table.  Though, I'm concerned that the SMC CC SOC_ID Name won't always
be a direct mapping to a processor/cpu name.  Especially for a SOC that
contains a mix of BIG/little, performance/efficiency, and/or special
purpose cores.  When all the cores of a SOC are the same, then it is
probably ok to equate the SMC CC SOC_ID Name with the processor/cpu part 
name.

For SMC CC compliant SOCs, perhaps it makes more sense to have lscpu
display the /sys/bus/soc/devices/soc0/machine value as a new
"SOC_ID Name" value in a manner similar to the "BIOS Model name"?  Would
changes be required to lscpu to select such a "SOC_ID Name" field from
the lscpu command line, or would it be sufficient to only display this
SOC_ID Name field in lscpu modes where the detailed/complete
cpu/processor information is displayed?  If lscpu were to display the
/sys/bus/soc/devices/soc0/machines value as "SOC_ID Name", then the
Ampere cpus/processor names would need to continue to come from the
lscpu part(s) table. Though, The existing names in the "ampere_part"
table would still need to change.

> 
> Then invert the check so that the /sys/bus entry is preferred?

Prior to my V1 lscpu patch, when I first made some lscpu changes as a
way to test the SMC CC SOC_ID Name kernel changes, I had originally been
checking for /sys/bus/soc/devices/soc0/machine before looking for an
entry in the part(s) table.  My concern with that was for the non-SMC
SOCs, for which there was both a part(s) table entry and
/sys/bus/soc/devices/soc0/machine was set.  If the string in the part(s)
table was not the same as the /sys/bus/soc/devices/soc0/machine string,
lscpu would then be displaying a different string than it had in the
past.  That is why my V1 patch switched to using the
/sys/bus/soc/devices/soc0/machine value only if there wasn't an entry
in the part(s) table.  A way to reduce the risk, of now using
/sys/bus/soc/devices/soc0/machine instead of the part(s) table entry for
a non-SMC SOC, would be for lscpu to only use the
/sys/bus/soc/devices/soc0/machine value if the value of
/sys/devices/soc0/soc_id starts with "jep106:".
Documentation/ABI/testing/sysfs-devices-soc in the Linux kernel tree
says
     "On many of ARM based silicon with SMCCC v1.2+ compliant firmware
     this will contain the SOC ID appended to the family attribute
     to ensure there is no conflict in this namespace across various
     vendors. The format is "jep106:XXYY:ZZZZ" where XX is identity
     code, YY is continuation code and ZZZZ is the SOC ID."

A search of the Linux kernel code confirms that only
drivers/firmware/smccc/soc_id.c is generating/using the "jep106:"
string.