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.
Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.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
- 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,sm8550-pmic-glink
+ - const: qcom,pmic-glink
'#address-cells':
const: 1
--
2.34.1On 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... > > Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.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. > - 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,sm8550-pmic-glink > + - const: qcom,pmic-glink > > '#address-cells': > const: 1 > -- > 2.34.1 >
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@oss.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? Best regards, Krzysztof
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@oss.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
On Tue, Oct 28, 2025 at 09:14:10AM -0500, Bjorn Andersson wrote:
> 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@oss.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?
Thanks! this makes sense. Then should we do this way..
- We do not touch the existing "ADSP based mobile/compute" items
- Add 2 new items for SoCCP based targets for - MOBILE-SoCCP & COMPUTE-SoCCP
like below?
- items:
- enum:
- 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,kaanapali-pmic-glink /* MOBILE - SoCCP for pmicglink No PDR */
+ - const: qcom,sm8550-pmic-glink /* battmgr - mobile */
+ - const: qcom,pmic-glink
+ - items:
+ - enum:
+ - qcom,glymur-pmic-glink /* COMPUTE - SoCCP */
+ - const: qcom,kaanapali-pmic-glink /* pmic-glink (SoCCP/ No PDR) */
+ - const: qcom,x1e80100-pmic-glink /* battmgr - Compute */
+ - const: qcom,sm8550-pmic-glink /* ucsi */
+ - const: qcom,pmic-glink
Regards,
Kamal
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@oss.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
On 28/10/2025 10:04, Konrad Dybcio wrote: > 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 Then say that. Otherwise it feels like describing current Linux implementation and that would be obvious no-go. Why? Because then argument is: change Linux driver implementation. > >>>> >>>> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.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)? Easier for you? Why nitpicking on wording "generation" instead of explaining the problems or issues with bindings... Best regards, Krzysztof
On 10/28/25 10:16 AM, Krzysztof Kozlowski wrote: > On 28/10/2025 10:04, Konrad Dybcio wrote: >> 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 > > Then say that. Otherwise it feels like describing current Linux > implementation and that would be obvious no-go. Why? Because then > argument is: change Linux driver implementation. > >> >>>>> >>>>> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.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)? > > Easier for you? > > Why nitpicking on wording "generation" instead of explaining the > problems or issues with bindings... What I'm saying is that Kaanapali and Glymur are disjoint projects that shouldn't be thought of as having a common base Konrad
On 28/10/2025 10:19, Konrad Dybcio wrote: >>> >>>>>> >>>>>> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.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)? >> >> Easier for you? >> >> Why nitpicking on wording "generation" instead of explaining the >> problems or issues with bindings... > > What I'm saying is that Kaanapali and Glymur are disjoint projects > that shouldn't be thought of as having a common base No, please go through my A B C D E list to understand the problem. I did not suggest what you reply here. Best regards, Krzysztof
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@oss.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)?
>>>
>>> Easier for you?
>>>
>>> Why nitpicking on wording "generation" instead of explaining the
>>> problems or issues with bindings...
>>
>> What I'm saying is that Kaanapali and Glymur are disjoint projects
>> that shouldn't be thought of as having a common base
>
>
> No, please go through my A B C D E list to understand the problem. I did
> not suggest what you reply here.
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.
Best regards,
Krzysztof
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@oss.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
On 28/10/2025 23:55, Anjelique Melendez wrote: > > > 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@oss.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 That's not what I said there. We don't speak here about these. We speak ONLY about this compatible. How you map your compatible to UCSI, BATTMGR, FOO and BAR does not matter, although I asked about re-using of Kaanapali drvdata in one of my last replies. > > or > A is compatible with B and C > E is compatible with B and D No, that was just because Konrad got focused on word "generation". Use my earlier comment. > > > 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. I don't understand whether you are explaining your patch - why it is done like that - or agreeing that your patch is wrong. Best regards, Krzysztof
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. > > Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.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 This seems pretty reasonable, kaanapali-pmic-glink being "the same" as sm8550-pmic-glink, just moved to a different core - with the changes that implies. > - qcom,milos-pmic-glink > - qcom,sm8650-pmic-glink > - qcom,sm8750-pmic-glink > - qcom,x1e80100-pmic-glink Why did we say x1e80100-pmic-glink is "the same" as sm8550-pmic-glink? > - const: qcom,sm8550-pmic-glink > - const: qcom,pmic-glink > + - items: > + - enum: > + - qcom,glymur-pmic-glink > + - const: qcom,x1e80100-pmic-glink glymur-pmic-glink indeed has parts in common with x1e80100-pmic-glink, so I guess that makes sense. > + - const: qcom,sm8550-pmic-glink I don't think this should be here. Regards, Bjorn > + - const: qcom,pmic-glink > > '#address-cells': > const: 1 > -- > 2.34.1 >
© 2016 - 2026 Red Hat, Inc.