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

From: Anjelique Melendez
Date: Wed Jan 07 2026 - 17:37:21 EST



On 12/22/2025 11:42 AM, Bjorn Andersson wrote:
On Tue, Dec 16, 2025 at 09:56:54PM -0800, Anjelique Melendez wrote:
Kaanapali PMIC glink platforms support features exposed by the
SM8550 PMIC glink interface. Document the Kaanpali compatible
string to have fallback on SM8550.

Glymur PMIC glink platforms support features exposed by SM8550, X1E80100 and Kaanapali PMIC glink interfaces. Document the Glymur compatible string to have fallbacks on SM8550, X1E80100 and
Kaanapali.

But while the Glymur PMIC GLINK interface does present (almost) the
same features as SM8550 and/or Kaanapali, I don't see them as
compatible. The protocol is different and if nothing else, as shown
by patch 2, the life cycle is different.


Signed-off-by: Anjelique Melendez
<anjelique.melendez@xxxxxxxxxxxxxxxx> --- .../devicetree/bindings/
soc/qcom/qcom,pmic-glink.yaml | 8 ++++++++ 1 file changed, 8
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..302b338e7012 100644 --- a/
Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml ++
+ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-
glink.yaml @@ -37,12 +37,20 @@ 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,kaanapali-pmic-glink + - const: qcom,x1e80100-pmic-
glink + - const: qcom,sm8550-pmic-glink + -
const: qcom,pmic-glink

So this would then result in:

compatible = "qcom,glymur-pmic-glink", "qcom,kaanapali-pmic-glink",
"qcom,x1e80100-pmic-glink", "qcom,sm8550-pmic-glink", "qcom,pmic-
glink";

Which tells the operating system that it should use the
implementation for the Glymur interface, and if that isn't known the
implementation for the Kaanapali interface, and if that isn't known
the implementation for the Hamoa interface, and if that isn't known
the implementation for the SM8550 interface, and if that isn't known
the generic "pmic glink" interface.

So, in an operating system that doesn't know how to interact with Glymur, you have stated that Kaanapali is a good second choice. This does accurately capture the soccp behavior, but looking at the individual functions we're not compatible with Kaanapali.

If we're in an operating system that doesn't know about Glymur or Kaanapali, you're stating that the Hamoa implementation is good. I
think this is accurate for several of the features, but the OS will
forever wait for the services to show up.

Etc...

As such, I think the appropriate way to express this is to add two
new "top-level" options:

- items: - const: qcom,kaanapali-pmic-glink - const: qcom,pmic-glink - items: - const: qcom,glymur-pmic-glink - const: qcom,pmic-glink

This establishes them as new "base compatibles", which can be used
for derived platforms, by just adding the relevant enums. The
alternative is to add them to the first item (enum + qcom,pmic-
glink) and then as soon as we have derivatives we split it out in
enum + kaanapali + qcom,pmic-glink or enum + glymur + qcom,pmic-
glink. But I think this would be cleaner.

Regards, Bjorn


I agree that it would make more sense to decouple Kaanapali and Glymur however I do have a few follow up questions on how that should look in the pmic-glink and glink aux drivers.

1. In v2 we had tried to define Kaanapali and Glymur separately but in the pmic-glink driver they were sharing the same data since they both have charger FW running on SOCCP instead of ADSP. Krzysztof had expressed here, https://lore.kernel.org/all/01f419cc-3236-48b9-bd51-e7db07d1e6fe@xxxxxxxxxx/, that having separate Glymur and Kaanapali compatible strings but then having them both point to the pmic_glink_kaanapali_data basically infers that Kaanapali and Glymur were compatible. There were other issues with that binding so I'm not sure if that comment would still stand in this case if we create new Glymur and Kaanapali base compatibles. If it does would it make more sense if the pmic_glink_data was instead named so that it relates to the system that the chg fw is running on?
i.e
{ .compatible="qcom,glymur-pmic-glink",.data=&pmic_glink_soccp_data},
{ .compatible="qcom,kaanapali-pmic-glink",.data=&pmic_glink_soccp_data},
{ .compatible = "qcom,pmic-glink", .data = &pmic_glink_adsp_data },


2. With Glymur and Kaanapali separated we would also need to update the UCSI and Battmngr drivers compatible string lists.

In USCI driver we would need to do:

+ { .compatible ="qcom,glymur-pmic-glink", .data = &quirk_sm8450, },
+ { .compatible = "qcom,kaanapali-pmic-glink",.data = &quirk_sm8450, },
{ .compatible = "qcom,qcm6490-pmic-glink", .data = &quirk_sc8280xp, },
{ .compatible = "qcom,sc8180x-pmic-glink", .data = &quirk_sc8180x, },
{ .compatible = "qcom,sc8280xp-pmic-glink", .data= &quirk_sc8280xp, },
{ .compatible = "qcom,sm8350-pmic-glink", .data = &quirk_sc8180x, },
{ .compatible = "qcom,sm8450-pmic-glink", .data = &quirk_sm8450, },
{ .compatible = "qcom,sm8550-pmic-glink", .data = &quirk_sm8450, },


and in battmgr driver we would need to do:

+ { .compatible = "qcom,glymur-pmic-glink", .data = (void *) X1E80100 },
+ { .compatible = "qcom,kaanapali-pmic-glink", .data = (void *)SM8550 },
{ .compatible = "qcom,sc8180x-pmic-glink", .data = (void *)SC8280XP },
{ .compatible = "qcom,sc8280xp-pmic-glink", .data = (void *)SC8280XP},
{ .compatible = "qcom,sm8550-pmic-glink", .data = (void *)SM8550 },
{ .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)X1E80100},


I'm wondering if instead of making changes to both the UCSI and battmngr drivers, does it make sense to just add a compatible for X1E to UCSI? I briefly discussed this approach in this response: https://lore.kernel.org/all/481ec137-87cf-4448-99e9-4a1477f4854d@xxxxxxxxxxxxxxxx/.
With this we could instead define Kaanapali as a fallback to sm8550 and Glymur as a fallback to the x1e

Binding would instead look something like this

--- 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:
@@ -38,12 +38,18 @@ 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

with the UCSI driver change just being:
{ .compatible = "qcom,qcm6490-pmic-glink", .data = &quirk_sc8280xp, },
{ .compatible = "qcom,sc8180x-pmic-glink", .data = &quirk_sc8180x, },
{ .compatible = "qcom,sc8280xp-pmic-glink", .data= &quirk_sc8280xp, },
{ .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, },


Thanks,
Anjelique