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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 13/11/2025 17:59, Krzysztof Kozlowski wrote:
>>> This is what we have for Hamoa:
>>>
>>> tcsr_mutex: hwlock@1f40000 {
>>>         compatible = "qcom,tcsr-mutex";
>>>         reg = <0 0x01f40000 0 0x20000>;
>>>         #hwlock-cells = <1>;
>>> };
>>>
>>> tcsr: clock-controller@1fc0000 {
>>
>>
>> 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