Suzuki sent me this patch [1] that has the effect of printing the following [2] in the kernel boot log at initialisation time. I think it is quite useful since one can correlate CPU information and ETM engine without having to go back to the DT or having to look at all the tracers in sysFS. On the flip side I'm a little weary (since peripheral numbers are implementation specific) that at one point we may end up with say, a Cortex-A53 with different peripheral IDs or another CPU type advertising a peripheral ID that is already taken.
As I said I think this is a good idea but before applying a change that will be very public I'd like to make sure there aren't any ramification we haven't thought about. Please let me know what you think.
From the patch, it looks like it was already using peripheral ids (e.g. for A53) and is just adding the CPU names. This should be safe as the ids should be unique across CPU products and fixed for any given CPU product.
Having said that, it might be wrong to have this table at all. It's a maintenance overhead to have to keep adding new CPU products to this table (it's a long way from being complete even now, and of course more products will appear). The ETM drivers should be working off the ETM feature identification registers and/or device tree as far as possible, so that a given kernel will automatically work for future CPU products. So whatever we're trying to do by looking at the CPU-specific ids here, it's not the right thing to do. If you find CPU #n has an ETM with features XYZ and want to print a message, you should be able to find CPU #n's CPU type some other way.
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.
Al
Best regards, Mathieu
[1]. https://www.spinics.net/lists/arm-kernel/msg653904.html [2]. https://pastebin.com/gbiLaJHJ