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: <20251204103151.GK724103@e132581.arm.com>
Date: Thu, 4 Dec 2025 10:31:51 +0000
From: Leo Yan <leo.yan@....com>
To: Mike Leach <mike.leach@...aro.org>
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

On Thu, Dec 04, 2025 at 09:07:56AM +0000, Mike Leach wrote:

[...]

> > I saw CTI registers are within 4KiB (0x1000), we can don't convert
> > standard regiserts and only convert to QCOM register based on the
> > standard ones.  So you can drop the cti_normal_offset strucuture and
> > only have a cti_reg_qcom_offset[] struct:
> >
> >   static const u32 cti_extended_offset[] = {
> >         [CTIINTACK]             = QCOM_CTIINTACK,
> >         [CTIAPPSET]             = QCOM_CTIAPPSET,
> >         [CTIAPPCLEAR]           = QCOM_CTIAPPCLEAR,
> >         [CTIAPPPULSE]           = QCOM_CTIAPPPULSE,
> >         [CTIINEN]               = QCOM_CTIINEN,
> >         ...
> >   };
> >
> 
> I suggested the dual offset approach a couple of patchset revisions
> ago as it actually simplifies the code & makes it more efficient. The
> offset array in use is set during probe and the remaining code is then
> common to both without lots of "if qcom else " occurences.

AFAICS, we will handle the QCOM CTI particularly in three cases:

  1) The register access;
  2) The claim tag;
  3) Sysfs attr is visible.

Now we are discussing the reigster access.  As suggested, the
"if qcom / else" is encapsulated (e.g., in cti_reg_addr_with_nr()), it
will not spread out.

I'd use standard registers by default and convert to non-standard ones
only when needed.  A new "neutral" index layer seems redundant, as the
existing standard register indexes already serve this purpose.

For the sysfs attrs, it makes sense to use a central place to decide
which knobs are only visible for QCOM CTI, otherwise, we also will not
spread the condition check.

I will reply separately for claim tag issue.

Thanks,
Leo