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: <CAJ9a7ViUoSMV_HHKKRMhcQX=isU+feJvwCaVhu-6EBK4QXJbVg@mail.gmail.com>
Date: Tue, 22 Jul 2025 15:56:15 +0100
From: Mike Leach <mike.leach@...aro.org>
To: Leo Yan <leo.yan@....com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>, Mao Jinlong <quic_jinlmao@...cinc.com>, 
	James Clark <james.clark@...aro.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, 
	Yingchao Deng <quic_yingdeng@...cinc.com>, coresight@...ts.linaro.org, 
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: arm: Add Qualcomm extended CTI

On Tue, 22 Jul 2025 at 15:07, Leo Yan <leo.yan@....com> wrote:
>
> On Tue, Jul 22, 2025 at 01:00:18PM +0100, Mike Leach wrote:
>
> [...]
>
> > For a change of this magnitude to a CS component, that the ID
> > registers will also have to change. This is a requirement of the
> > Visible Component Architecture in the CoreSight specification.
> > External tools cannot see the device tree.
> >
> > This is effectively no longer an ARM designed component, so the
> > CoreSight specification requires that the DEVARCH register change to
> > show qualcomm as the designer, and the architecture value change to
> > represent this component.
> > DEVID should be used to allow the driver to pick up parameters such as
> > number of triggers as per the existing CTI component.
> >
> > If this component is Coresight compliant then the driver can use the
> > ID registers to configure to the extended trigger architecture.
> >
> > With complete remapping of most of the registers, and the dropping of
> > claim tag compatibility - which appears to be a breach of the
> > CoreSight specification - it may be better to have a completely
> > separate driver for this component.
>
> Good point. I'd like to confirm with the Qualcomm team: apart from the
> differences in register offsets and claim bits, does this CTI module
> have exactly the same bit layout and usage as CTI standard
> implementation?
>
> If yes, then from a maintenance perspective, we probably don't want to
> have two CTI drivers with identical register settings. It seems plausible
> to encapsulate register access and claim logic into several functions.
>
>   void cti_reg_writel(u32 val, struct cti_drvdata *drvdata, bool relax);
>   u32 cti_reg_readl(struct cti_drvdata *drvdata, bool relax);
>   int cti_claim_device(struct cti_drvdata *drvdata);
>   int cti_disclaim_device(struct cti_drvdata *drvdata, bool unlocked);
>
> Thanks,
> Leo

The CTI supports 128 triggers  - which means many more registers to
enable / connect etc.
I need to study the changes to determine if there are functional
differences too.

It might be feasible to divide the code into a common file and a pair
of variants so some is reused.

Mike

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