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

On 7/15/2025 5:19 AM, Karel Zak wrote:
> On Mon, Jul 14, 2025 at 03:48:50PM -0500, 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.
> 
> We can update the string to make them happy.
> 
>> If its OK to break whatever scripts/etc might depend on it at the moment,
>> why not just update the string.
>>
>> Then invert the check so that the /sys/bus entry is preferred?
> 
> I still do not understand how a per-CPU identifier can be replaced by
> one soc0 path. What if there is soc1, soc2, etc.?

Yes, I agree that /sys/bus/soc/devices/soc0/machine shouldn't be used
for processors/cpus in soc1..socn unless all physical SOCs are mapped by
soc0.  My recollection is that I only saw the one /sys/bus/devices/soc0
on an SMC compliant system with 2 SOCs.  The smccc_soc_init routine is
what calls soc_device_register once.  The support code for other ARM
SOCs call soc_device_register from a *_probe routine (run once per
SOC?).  As per my other reply in this thread today,
/sys/bus/soc/devices/soc0/machine will only be used for a SMC CC
compliant SOC.

> 
> Anyway, using /sys/bus as the primary source and the hardcoded id_part[]
> array as a fallback seems better than removing anything from id_part[]
> and relying on /sys/bus only.
> 
>      Karel
>