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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <918fc9d3-2cd5-4442-8bc6-b930596d95c1@oss.qualcomm.com>
Date: Tue, 28 Oct 2025 10:04:44 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        Anjelique Melendez <anjelique.melendez@....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/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@....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