[PATCH v2 0/2] soc: qcom: pmic_glink: Add support for battery management running on SOCCP

[PATCH v2 0/2] soc: qcom: pmic_glink: Add support for battery management running on SOCCP

[Anjelique Melendez]

System On Chip Control Processor (SOCCP) is a subsystem that can have
battery management firmware running on it to support Type-C/PD and
battery charging. Add support for devices, such as Kaanpali and Glymur, 
which are running battery management on SOCCP.

Changes since V1:
  - Corrected bindings dependencies 
  - Renamed pmic_glink_data variables
  - Dropped "soc: qcom: pmic_glink: Add support for SOCCP remoteproc channels"
    since it was applied from its original series: https://lore.kernel.org/all/176157405464.8818.5887965202916918883.b4-ty@kernel.org/
  - Link: https://lore.kernel.org/all/20251017003033.268567-1-anjelique.melendez@oss.qualcomm.com/

Anjelique Melendez (2):
  dt-bindings: soc: qcom: qcom,pmic-glink: Add Kaanapali and Glymur
    compatibles
  soc: qcom: pmic_glink: Add charger PDR service path and service name
    to client data

 .../bindings/soc/qcom/qcom,pmic-glink.yaml    |  7 ++
 drivers/soc/qcom/pmic_glink.c                 | 66 ++++++++++++-------
 2 files changed, 49 insertions(+), 24 deletions(-)

-- 
2.34.1

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

[Anjelique Melendez]

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.

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
               - qcom,x1e80100-pmic-glink
           - const: qcom,sm8550-pmic-glink
           - const: qcom,pmic-glink
+      - items:
+          - enum:
+              - qcom,glymur-pmic-glink
+          - const: qcom,x1e80100-pmic-glink
+          - const: qcom,sm8550-pmic-glink
+          - const: qcom,pmic-glink
 
   '#address-cells':
     const: 1
-- 
2.34.1

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

[Bjorn Andersson]

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.
> 
> 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

This seems pretty reasonable, kaanapali-pmic-glink being "the same" as
sm8550-pmic-glink, just moved to a different core - with the changes
that implies.

>                - qcom,milos-pmic-glink
>                - qcom,sm8650-pmic-glink
>                - qcom,sm8750-pmic-glink
>                - qcom,x1e80100-pmic-glink

Why did we say x1e80100-pmic-glink is "the same" as sm8550-pmic-glink?

>            - const: qcom,sm8550-pmic-glink
>            - const: qcom,pmic-glink
> +      - items:
> +          - enum:
> +              - qcom,glymur-pmic-glink
> +          - const: qcom,x1e80100-pmic-glink

glymur-pmic-glink indeed has parts in common with x1e80100-pmic-glink,
so I guess that makes sense.

> +          - const: qcom,sm8550-pmic-glink

I don't think this should be here.

Regards,
Bjorn

> +          - const: qcom,pmic-glink
>  
>    '#address-cells':
>      const: 1
> -- 
> 2.34.1
> 

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

[Krzysztof Kozlowski]

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...

> 
> 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.

>                - qcom,x1e80100-pmic-glink
>            - const: qcom,sm8550-pmic-glink
>            - const: qcom,pmic-glink
> +      - items:
> +          - enum:
> +              - qcom,glymur-pmic-glink
> +          - const: qcom,x1e80100-pmic-glink
> +          - const: qcom,sm8550-pmic-glink
> +          - const: qcom,pmic-glink
>  
>    '#address-cells':
>      const: 1
> -- 
> 2.34.1
> 

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

[Krzysztof Kozlowski]

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



Best regards,
Krzysztof

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

[Konrad Dybcio]

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

>>>
>>> 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'

Konrad

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

[Krzysztof Kozlowski]

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

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

[Konrad Dybcio]

On 10/28/25 10:16 AM, Krzysztof Kozlowski wrote:
> 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...

What I'm saying is that Kaanapali and Glymur are disjoint projects
that shouldn't be thought of as having a common base

Konrad

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

[Krzysztof Kozlowski]

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)?
>>
>> Easier for you?
>>
>> Why nitpicking on wording "generation" instead of explaining the
>> problems or issues with bindings...
> 
> What I'm saying is that Kaanapali and Glymur are disjoint projects
> that shouldn't be thought of as having a common base


