Hi Mike,
On Wed, Oct 22, 2025 at 01:35:46PM +0100, Mike Leach wrote:
[...]
- We can add a new flag ("bool claim_impl" in the struct csdev_access), by default the field will be zero.
I considered a bool - but the correct place for this would be coresight_device - where we keep all the information about the hardware features.
Maybe coresight_device is suitable. But this might require to update furthermore for claim function arguments (e.g., need to pass "csdev" rather than "csdev_access").
- The drivers support claim tags call coresight_clear_self_claim_tag() in probe (see __catu_probe() as an example), we can call a new function coresight_init_claim_tag() to replace it, this function sets "claim_impl" properly and clear the tag if supported.
I considered moving this initialisation to the common coresight code where we create the coresight_device.
Seems to me, this is dangerous. If a module is not CoreSight compliant and claim registers are absent, when access we will get unknown values or even cause serious result (external abort or bus lockup).
[...]
+/*
- Coresight specification defines a maximum of 8 claim tag bits.
- The precise number is implementation defined, and may be obtained by
- reading the CLAIMSET register.
- */
+#define CORESIGHT_CLAIM_BITS_MAX_MASK GENMASK(7, 0) +#define CORESIGHT_CLAIM_SELF_HOSTED_BIT BIT(1)
Now we only care about the self-host bit. Can reuse existed macros ?
I feel that drivers should be written to match the specification - the macros above are a correct mask value per specification and the correct bitfield comparison for the MSBit of the protocol.
The ones below are a protocol masks field, and a specific protocol value that is used in value rather than bit comparisons in the claimtag code. I felt it clearer to differentiate between the uses when reading the code.
How about change CORESIGHT_CLAIM_EXTERNAL and CORESIGHT_CLAIM_SELF_HOSTED to MSBit ?
Thanks, Leo