I also really dislike this. What's the preferred way to identify the
SoC
from userspace?
/proc/cpuinfo? ;)
The *SoC*!
For an non-firmware specific case, I'd say soc_device should be. I'd
guess ACPI systems don't use it and for them it's dmidecode typically.
The other problem I have with soc_device is it is optional.
Hi Will,
John -- what do you think about using soc_device to expose this
information,
with ACPI systems using DMI data instead?
Generally I don't think that DMI is reliable, and I saw this as the
least preferred choice. I'm looking at the sysfs DMI info for my dev
board, and I don't even see anything like a SoC identifier.
As for the event_source device sysfs identifier file, it would not
always contain effectively the same as the SoC ID.
Certain PMUs which I'm interested in plan to have probe-able
identification info available in future.
BTW, Shaokun now tells me that the HiSi uncore PMU HW have such
registers to identify the implementation. I didn't know.
So we could add that identifier file for those PMUs as proof-of-concept,
exposing that register.
As for other PMUs which I'm interested in, again, future versions should
have such registers to self-identify.
So using something derived from the DT compat string would hopefully be
the uncommon case.
Cheers,
John
- Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU ident... John Garry
-