No, please go through my A B C D E list to understand the problem. I did
not suggest what you reply here.

Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

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)?
>>>
>>> Easier for you?
>>>
>>> Why nitpicking on wording "generation" instead of explaining the
>>> problems or issues with bindings...
>>
>> What I'm saying is that Kaanapali and Glymur are disjoint projects
>> that shouldn't be thought of as having a common base
> 
> 
> No, please go through my A B C D E list to understand the problem. I did
> not suggest what you reply here.


Heh, and don't get me started on driver...

{ .compatible = "qcom,glymur-pmic-glink", .data =
&pmic_glink_kaanapali_data },
{ .compatible = "qcom,kaanapali-pmic-glink", .data =
&pmic_glink_kaanapali_data },

So how is now Glymur using Kaanapali, so basically compatible with it?

Even more questions I did not consider.



Best regards,
Krzysztof

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

[Anjelique Melendez]

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

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


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.



If the reuse of SM8550 as compatible in both drivers is causing 
confusion, perhaps we instead add an X1E compatible string to the UCSI 
driver. i.e.

--- a/drivers/usb/typec/ucsi/ucsi_glink.c
+++ b/drivers/usb/typec/ucsi/ucsi_glink.c
@@ -319,6 +319,7 @@ static const struct of_device_id 
pmic_glink_ucsi_of_quirks[] = {
     {.compatible = "qcom,sm8350-pmic-glink", .data = &quirk_sc8180x, },
     {.compatible = "qcom,sm8450-pmic-glink", .data = &quirk_sm8450, },
     {.compatible = "qcom,sm8550-pmic-glink", .data = &quirk_sm8450, },
+   {.compatible = "qcom,x1e80100-pmic-glink", .data = &quirk_sm8450, },
     {}
  };



Then we can have the bindings like:

--- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -29,6 +29,7 @@ properties:
                - qcom,sm8350-pmic-glink
                - qcom,sm8450-pmic-glink
                - qcom,sm8550-pmic-glink
+              - qcom,x1e80100-pmic-glink
            - const: qcom,pmic-glink
        - items:
            - enum:
@@ -37,12 +38,17 @@ properties:
            - const: qcom,pmic-glink
        - items:
            - enum:
+              - qcom,kaanapali-pmic-glink
                - qcom,milos-pmic-glink
                - qcom,sm8650-pmic-glink
                - qcom,sm8750-pmic-glink
-              - qcom,x1e80100-pmic-glink
            - const: qcom,sm8550-pmic-glink
            - const: qcom,pmic-glink
+      - items:
+          - enum:
+              - qcom,glymur-pmic-glink
+          - const: qcom,x1e80100-pmic-glink
+          - const: qcom,pmic-glink


[1] 
https://lore.kernel.org/all/20250917-qcom_battmgr_update-v5-5-270ade9ffe13@oss.qualcomm.com/
> 
> 
> Heh, and don't get me started on driver...
> 
> { .compatible = "qcom,glymur-pmic-glink", .data =
> &pmic_glink_kaanapali_data },
> { .compatible = "qcom,kaanapali-pmic-glink", .data =
> &pmic_glink_kaanapali_data },
> 
> So how is now Glymur using Kaanapali, so basically compatible with it?
> 
> Even more questions I did not consider.
> 
> 

Both Kaanapali and Glymur are running on SOCCP, so we should not define 
PDR paths. Since both platforms have will have the same pmic_glink 
services running(i.e. altmode, ucsi, and battmgr),we can reuse the 
pmic_glink_data for both. I have no problem with instead defining 
pmic_glink_kaanapali_data and pmic_glink_glymur_data separately but I 
figured upstream would not like code reuse.


> 
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

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

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

[Bjorn Andersson]

On Tue, Oct 28, 2025 at 09:36:09AM +0100, 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? >
> >>
> >> 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?
> 

There are effectively two different implementations of the pmic glink
firmware (in particular the interface); one designed for Windows
products and one designed for Android products.

Then for each implementation there's incremental additions over the
years.


By not accounting for this in the fallback compatibles, we're relying on
a growing list of "specific compatibles" in qcom_battmgr_of_variants[].

In addition to this, we have the addition of USB4/TBT support in Hamoa.

Enter Glymur and Kaanapali, the implementation has moved to SoCCP, so we
should no longer do the PDR stuff.


IMHO this binding should have fallbacks for the major "versions",
mobile, and compute. But perhaps even for compute/usb4, mobile/soccp and
compute/usb4/soccp?

Regards,
Bjorn

> 
> 
> Best regards,
> Krzysztof

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

