linux-kernel - Re: [PATCH v6 2/2] coresight: cti: Add Qualcomm extended CTI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ9a7VgYoSZPsm1jPniVZWZk7MHRAsRJwQGBxyNmndCcfnso2g@mail.gmail.com>
Date: Mon, 8 Dec 2025 14:25:05 +0000
From: Mike Leach <mike.leach@...aro.org>
To: Leo Yan <leo.yan@....com>
Cc: Yingchao Deng <yingchao.deng@....qualcomm.com>, 
	Suzuki K Poulose <suzuki.poulose@....com>, James Clark <james.clark@...aro.org>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, 
	Tingwei Zhang <tingwei.zhang@....qualcomm.com>, quic_yingdeng@...cinc.com, 
	coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	Jinlong Mao <jinlong.mao@....qualcomm.com>, Mao Jinlong <quic_jinlmao@...cinc.com>
Subject: Re: [PATCH v6 2/2] coresight: cti: Add Qualcomm extended CTI support

Hi Leo,

On Fri, 5 Dec 2025 at 10:27, Leo Yan <leo.yan@....com> wrote:
>
> On Thu, Dec 04, 2025 at 03:07:10PM +0000, Mike Leach wrote:
>
> [...]
>
> > > > > > +             /*
> > > > > > +              * QCOM CTI does not implement Claimtag functionality as
> > > > > > +              * per CoreSight specification, but its CLAIMSET register
> > > > > > +              * is incorrectly initialized to 0xF. This can mislead
> > > > > > +              * tools or drivers into thinking the component is claimed.
> > > > > > +              *
> > > > > > +              * Reset CLAIMSET to 0 to reflect that no claims are active.
> > > > > > +              */
> > > > > > +             writel_relaxed(0, drvdata->base + CORESIGHT_CLAIMSET);
> > > > >
> > > > > I am confused for this.  If QCOM CTI does not implement claim tag,
> > > > > then what is the designed register at the offset CORESIGHT_CLAIMSET?
> > > > >
> > > > > Should you bypass all claim tag related operations for QCOM CTI case?
> > > > > (I don't see you touch anything for claim and declaim tags).
> > > > >
> > > >
> > > > The patch I have created to handle systems without correct claim tag
> > > > operation is a dependency for this patch set. Thus no need for
> > > > override here as the core code will handle this correctly.
> > > >
> > > > The only issue is ensuring the non-CTI spec implementation will result
> > > > in the correct detection of no claim tags present.
> > >
> > > Your patch works only when a module has implemented claim registers.
> > >
> >
> > Per the Coresight spec - unimplemented registers must be RAZ/WI- so
> > this still works for non implemented claim registers.
>
> QCOM CTI does not follow the spec in two aspects:
>
> - Given the patch's comment: "QCOM CTI does not implement Claim tag
>   functionality as per CoreSight specification", I am suspect the CLAIM
>   registers are not implemented at all in QCOM CTI.
>
> - It neither follows up the "unimplemented registers must be RAZ/WI" -
>   the patch says its reset value is 0xF and then even can write 0 to it.
>

Correct - but my point is that the patch to handle lack of claim tags
does work for both existent claim tags and unimplemented ones, where
the spec is followed.

> > > This leads to two issues: we end up clearing an unknown register in the
> > > CTI driver, and then the coresight core layer assumes it is reading a
> > > claim register even though it is not.
> >
> > Again RAZ will simply read 0x0 - which is an indication that there are
> > no claim bits implemented.
> >
> > >
> > > For QCOM CTI, combined with your patch, I would suggest directly
> > > setting csdev->access.claim_tag_impl to false (perhaps using a helper).
> >
> > That would be a better solution, though as Qcom appear to have
> > implemented a pair of standard RW registers rather than the claim tag
> > functionality, the write solution works for this particular
> > implementation.
>
> If an IP violates both the rules for implemented claim registers and
> the rules for non-implemented claim registers, how can we rely on
> these registers to detect the claim feature?
>
> My feeling is we are building a house on sand - these registers are not
> used for claim tags purpose at all.
>

No they are not, but by either writing the claim tag register with 0,
or by setting the csdev->access.claim_tag_impl to false, this
particular incorrect implementation instance can be made to work with
the existing claim tag code.

There are effectively two issues here:-

1) The existing core code does not correctly handle insufficient claim
tags or none existent claim tag register - per the coresight spec.
This needs fixing for all potential components - not just this one. My
claim tag patch does that.

2) This particular QCom CTI does not implement claim tags correctly.
This particular instance can be made to operate correctly as detailed
above as long as the core code can handle none-existent claim tags.
The alternative is to bracket every claim tag access call with an "if
!qcom_cti" statement. (which is what was happening in earlier
patches).

We need to fix the core code anyway, and the specific QCom CTI can
then be fixed in a single location without changes elsewhere in the
code. This is the cleanest and least disruptive solution.

Regards

Mike


> Thanks,
> Leo



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK