Re: [PATCH v2 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add Kaanapali and Glymur compatibles

[Krzysztof Kozlowski <krzk@kernel.org>]

On 28/10/2025 23:55, Anjelique Melendez wrote:
> 
> 
> On 10/28/2025 2:30 AM, Krzysztof Kozlowski wrote:
>> On 28/10/2025 10:21, Krzysztof Kozlowski wrote:
>>> On 28/10/2025 10:19, Konrad Dybcio wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>>>>   .../devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml      | 7 +++++++
>>>>>>>>>   1 file changed, 7 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
>>>>>>>>> index 7085bf88afab..c57022109419 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
>>>>>>>>> @@ -37,12 +37,19 @@ properties:
>>>>>>>>>             - const: qcom,pmic-glink
>>>>>>>>>         - items:
>>>>>>>>>             - enum:
>>>>>>>>> +              - qcom,kaanapali-pmic-glink
>>>>>>>>>                 - qcom,milos-pmic-glink
>>>>>>>>>                 - qcom,sm8650-pmic-glink
>>>>>>>>>                 - qcom,sm8750-pmic-glink
>>>>>>>>
>>>>>>>> Why qcom,kaanapali-pmic-glink is not compatible with
>>>>>>>> qcom,sm8750-pmic-glink? If Glymur is compatible with previous
>>>>>>>> generation, I would expect that here too.
>>>>>>>
>>>>>>> And again to re-iterate:
>>>>>>>
>>>>>>> If X1E is compatible with SM8550 AND:
>>>>>>> SM8750 is compatible with SM8550 THEN
>>>>>>> WHY Glymur is compatible with previous generation but Kaanapali is not
>>>>>>> compatible with previous generation?
>>>>>>
>>>>>> The announcement date does not directly correlate to 'generation'
>>>>> I don't know exactly this IP block/component, but in general these SoCs
>>>>> follow some sort of previous design, thus term "generation" is correct
>>>>> in many cases. Anyway don't be picky about wording.
>>>>>
>>>>> You can remove the generation and statement will be the same.
>>>>>
>>>>> If A is compatible with B AND
>>>>> C is compatible with B
>>>>> THEN
>>>>>
>>>>> WHY D is compatible with (A and B) but E is not
>>>>> compatible with (C and B)?
> 
> I think some of the confusion is relating to both UCSI and battmngr aux 
> drivers using SM8550 as compatible strings...
> 
> Really we should be thinking about this as:
> 
> 	SM8750 is compatible with SM8550 UCSI and SM8550 BATTMGR
> 	X1E is compatible with SM8550 UCSI and X1E BATTMGR

That's not what I said there. We don't speak here about these.

We speak ONLY about this compatible. How you map your compatible to
UCSI, BATTMGR, FOO and BAR does not matter, although I asked about
re-using of Kaanapali drvdata in one of my last replies.

> 
> or
> 	A is compatible with B and C
> 	E is compatible with B and D

No, that was just because Konrad got focused on word "generation". Use
my earlier comment.

> 
> 
> More specifically:
> 
> SM8750 has the same UCSI quirks (UCSI_DELAY_DEVICE_PDOS) as SM8550, so 
> we would want to use SM8550 compatible string in UCSI driver.
> SM8750 also exposes the same features, state of health and charge 
> control, in battmgr driver, so should use the SM8550 compatible string 
> for battmgr driver as well.
> 
> Like SM8750, X1E has the same UCSI quirks (UCSI_DELAY_DEVICE_PDOS) as 
> SM8550, so will use the SM8550 compatible.
> BUT X1E only wants to have charge control exposed in battmngr driver. So 
> instead of using the SM8550 compatible, we should use the X1E compatible 
> in battmgr driver [1]
> 
> 
> 
> Now we have Kaanapali and Glymur being introduced...
> 
> Kaanapali IS compatible with SM8750, however since SM8750 did not 
> introduce any new "quirks" or features that Kaanapali should inherit, we 
> can simply define Kaanapali as compatible as SM8550 as well.
> 
> Glymur IS compatible with X1E and since X1E introduces a new "feature" 
> that we would like Glymur to inherit, we need to explicitly defined 
> Glymur as compatible to X1E.

I don't understand whether you are explaining your patch - why it is
done like that - or agreeing that your patch is wrong.

Best regards,
Krzysztof