[Kamal Wadhwa]

On Tue, Oct 28, 2025 at 09:14:10AM -0500, Bjorn Andersson wrote:
> On Tue, Oct 28, 2025 at 09:36:09AM +0100, 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? >
> > >>
> > >> 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?
> > 
> 
> There are effectively two different implementations of the pmic glink
> firmware (in particular the interface); one designed for Windows
> products and one designed for Android products.
> 
> Then for each implementation there's incremental additions over the
> years.
> 
> 
> By not accounting for this in the fallback compatibles, we're relying on
> a growing list of "specific compatibles" in qcom_battmgr_of_variants[].
> 
> In addition to this, we have the addition of USB4/TBT support in Hamoa.
> 
> Enter Glymur and Kaanapali, the implementation has moved to SoCCP, so we
> should no longer do the PDR stuff.
> 
> 
> IMHO this binding should have fallbacks for the major "versions",
> mobile, and compute. But perhaps even for compute/usb4, mobile/soccp and
> compute/usb4/soccp?

Thanks! this makes sense. Then should we do this way..
- We do not touch the existing "ADSP based mobile/compute" items
- Add 2 new items for SoCCP based targets for - MOBILE-SoCCP & COMPUTE-SoCCP
like below?

      - items:
          - enum:
              - qcom,milos-pmic-glink
              - qcom,sm8650-pmic-glink
              - qcom,sm8750-pmic-glink
              - qcom,x1e80100-pmic-glink
          - const: qcom,sm8550-pmic-glink
          - const: qcom,pmic-glink
+     - items:
+         - enum:
+             - qcom,kaanapali-pmic-glink       /* MOBILE - SoCCP for pmicglink No PDR */
+         - const: qcom,sm8550-pmic-glink       /* battmgr - mobile    */
+         - const: qcom,pmic-glink
+     - items:
+         - enum:
+            - qcom,glymur-pmic-glink          /* COMPUTE - SoCCP */
+         - const: qcom,kaanapali-pmic-glink    /* pmic-glink (SoCCP/ No PDR) */
+         - const: qcom,x1e80100-pmic-glink     /* battmgr - Compute    */
+         - const: qcom,sm8550-pmic-glink       /* ucsi */
+         - const: qcom,pmic-glink

Regards,
Kamal

[PATCH v2 2/2] soc: qcom: pmic_glink: Add charger PDR service path and service name to client data

[Anjelique Melendez]

Currently, the charger PD service path and service name are hard coded
however these paths are not guaranteed to be the same between PMICs. For
example, on Kaanapali and Glymur, Charger FW runs on SOCCP(another subsystem)
which does not have any specific charger PDs defined.

Define charger PDR service path and service name as client data so that
each PMIC generation can properly define these paths.

While at it, add the qcom,kaanapali-pmic-glink and
qcom,glymur-pmic-glink compatible strings.

Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
---
 drivers/soc/qcom/pmic_glink.c | 66 ++++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 24 deletions(-)

diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c
index c0a4be5df926..aa5ba9a0285e 100644
--- a/drivers/soc/qcom/pmic_glink.c
+++ b/drivers/soc/qcom/pmic_glink.c
@@ -23,13 +23,19 @@ enum {
 	PMIC_GLINK_CLIENT_UCSI,
 };
 
+struct pmic_glink_data {
+	unsigned long	client_mask;
+	char		*charger_pdr_service_name;
+	char		*charger_pdr_service_path;
+};
+
 struct pmic_glink {
 	struct device *dev;
 	struct pdr_handle *pdr;
 
 	struct rpmsg_endpoint *ept;
 
-	unsigned long client_mask;
+	const struct pmic_glink_data *data;
 
 	struct auxiliary_device altmode_aux;
 	struct auxiliary_device ps_aux;
@@ -285,7 +291,6 @@ static struct rpmsg_driver pmic_glink_rpmsg_driver = {
 
 static int pmic_glink_probe(struct platform_device *pdev)
 {
-	const unsigned long *match_data;
 	struct pdr_service *service;
 	struct pmic_glink *pg;
 	int ret;
@@ -302,12 +307,10 @@ static int pmic_glink_probe(struct platform_device *pdev)
 	spin_lock_init(&pg->client_lock);
 	mutex_init(&pg->state_lock);
 
-	match_data = (unsigned long *)of_device_get_match_data(&pdev->dev);
-	if (!match_data)
+	pg->data = of_device_get_match_data(&pdev->dev);
+	if (!pg->data)
 		return -EINVAL;
 
-	pg->client_mask = *match_data;
-
 	pg->pdr = pdr_handle_alloc(pmic_glink_pdr_callback, pg);
 	if (IS_ERR(pg->pdr)) {
 		ret = dev_err_probe(&pdev->dev, PTR_ERR(pg->pdr),
@@ -315,27 +318,30 @@ static int pmic_glink_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI)) {
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI)) {
 		ret = pmic_glink_add_aux_device(pg, &pg->ucsi_aux, "ucsi");
 		if (ret)
 			goto out_release_pdr_handle;
 	}
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE)) {
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE)) {
 		ret = pmic_glink_add_aux_device(pg, &pg->altmode_aux, "altmode");
 		if (ret)
 			goto out_release_ucsi_aux;
 	}
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_BATT)) {
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_BATT)) {
 		ret = pmic_glink_add_aux_device(pg, &pg->ps_aux, "power-supply");
 		if (ret)
 			goto out_release_altmode_aux;
 	}
 
