I agree. The problem here is that the ETM devices are treated as AMBA devices and we rely on the AMBA bus probing (which in turn looks at the PIDs) to match a given device to ETM device.
Even if you're probing the bus you shouldn't need to look at the implementation-specific part of the id. There are generic id registers that let you progressively discover all the ETM features, all the way from generic device class right through to the fact that it's an ETM 4.1 with 6 address comparators etc. You shouldn't ever need to match against a table of implementation-specific ids.
Al
May be we need to get away from the AMBA
frame work and come up with something like the PMU probing, where we probe for the device on each CPU using the ETM feature registers and detect the devices (of course, based on the DT)
I'd think the only reason the CoreSight drivers would need to check for specific CPUs is to work around hardware errata specific to those CPUs - and in that case you would likely want to test the CPU
release/patch/stepping level in more detail.
We have a generic infrastructure in the arm64 kernel for detecting Errata, which could be leveraged to manage the coresight errata work arounds for ETMs. So we don't duplicate something just for us.
Cheers Suzuki