Re: [PATCH v2 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add Kaanapali and Glymur compatibles
From: Anjelique Melendez
Date: Tue Oct 28 2025 - 18:55:16 EST
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:
I don't know exactly this IP block/component, but in general these SoCs
Signed-off-by: Anjelique Melendez <anjelique.melendez@xxxxxxxxxxxxxxxx>
---
.../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'
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@xxxxxxxxxxxxxxxx/
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