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] [day] [month] [year] [list]
Message-ID: <b5ecf5e7-4dc4-41ac-9b56-7c52afacb950@oss.qualcomm.com>
Date: Thu, 6 Nov 2025 18:16:41 +0800
From: "Aiqun(Maria) Yu" <aiqun.yu@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>,
        Jingyi Wang <jingyi.wang@....qualcomm.com>
Cc: 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 11/6/2025 5:06 AM, Bjorn Andersson wrote:
> On Tue, Nov 04, 2025 at 01:35:01PM +0800, Jingyi Wang wrote:
>>
>>
>> On 11/4/2025 12:02 PM, Bjorn Andersson wrote:
>>> On Tue, Nov 04, 2025 at 11:34:25AM +0800, Aiqun(Maria) Yu wrote:
>>>> On 9/25/2025 7:23 AM, Jingyi Wang wrote:
>>>>> Document the qcom,tcsr-kaanapali compatible, tcsr will provide various
>>>>> control and status functions for their peripherals.
>>>>>
>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@....qualcomm.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml | 1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
>>>>> index 14ae3f00ef7e..ae55b0a70766 100644
>>>>> --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
>>>>> +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
>>>>> @@ -48,6 +48,7 @@ properties:
>>>>>            - qcom,tcsr-ipq8064
>>>>>            - qcom,tcsr-ipq8074
>>>>>            - qcom,tcsr-ipq9574
>>>>> +          - qcom,tcsr-kaanapali
>>>>
>>>> It looks good to me. Glymur didn't have this functionality verified yet.
>>>
>>> You spelled Reviewed-by: Aiqun Yu <..> wrong.
>>>
>>>> Remind for review.
>>>
>>> No need for that, reviewers will review when they have time.
>>>
>>>>
>>
>> Hi Bjorn,
>>
>>>
>>> But that said, most modern additions to this binding follow the common
>>> format of qcom,<soc>-<block>.
>>>
>>> So I would prefer this to be qcom,kaanapali-tcsr.
>>>
>>> Regards,
>>> Bjorn
>>>
>>
>> qcom,tcsr-kaanapali is used to distinguish with binding for GCC:
>> https://lore.kernel.org/all/20251030-gcc_kaanapali-v2-v2-2-a774a587af6f@oss.qualcomm.com/
>>
> 
> So, qcom,kaanapali-tcsr is the clock controller region of TCSR and
> qcom,tcsr-kaanapali is the non-clock controller region of TCSR?
> 
> Sorry for not understanding that earlier, but this doesn't work for me.
> 
> It's a bit of a lie that TCSR_MUTEX is a separate node in devicetree,
> but it's always an nice chunk of 256K in the beginning (or end in some
> cases?) of TCSR. But for the rest, there should be a single tcsr node in
> DeviceTree and that one node should be a syscon and a clock controller.

I've been dive deeply on this tcsr block. And actually the tcsr clock
controller part is a very small trunk size(0x1c) of the tcsr block. And
this block have contain other multiple purposed sys registers. So maybe
we can have a more discussion on how to have device tree node describe
this situation? It is not straight forward that to have a non-tcsrcc
related area being described in tcsrcc.

What about option 1 (tcsr_mutex + tcsr_dload_syscon + tcsrcc):
tcsr_mutex: hwlock@...0000 {
	compatible = "qcom,tcsr-mutex";
	reg = <0x0 0x01f40000 0x0 0x20000>;
	#hwlock-cells = <1>;
};

tcsr_dload: syscon@...0000 {
	compatible = "qcom,tcsr-kaanapali", "syscon";
	reg = <0x0 0x1fc0000 0x0 0x30000>;
};

tcsrcc: clock-controller@...5044 {
	compatible = "qcom,kaanapali-tcsr", "syscon";
	reg = <0x0 0x01fd5044 0x0 0x1c>;
...
};

What about option 2 (tcsr whole block + tcsr_mutex  + tcsrcc):

tcsr: syscon@...0000 {
	compatible = "qcom,tcsr-kaanapali", "syscon";
	reg = <0x0 0x1f40000 0x0 0xC0000>; //align with the whole hardware
block design.
};

tcsr_mutex: hwlock@...0000 {
	compatible = "qcom,tcsr-mutex";
	reg = <0x0 0x01f40000 0x0 0x20000>;
	#hwlock-cells = <1>;
};

tcsrcc: clock-controller@...5044 {
	compatible = "qcom,kaanapali-tcsr", "syscon";
	reg = <0x0 0x01fd5044 0x0 0x1c>;
...
};

> 
> Regards,
> Bjorn
> 
>> Thanks,
>> Jingyi
>>
>>>>>            - qcom,tcsr-mdm9615
>>>>>            - qcom,tcsr-msm8226
>>>>>            - qcom,tcsr-msm8660
>>>>>
>>>>> ---
>>>>> base-commit: ae2d20002576d2893ecaff25db3d7ef9190ac0b6
>>>>> change-id: 20250917-knp-mfd-4dd3c81e6b9b
>>>>>
>>>>> Best regards,
>>>>
>>>>
>>>> -- 
>>>> Thx and BRs,
>>>> Aiqun(Maria) Yu
>>
-- 
Thx and BRs,
Aiqun(Maria) Yu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