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 10:04, Konrad Dybcio wrote:
> On 10/28/25 9:36 AM, Krzysztof Kozlowski wrote:
>> On 28/10/2025 09:29, Krzysztof Kozlowski wrote:
>>> On Mon, Oct 27, 2025 at 02:22:49PM -0700, Anjelique Melendez wrote:
>>>> Document the Kaanapali and Glymur compatibles used to describe the PMIC
>>>> glink on each platform.
>>>> Kaanapali will have the same battery supply properties as sm8550 platforms
>>>> so define qcom,sm8550-pmic-glink as fallback for Kaanapali.
>>>> Glymur will have the same battery supply properties as x1e80100 platforms
>>>> so define qcom,x1e80100-pmic-glink as fallback for Glymur.
>>>
>>> What does it mean "battery supply properties"? Binding does not define
>>> them, so both paragraphs do not help me understanding the logic behind
>>> such choice at all.
>>>
>>> What are you describing in this binding? Battery properties? No, battery
>>> properties go to the monitored-battery, right? So maybe you describe SW
>>> interface...
>>
>> Or maybe you describe the device that it is different? >
> 
> Certain versions of the pmic-glink stack expose services (such as battmgr)
> which support different features (e.g. 8550 exposes state of health and
> charge control, x1e exposes charge control, 8280 exposes neither)
> 
> There seems to be a similar situation here

Then say that. Otherwise it feels like describing current Linux
implementation and that would be obvious no-go. Why? Because then
argument is: change Linux driver implementation.

> 
>>>>
>>>> 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)?

Easier for you?

Why nitpicking on wording "generation" instead of explaining the
problems or issues with bindings...


Best regards,
Krzysztof