linux-kernel - Re: [PATCH v3 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] [day] [month] [year] [list]

Message-ID: <fcb65bmrocuyapp2hocfzxuufa2ttgv7sf4ip72yybbefm65zb@ojka5lpo7iuh>
Date: Mon, 22 Dec 2025 13:42:10 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Anjelique Melendez <anjelique.melendez@....qualcomm.com>
Cc: 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 v3 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Add
 Kaanapali and Glymur compatibles

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@....qualcomm.com>
> ---
>  .../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

>  
>    '#address-cells':
>      const: 1
> -- 
> 2.34.1
>