Hi Leo
-----Original Message----- From: Leo Yan leo.yan@arm.com Sent: Monday, June 22, 2026 11:26 AM To: Mike Leach Mike.Leach@arm.com Cc: coresight@lists.linaro.org; linux-arm-kernel@lists.infradead.org; linux- kernel@vger.kernel.org; Suzuki Poulose Suzuki.Poulose@arm.com; james.clark@linaro.org Subject: Re: [PATCH v3 1/1] coresight: fix issue where coresight component has no claimtags
Hi Mike,
On Fri, Jun 19, 2026 at 05:01:48PM +0100, Mike Leach wrote:
[...]
Any device which is not verified to support claim tags, will now get a success return from the claim/disclaim calls.
Do we really want to relax this?
The claim tag specification permits 0-8 claim tags - it is perfectly reasonable to have no claim tags on a device - including an implementation of devices matching ETMs CTIs specification etc designed other than by ARM.
Currently, a correctly specified device with no claim tags will fail in most of our drivers because they all assume all devices have at least two claim tags - to implement the external / self claim standard.
Clearly this does not meet the specification of claim tags. By returning a success call on devices that do not have claim tags this actually simplifies what otherwise would be a much more wide ranging set of changes.
AFAIK, all Arm standard modules should follow the claim tag protocol. SoC specific modules that do not support claim tags should not enable claim tag handling in the first place. In that case, they would not need any claim tag-related operations.
Claim tag checks are endemic within the drivers - this solution allows for a valid return for devices without claim tags, using the simplest set of changes.
The tricky part is that if a module provides CORESIGHT_CLAIMSET, it likely supports claim tags. Conversely, if a module does not provide CORESIGHT_CLAIMSET, validating claim tags using that offset seems pointless.
CORESIGHT_CLAIMSET is used to determine the number of claimtags available - even if this is 1 or 0. The existence of this register is not proof of the ability to provide enough claim tags to support the protocol we have implemented in the drivers.
As a result, can we constraint to only two cases as below?
enum coresight_claim_tag_info { CS_CLAIM_TAG_STD_PROTOCOL, CS_CLAIM_TAG_IGNORE, };
For CS_CLAIM_TAG_STD_PROTOCOL type, it must pass the validation. Otherwise, the claim tag operations will be totally ignored.
The process is to check the claim tag register on init to determine the number of claim tags, which is cached in the device structure. We use the default 0 enum as not init to allow for the check to be performed only once.
After the check is made and we have determine if the 2 bit protocol can be followed or not.
If the protocol cannot be followed then the set/clear API will return early and allow the drivers to work correctly on devices not supporting the protocol
The override enum value is for devices that either implement a register at the claimtag locations but it does not operate correctly as a claim tag register per spec, or do not implement a valid register at all, which might result in a read failure. The advanced CTI device from qcom I believe falls into the former category, but the latter is also a possibility that is covered by the use case.
[...]
diff --git a/drivers/hwtracing/coresight/coresight-catu.c
b/drivers/hwtracing/coresight/coresight-catu.c
index 43abe13995cf..d8a0ecc502af 100644 --- a/drivers/hwtracing/coresight/coresight-catu.c +++ b/drivers/hwtracing/coresight/coresight-catu.c @@ -574,10 +574,14 @@ static int __catu_probe(struct device *dev, struct
resource *res)
catu_desc.subtype.helper_subtype =
CORESIGHT_DEV_SUBTYPE_HELPER_CATU;
catu_desc.ops = &catu_ops;
- coresight_clear_self_claim_tag(&catu_desc.access); drvdata->csdev = coresight_register(&catu_desc); if (IS_ERR(drvdata->csdev)) ret = PTR_ERR(drvdata->csdev);
- ret = coresight_init_claim_tags(drvdata->csdev);
- if (ret)
coresight_unregister(drvdata->csdev);coresight_init_claim_tags() is much simpler than coresight_register(), this is why we can put coresight_init_claim_tags() before coresight_register() to avoid complex rollback operations for claim init failure.
There is no csdev before coresight register - we save the claim tag operational state in csdev.
I have no strong opinion for this, as the sequence in this patch should can work as well.
+/* helper for checking if claim tag protocol in use */ +static bool coresight_using_claim_tag_protocol(struct coresight_device
*csdev)
+{
- return (bool)(csdev->claim_tag_info ==
CS_CLAIM_TAG_STD_PROTOCOL);
+}
Redundant for bool cast?
Agreed will change
+/* helper to check initialised */ +static bool coresight_claim_tag_noinit(struct coresight_device *csdev) +{
- return (bool)(csdev->claim_tag_info == CS_CLAIM_TAG_UNKNOWN);
Ditto.
+/* cpu bound devices (etms) may need to run on bound cpu */ +int coresight_init_claim_tags_cpu_smp(struct coresight_device *csdev, int
cpu)
+{
- int ret = 0;
- struct cs_claim_tag_init_arg arg = { };
- arg.csdev = csdev;
- ret = smp_call_function_single(cpu,
coresight_init_claim_tags_smp_call,&arg, 1);- if (!ret)
ret = arg.rc;- return ret;
+} +EXPORT_SYMBOL_GPL(coresight_init_claim_tags_cpu_smp);
Do we really need a specific SMP call for this? I understand this will be used by ETMv3/v4 drivers, can we simply init claim tags in the local functions (e.g., etm4_init_arch_data() for ETMv4), same as the current implemenation?
Yes - the purpose here is to avoid having two different APIs to access the claim tags, simplifying the driver. Additionally the early access is before the csdev device is created.
The intention is to move to a check once and save state without needing multiple read checks - which is what happened in the previous iterations of this patch set.
Regards
Mike
Thanks, Leo