On Tue, Apr 27, 2021 at 06:37:24PM +0100, Robin Murphy wrote:

On 2021-04-02 04:56, Shawn Guo wrote:

quoted

Currently the platdata is being used in different way by SMMU and PMCG
device.  The former uses it for acpi_iort_node pointer passing, while
the later uses it for model identifier.  As it's been seen that the
model identifier is useful for SMMU devices as well, let's consolidate
the platdata use to get it accommodate both acpi_iort_node pointer and
model identifier, so that all IORT devices (SMMU, SMMUv3 and PMCG) pass
platdata in a consistent manner.

With this change, model identifier is not specific to PMCG, so
IORT_SMMU_V3_PMCG_GENERIC gets renamed to IORT_SMMU_GENERIC.  While at
it, the spaces used in model defines are converted to tabs.

SMMUs and PMCGs are deliberately kept distinct because they are not
necessarily equivalent - a PMCG may belong to something other than an SMMU,
(like a root complex or a device with its own TLB), and even a single SMMU
may implement heterogeneous PMCGs (e.g. Arm's MMU-600 has PMCGs in its
control unit and TLB units which count different sets of events). So NAK to
that aspect, sorry.

FWIW this was originally here because we envisaged needing to identify
individual PMCG implementations through a variety of poking at different
fields and tables, so hiding that behind an abstraction in ACPI code seemed
neatest. However, things haven't really panned out that way - now we seem to
have moved more towards describing events in userspace in conjunction with
other system-specific identifiers. If we've no need to identify PMCGs in the
kernel for the sake of exporting imp-def events, then most of the argument
for this PMCG identifier abstraction is gone, and it's looking increasingly
like the HIP08 case deserves to be punted back to the PMCG driver itself as
a one-off erratum workaround.

I think at this point we should accept that if a driver needs to match
*some* platform-specific data for its own internal purposes, the fact that
that data might be the IORT header still doesn't make it "IORT
functionality", and referencing ACPI_SIG_IORT from drivers is a lesser evil
than cluttering up the IORT code with increasing amounts of random stuff
that's outside the scope of the IORT specification itself.

Thanks much for the comments, Robin!  Indeed, it makes more sense to
sort the issue out in qcom driver than IORT code.  v3 is on the way.

Shawn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel