linux-kernel - Re: [PATCH v2 01/12] dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property

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: <20251218-silky-skylark-of-purring-20faa5@sudeepholla>
Date: Thu, 18 Dec 2025 11:37:10 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Yuanfang Zhang <yuanfang.zhang@....qualcomm.com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Mike Leach <mike.leach@...aro.org>,
	James Clark <james.clark@...aro.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Leo Yan <leo.yan@...ux.dev>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>, kernel@....qualcomm.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, maulik.shah@....qualcomm.com
Subject: Re: [PATCH v2 01/12] dt-bindings: arm: coresight: Add
 'qcom,cpu-bound-components' property

On Thu, Dec 18, 2025 at 12:09:41AM -0800, Yuanfang Zhang wrote:
> Introduce the `qcom,cpu-bound-components` boolean property for CoreSight
> components (TMC, Funnel, and Replicator).
> 
> This property indicates that the component is physically located within a
> CPU cluster power domain. Such components share the power state of the
> cluster and may require special handling (e.g., cross-CPU register
> access) compared to system-wide components.
> 

NACK, and the rationale expressed as a question:

If unique compatibles were required to determine the power domains to which
devices belong, we would have accumulated numerous additional compatibles for
every IP block used on new systems with even slightly different power-domain
configurations—a scenario that occurs frequently. Why, then, is such a
requirement considered necessary in this case?

-- 
Regards,
Sudeep