Why don't we just expose SMMU_IIDR in the SMMUv3 PMU directory, so that
you can key off that?
That does not sound like a standard sysfs interface.
It's standard in the sense that PMUs already have their own directory under
sysfs where you can put things.
dumping ground for all sorts of PMU-specific information.
On the other hand, saying "please go figure out which SoC you're on"
certainly isn't standard and is likely to lead to unreliable, spaghetti
Anyway, I don't think that works for every case, quoting from
"> Note: I do acknowledge that an overall issue is that we assume all PMCG
IMP DEF events are same for a given SMMU model.
That assumption does technically fail already - I know MMU-600 has
different IMP-DEF events for its TCU and TBUs, however as long as we can
get as far as "this is some part of an MMU-600" the driver should be
able to figure out the rest ..."
Perhaps I'm misreading this, but it sounds like if you knew it was an
MMU-600 then you'd be ok. I also don't understand how a SoC ID makes things
any easier in this regard.
So even if it is solvable here, the kernel driver(s) will need to be
reworked. And that is just solving one case in many.
PMU drivers will need to expose more information to userspace so that they
can be identified more precisely, yes. I wouldn't say they would need to be
I'm nervous about coming up with a global "SYSID"
when we don't have the ability to standardise anything in that space.
I understand totally, especially if any sysid is based on DT bindings.
Well if this is going to be ACPI-only then it's a non-starter.
But this is some sort of standardization:
https://developer.arm.com/docs/den0028/c, see SMCCC_ARCH_SOC_ID
Yay, firmware :/
> Even if this was widely implemented (it's not),
I still think that it's
the wrong level of abstraction.
and predicate everything off the SoC ID?