| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <481ec137-87cf-4448-99e9-4a1477f4854d@oss.qualcomm.com>
Date: Tue, 28 Oct 2025 15:55:11 -0700
From: Anjelique Melendez <anjelique.melendez@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: andersson@...nel.org, konradybcio@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add
Kaanapali and Glymur compatibles
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@....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
Powered by blists - more mailing lists