From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B42CF3A543A for ; Mon, 22 Jun 2026 10:26:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782123991; cv=none; b=Q3UeOF5iV70A3KhJP/8efTaij640PAX4pNfLPUqfb/rar0O1j22FehWsLtKjzgF1Ak9mpgn0/NC7gaZ6z/M0h0W+ihFBrAHnWugmhvKHwIpE+bj2e1UctZtUsFQamUy94OpkJLuxx8zWJaSJ1KmzafzHjSp42FGFiEhVQat7s5A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782123991; c=relaxed/simple; bh=wxS1GBA5+0T3tdNgKK+Y6NF5mI+zXq9Oddgyf6Zumio=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fYlloBTiipe1/snbyL4vrCnBREPCQN+JzQ+v0nA9o1aFTcyAHCL+F1z4aoYcvaVNyTp8wOugphlMcpyNTg0Q+TfecykqC3M6Qdg3wjGPIJUSSNvSvOy7h3Iplf8DWIHNm05XSl+oxqEBKmPzX+CPVAS7+vtRq7GSCLTeSzfnAjQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=YBncEEiV; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="YBncEEiV" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 07DE41BF7; Mon, 22 Jun 2026 03:26:24 -0700 (PDT) Received: from localhost (unknown [10.2.196.114]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2922A3F632; Mon, 22 Jun 2026 03:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782123988; bh=wxS1GBA5+0T3tdNgKK+Y6NF5mI+zXq9Oddgyf6Zumio=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YBncEEiVS+R/Fj/s7EP0mJW94iPEi1PFC6YWV5jT7AM51VUXtZ2p7ZAB9sSBgQTR8 iTeArdRGQWNfkgmOaRcvq5llKVbE+Qf5H2BnrIAKiGowCCu2DQ8kzEb7RhciVqAdR0 Xij3gQZmxGecg+ss08VPVZAHzXZCbdV5BiQYiCF0= Date: Mon, 22 Jun 2026 11:26:25 +0100 From: Leo Yan To: Mike Leach Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, james.clark@linaro.org Subject: Re: [PATCH v3 1/1] coresight: fix issue where coresight component has no claimtags Message-ID: <20260622102625.GF31870@e132581.arm.com> References: <20260619160148.499223-1-mike.leach@arm.com> <20260619160148.499223-2-mike.leach@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260619160148.499223-2-mike.leach@arm.com> 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? 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. 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. 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. [...] > 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. 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? > + > +/* 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? Thanks, Leo