linux-kernel - Re: [PATCH] dt-bindings: mfd: qcom,tcsr: Add compatible for Kaanapali

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: <715b0dfd-cd75-401a-acac-0e4ea373dc7d@kernel.org>
Date: Thu, 13 Nov 2025 18:01:00 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: "Aiqun(Maria) Yu" <aiqun.yu@....qualcomm.com>,
 Bjorn Andersson <andersson@...nel.org>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Jingyi Wang <jingyi.wang@....qualcomm.com>, Lee Jones <lee@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com,
 yijie.yang@....qualcomm.com
Subject: Re: [PATCH] dt-bindings: mfd: qcom,tcsr: Add compatible for Kaanapali

On 13/11/2025 17:59, Krzysztof Kozlowski wrote:
>>> This is what we have for Hamoa:
>>>
>>> tcsr_mutex: hwlock@...0000 {
>>>         compatible = "qcom,tcsr-mutex";
>>>         reg = <0 0x01f40000 0 0x20000>;
>>>         #hwlock-cells = <1>;
>>> };
>>>
>>> tcsr: clock-controller@...0000 {
>>
>>
>> It is not a clock-controller start from 0x1fc0000.
>>
>>>         compatible = "qcom,x1e80100-tcsr", "syscon";
>>>         reg = <0 0x01fc0000 0 0x30000>;
>>
>> This is what we have a discussion initialized here:
>> "qcom,<platform>-tcsr" is only a tcsr clock controller binder, reference
>> from [1].
>> "qcom,tcsr-<platform>" is a common tcsr block. reference current binding
>> patch.

I forgot to trim the quote and paste here one more thing - you
completely miss the history, so quoting:

"The TCSR block is purely configuration block and should not have
children.  Any child device should be simply moved outside of TCSR
syscon block."

This is about this binding. If you claim to make it something else, you
are basically changing the meaning of the binding now.


>>
>> For below hardware block information, is it really a recommendation to
>> combine the tscr block with tcsr clock controller all together?
>> ______________________
>> |             |       |
>> | TCSR_MUTEX  | mutex |
>> |_____________|_______|
>> |	      |       |
>> | RANDOM_REGS |       |
>> |_____________|       |
>> |	      |       |
>> | TCSR_CLKS   | tcsr  |
>> |_____________|       |
>> |	      |       |
>> | RANDOM_REGS |       |
>> |_____________|_______|
>>
>> [1]https://lore.kernel.org/all/20251030-gcc_kaanapali-v2-v2-2-a774a587af6f@oss.qualcomm.com/
>>
>>
>>>         clocks = <&rpmhcc RPMH_CXO_CLK>;
>>>         #clock-cells = <1>;
>>>         #reset-cells = <1>;
>>> };
>>>
>>> This is exactly what I suggested above and Konrad is asking you why
>>> this doesn't work for Kaanapali. The addresses are even the same, what
>>> is the problem?
>>
>> The problem is the current patchset document a separate tcsr block as a
>> mfd. While the suggestion here is to use the tcsr clock controller
> 
> There is no MFD. Don't use that term in context of supporting a change.
> But regardless, this documents only random regs.
> 
>> binding to document the whole tcsr block which is not belonged to tcsr
>> clock controller.
> 
> I don't understand whether you claim this patch as "this suggestion" or
> something else.
> 
> 
> Best regards,
> Krzysztof


Best regards,
Krzysztof