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 B908D28BA83; Tue, 3 Feb 2026 09:44:12 +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=1770111854; cv=none; b=gPX2udONWXt7PelE6HpLZjUBzXdmYkBDChKqhzHK7hJuZwNjkJCmAQdL4UOXu/5DypsipOGVHTTdKjlhF5IZZ7sHzqNqaX6c1Z0XfCmjNy5iXkKglJZZcJRNrRE0U6Jaqo5dt9blXZDDpSHIT7+Urt/rjXrHZN6v1MsyaiaihEc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770111854; c=relaxed/simple; bh=LH85J6u+VV+g5aWO2q28Gxqi15HcIPs2peibxluuZDY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UvP00Y0eysWi3rR/P5/hFXYbTXJGbYCh615PzjadmHUKmTuVcEperoCthkukeidU3G3DQS70tRYv84kj9Dfmc/hY1dOpgS98ESUCy52YJm/E7w37buWIPMSOd+LZ9gHFPCVxUEsxPcRTjbsM+s9FS1rpcEXT1r0qBymS7aTr2eg= 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; 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 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 7E187339; Tue, 3 Feb 2026 01:44:05 -0800 (PST) Received: from [10.57.69.219] (unknown [10.57.69.219]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 526223F632; Tue, 3 Feb 2026 01:44:09 -0800 (PST) Message-ID: Date: Tue, 3 Feb 2026 09:44:07 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] dt-binding: document QCOM platforms for CTCU device Content-Language: en-GB To: Konrad Dybcio , Jie Gan , Mike Leach , James Clark , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Tingwei Zhang , Bjorn Andersson , Konrad Dybcio Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260203-enable-ctcu-and-etr-v1-0-a5371a2ec2b8@oss.qualcomm.com> <20260203-enable-ctcu-and-etr-v1-1-a5371a2ec2b8@oss.qualcomm.com> <6019b38d-3a15-41f5-989e-1f576c327446@oss.qualcomm.com> <6c823646-9085-409e-a692-ae3e77347742@oss.qualcomm.com> <5911fe77-fe2c-4321-96a9-a1b6b3b5d1e3@arm.com> From: Suzuki K Poulose In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/02/2026 09:36, Konrad Dybcio wrote: > On 2/3/26 10:31 AM, Suzuki K Poulose wrote: >> On 03/02/2026 09:00, Jie Gan wrote: >>> >>> >>> On 2/3/2026 4:50 PM, Konrad Dybcio wrote: >>>> On 2/3/26 9:08 AM, Jie Gan wrote: >>>>> Document the platforms that fallback to using the qcom,sa8775p-ctcu >>>>> compatible for probing. >>>>> >>>>> Signed-off-by: Jie Gan >>>>> --- >>>>>   Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 4 ++++ >>>>>   1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight- ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight- ctcu.yaml >>>>> index e002f87361ad..68853db52bef 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>> @@ -29,6 +29,10 @@ properties: >>>>>       oneOf: >>>>>         - items: >>>>>             - enum: >>>>> +              - qcom,glymur-ctcu >>>>> +              - qcom,hamoa-ctcu >>>>> +              - qcom,kaanapali-ctcu >>>>> +              - qcom,pakala-ctcu >>>> >>>> Platforms with existing numeric compatibles should continue to use them, >>>> so that the mess is somewhat containable >>> >>> Sure Konrad. So for Pakala, I will change it back to qcom,sm8750-ctcu >> >> Why do we need different compatibles for the others ? Are they not all compliant to the CTCU programming model ? i.e., sa8775p-ctcu ? or even, >> a generic, >> >> qcom,coresight-ctcu > > It's a huge anti-pattern with the DT maintainers, since a compatible is > the only way to effectively differentiate different implementations (i.e. > instances on different SoCs) of an IP block Do you mean, same IP block integrated to different SoC ? Or are they different implementations altogether ? Why are these not applicable for other components ? (e.g., Tnoc, I-Tnoc, TPDA, TPDM etc ?) > > This is important for the case where a DTB is shipped as part of firmware > and can not be replaced - if some quirk needs to be applied retroactively, > we can look for "qcom,glymur-ctcu" without affecting all the 50 other' > users of the effectively-identical IP block Fair enough, thank for the explanation. Kind regards Suzuki > > In this case, we're already reducing the impact on the driver, as that > only looks for the single fallback compatible (qcom,sa8775p-ctcu) > > Konrad