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: <xg6x7vulzjtiqnzu2g3k4phhi3og537cwu2quwqgdlpcxoggwt@pqmfsvsumt2g>
Date: Tue, 28 Oct 2025 09:14:10 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Anjelique Melendez <anjelique.melendez@....qualcomm.com>, 
	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 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@....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