Messages in this thread | | | From | John Garry <> | Subject | Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace | Date | Wed, 27 May 2020 15:34:48 +0100 |
| |
>>>> >>>> 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
| |