-	service = pdr_add_lookup(pg->pdr, "tms/servreg", "msm/adsp/charger_pd");
-	if (IS_ERR(service)) {
-		ret = dev_err_probe(&pdev->dev, PTR_ERR(service),
-				    "failed adding pdr lookup for charger_pd\n");
-		goto out_release_aux_devices;
+	if (pg->data->charger_pdr_service_name && pg->data->charger_pdr_service_path) {
+		service = pdr_add_lookup(pg->pdr, pg->data->charger_pdr_service_name,
+					 pg->data->charger_pdr_service_path);
+		if (IS_ERR(service)) {
+			ret = dev_err_probe(&pdev->dev, PTR_ERR(service),
+					    "failed adding pdr lookup for charger_pd\n");
+			goto out_release_aux_devices;
+		}
 	}
 
 	mutex_lock(&__pmic_glink_lock);
@@ -345,13 +351,13 @@ static int pmic_glink_probe(struct platform_device *pdev)
 	return 0;
 
 out_release_aux_devices:
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_BATT))
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_BATT))
 		pmic_glink_del_aux_device(pg, &pg->ps_aux);
 out_release_altmode_aux:
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE))
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE))
 		pmic_glink_del_aux_device(pg, &pg->altmode_aux);
 out_release_ucsi_aux:
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI))
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI))
 		pmic_glink_del_aux_device(pg, &pg->ucsi_aux);
 out_release_pdr_handle:
 	pdr_handle_release(pg->pdr);
@@ -365,23 +371,35 @@ static void pmic_glink_remove(struct platform_device *pdev)
 
 	pdr_handle_release(pg->pdr);
 
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_BATT))
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_BATT))
 		pmic_glink_del_aux_device(pg, &pg->ps_aux);
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE))
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE))
 		pmic_glink_del_aux_device(pg, &pg->altmode_aux);
-	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI))
+	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI))
 		pmic_glink_del_aux_device(pg, &pg->ucsi_aux);
 
 	guard(mutex)(&__pmic_glink_lock);
 	__pmic_glink = NULL;
 }
 
-static const unsigned long pmic_glink_sm8450_client_mask = BIT(PMIC_GLINK_CLIENT_BATT) |
-							   BIT(PMIC_GLINK_CLIENT_ALTMODE) |
-							   BIT(PMIC_GLINK_CLIENT_UCSI);
+static const struct pmic_glink_data pmic_glink_sm8450_data = {
+	.client_mask = BIT(PMIC_GLINK_CLIENT_BATT) |
+		       BIT(PMIC_GLINK_CLIENT_ALTMODE) |
+		       BIT(PMIC_GLINK_CLIENT_UCSI),
+	.charger_pdr_service_name = "tms/servreg",
+	.charger_pdr_service_path = "msm/adsp/charger_pd",
+};
+
+static const struct pmic_glink_data pmic_glink_kaanapali_data = {
+	.client_mask = BIT(PMIC_GLINK_CLIENT_BATT) |
+		       BIT(PMIC_GLINK_CLIENT_ALTMODE) |
+		       BIT(PMIC_GLINK_CLIENT_UCSI),
+};
 
 static const struct of_device_id pmic_glink_of_match[] = {
-	{ .compatible = "qcom,pmic-glink", .data = &pmic_glink_sm8450_client_mask },
+	{ .compatible = "qcom,glymur-pmic-glink", .data = &pmic_glink_kaanapali_data },
+	{ .compatible = "qcom,kaanapali-pmic-glink", .data = &pmic_glink_kaanapali_data },
+	{ .compatible = "qcom,pmic-glink", .data = &pmic_glink_sm8450_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, pmic_glink_of_match);
-- 
2.34.1

Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Add charger PDR service path and service name to client data

[Konrad Dybcio]

On 10/27/25 10:22 PM, Anjelique Melendez wrote:
> Currently, the charger PD service path and service name are hard coded
> however these paths are not guaranteed to be the same between PMICs. For
> example, on Kaanapali and Glymur, Charger FW runs on SOCCP(another subsystem)
> which does not have any specific charger PDs defined.
> 
> Define charger PDR service path and service name as client data so that
> each PMIC generation can properly define these paths.
> 
> While at it, add the qcom,kaanapali-pmic-glink and
> qcom,glymur-pmic-glink compatible strings.
> 
> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
> ---

I think this change disqualifies Glymur from having a fallback to 8550,
since it couldn't have worked without ignoring the PDR

Konrad

Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Add charger PDR service path and service name to client data

[Abel Vesa]

On 25-10-27 14:22:50, Anjelique Melendez wrote:
> Currently, the charger PD service path and service name are hard coded
> however these paths are not guaranteed to be the same between PMICs. For
> example, on Kaanapali and Glymur, Charger FW runs on SOCCP(another subsystem)
> which does not have any specific charger PDs defined.
> 
> Define charger PDR service path and service name as client data so that
> each PMIC generation can properly define these paths.
> 
> While at it, add the qcom,kaanapali-pmic-glink and
> qcom,glymur-pmic-glink compatible strings.
> 
> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
> ---
>  drivers/soc/qcom/pmic_glink.c | 66 ++++++++++++++++++++++-------------
>  1 file changed, 42 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c
> index c0a4be5df926..aa5ba9a0285e 100644
> --- a/drivers/soc/qcom/pmic_glink.c
> +++ b/drivers/soc/qcom/pmic_glink.c
> @@ -23,13 +23,19 @@ enum {
>  	PMIC_GLINK_CLIENT_UCSI,
>  };
>  
> +struct pmic_glink_data {
> +	unsigned long	client_mask;
> +	char		*charger_pdr_service_name;
> +	char		*charger_pdr_service_path;
> +};
> +
>  struct pmic_glink {
>  	struct device *dev;
>  	struct pdr_handle *pdr;
>  
>  	struct rpmsg_endpoint *ept;
>  
> -	unsigned long client_mask;
> +	const struct pmic_glink_data *data;
>  
>  	struct auxiliary_device altmode_aux;
>  	struct auxiliary_device ps_aux;
> @@ -285,7 +291,6 @@ static struct rpmsg_driver pmic_glink_rpmsg_driver = {
>  
>  static int pmic_glink_probe(struct platform_device *pdev)
>  {
> -	const unsigned long *match_data;
>  	struct pdr_service *service;
>  	struct pmic_glink *pg;
>  	int ret;
> @@ -302,12 +307,10 @@ static int pmic_glink_probe(struct platform_device *pdev)
>  	spin_lock_init(&pg->client_lock);
>  	mutex_init(&pg->state_lock);
>  
> -	match_data = (unsigned long *)of_device_get_match_data(&pdev->dev);
> -	if (!match_data)
> +	pg->data = of_device_get_match_data(&pdev->dev);
> +	if (!pg->data)
>  		return -EINVAL;
>  
> -	pg->client_mask = *match_data;
> -
>  	pg->pdr = pdr_handle_alloc(pmic_glink_pdr_callback, pg);
>  	if (IS_ERR(pg->pdr)) {
>  		ret = dev_err_probe(&pdev->dev, PTR_ERR(pg->pdr),
> @@ -315,27 +318,30 @@ static int pmic_glink_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> -	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI)) {
> +	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_UCSI)) {
>  		ret = pmic_glink_add_aux_device(pg, &pg->ucsi_aux, "ucsi");
>  		if (ret)
>  			goto out_release_pdr_handle;
>  	}
> -	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE)) {
> +	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_ALTMODE)) {
>  		ret = pmic_glink_add_aux_device(pg, &pg->altmode_aux, "altmode");
>  		if (ret)
>  			goto out_release_ucsi_aux;
>  	}
> -	if (pg->client_mask & BIT(PMIC_GLINK_CLIENT_BATT)) {
> +	if (pg->data->client_mask & BIT(PMIC_GLINK_CLIENT_BATT)) {
>  		ret = pmic_glink_add_aux_device(pg, &pg->ps_aux, "power-supply");
>  		if (ret)
>  			goto out_release_altmode_aux;
>  	}
>  
> -	service = pdr_add_lookup(pg->pdr, "tms/servreg", "msm/adsp/charger_pd");
> -	if (IS_ERR(service)) {
> -		ret = dev_err_probe(&pdev->dev, PTR_ERR(service),
> -				    "failed adding pdr lookup for charger_pd\n");
> -		goto out_release_aux_devices;
> +	if (pg->data->charger_pdr_service_name && pg->data->charger_pdr_service_path) {
> +		service = pdr_add_lookup(pg->pdr, pg->data->charger_pdr_service_name,
> +					 pg->data->charger_pdr_service_path);
> +		if (IS_ERR(service)) {
> +			ret = dev_err_probe(&pdev->dev, PTR_ERR(service),
> +					    "failed adding pdr lookup for charger_pd\n");
> +			goto out_release_aux_devices;
> +		}
>  	}

But this does nothing on Kaanapali and Glymur. Am I wrong?

Yes, you do not have a charger PD on Glymur, but you do have an ssr,
for which you do need to register a notifier instead.

You need to be doing something like this:
https://gitlab.com/Linaro/arm64-laptops/linux/-/commit/2cd84e303d263d8fd5de3730714a16c29cc6788b

Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Add charger PDR service path and service name to client data

[Anjelique Melendez]

On 10/28/2025 10:20 AM, Abel Vesa wrote:
> On 25-10-27 14:22:50, Anjelique Melendez wrote:

>> -		goto out_release_aux_devices;
>> +	if (pg->data->charger_pdr_service_name && pg->data->charger_pdr_service_path) {
>> +		service = pdr_add_lookup(pg->pdr, pg->data->charger_pdr_service_name,
>> +					 pg->data->charger_pdr_service_path);
>> +		if (IS_ERR(service)) {
>> +			ret = dev_err_probe(&pdev->dev, PTR_ERR(service),
>> +					    "failed adding pdr lookup for charger_pd\n");
>> +			goto out_release_aux_devices;
>> +		}
>>   	}
> 
> But this does nothing on Kaanapali and Glymur. Am I wrong?
> 
> Yes, you do not have a charger PD on Glymur, but you do have an ssr,
> for which you do need to register a notifier instead.
> 
> You need to be doing something like this:
> https://gitlab.com/Linaro/arm64-laptops/linux/-/commit/2cd84e303d263d8fd5de3730714a16c29cc6788b

Please take a look at this change, just applied: 
https://lore.kernel.org/all/20250919175025.2988948-1-anjelique.melendez@oss.qualcomm.com/.

Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Add charger PDR service path and service name to client data

[Abel Vesa]

On 25-10-28 16:30:28, Anjelique Melendez wrote:
> 
> 
> On 10/28/2025 10:20 AM, Abel Vesa wrote:
> > On 25-10-27 14:22:50, Anjelique Melendez wrote:
> 
> > > -		goto out_release_aux_devices;
> > > +	if (pg->data->charger_pdr_service_name && pg->data->charger_pdr_service_path) {
> > > +		service = pdr_add_lookup(pg->pdr, pg->data->charger_pdr_service_name,
> > > +					 pg->data->charger_pdr_service_path);
> > > +		if (IS_ERR(service)) {
> > > +			ret = dev_err_probe(&pdev->dev, PTR_ERR(service),
> > > +					    "failed adding pdr lookup for charger_pd\n");
> > > +			goto out_release_aux_devices;
> > > +		}
> > >   	}
> > 
> > But this does nothing on Kaanapali and Glymur. Am I wrong?
> > 
> > Yes, you do not have a charger PD on Glymur, but you do have an ssr,
> > for which you do need to register a notifier instead.
> > 
> > You need to be doing something like this:
> > https://gitlab.com/Linaro/arm64-laptops/linux/-/commit/2cd84e303d263d8fd5de3730714a16c29cc6788b
> 
> Please take a look at this change, just applied: https://lore.kernel.org/all/20250919175025.2988948-1-anjelique.melendez@oss.qualcomm.com/.

Fair enough. I think your approach is even cleaner.

Thanks.