PMM8654AU is a different PMIC from PMM8650AU, even though both share
the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
variant.
The PMM8654AU PON block is compatible with the PMK8350 PON
implementation, but PMM8654AU also implements additional PON registers
beyond the baseline. Use the PMM8654AU naming to match the compatible
string already present in the upstream pinctrl-spmi-gpio driver, keeping
device tree and kernel driver naming consistent.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v3:
- Update the commit message.
Changes in v2:
- Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
---
.../devicetree/bindings/power/reset/qcom,pon.yaml | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..14b85b0d97da12c756cfe2ce33853501ba4ca46c 100644
--- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
+++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
@@ -17,12 +17,16 @@ description: |
properties:
compatible:
- enum:
- - qcom,pm8916-pon
- - qcom,pm8941-pon
- - qcom,pms405-pon
- - qcom,pm8998-pon
- - qcom,pmk8350-pon
+ oneOf:
+ - enum:
+ - qcom,pm8916-pon
+ - qcom,pm8941-pon
+ - qcom,pms405-pon
+ - qcom,pm8998-pon
+ - qcom,pmk8350-pon
+ - items:
+ - const: qcom,pmm8654au-pon
+ - const: qcom,pmk8350-pon
reg:
description: |
--
2.34.1On Fri, Feb 27, 2026 at 06:02:28PM +0530, Rakesh Kota wrote: > PMM8654AU is a different PMIC from PMM8650AU, even though both share > the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC > variant. > > The PMM8654AU PON block is compatible with the PMK8350 PON > implementation, but PMM8654AU also implements additional PON registers So does that mean that PMM8654AU has 2 address spaces and PMK8350 has only one? At least it looks, so I expect fixing the last if:then: - you need to drop contains from PMK8350 if clause and add new if:then: for PMM8654AU. Although the binding says "pbs" and here you say "PON". > beyond the baseline. Use the PMM8654AU naming to match the compatible > string already present in the upstream pinctrl-spmi-gpio driver, keeping > device tree and kernel driver naming consistent. And all this is partially confusing. This is reset/PON, not SPMI Pinctrl GPIO binding. Best regards, Krzysztof
On 2/28/26 11:17 AM, Krzysztof Kozlowski wrote: > On Fri, Feb 27, 2026 at 06:02:28PM +0530, Rakesh Kota wrote: >> PMM8654AU is a different PMIC from PMM8650AU, even though both share >> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC >> variant. >> >> The PMM8654AU PON block is compatible with the PMK8350 PON >> implementation, but PMM8654AU also implements additional PON registers > > So does that mean that PMM8654AU has 2 address spaces and PMK8350 has > only one? At least it looks, so I expect fixing the last if:then: - you > need to drop contains from PMK8350 if clause and add new if:then: for > PMM8654AU. The delta between them is such that within the already-described reg ranges, there is some additional bits and/or registers (can't remember but it doesn't matter for this point) This doesn't impact the described size, as all QC PMIC peripherals are by design allocated 0x100-wide windows Konrad > > Although the binding says "pbs" and here you say "PON". > > >> beyond the baseline. Use the PMM8654AU naming to match the compatible >> string already present in the upstream pinctrl-spmi-gpio driver, keeping >> device tree and kernel driver naming consistent. > > And all this is partially confusing. This is reset/PON, not SPMI Pinctrl > GPIO binding. > > Best regards, > Krzysztof > >
On 02/03/2026 11:20, Konrad Dybcio wrote: > On 2/28/26 11:17 AM, Krzysztof Kozlowski wrote: >> On Fri, Feb 27, 2026 at 06:02:28PM +0530, Rakesh Kota wrote: >>> PMM8654AU is a different PMIC from PMM8650AU, even though both share >>> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC >>> variant. >>> >>> The PMM8654AU PON block is compatible with the PMK8350 PON >>> implementation, but PMM8654AU also implements additional PON registers >> >> So does that mean that PMM8654AU has 2 address spaces and PMK8350 has >> only one? At least it looks, so I expect fixing the last if:then: - you >> need to drop contains from PMK8350 if clause and add new if:then: for >> PMM8654AU. > > The delta between them is such that within the already-described reg > ranges, there is some additional bits and/or registers (can't remember > but it doesn't matter for this point) > > This doesn't impact the described size, as all QC PMIC peripherals are > by design allocated 0x100-wide windows I still expect that fixed. Best regards, Krzysztof
On 3/2/26 11:28 AM, Krzysztof Kozlowski wrote: > On 02/03/2026 11:20, Konrad Dybcio wrote: >> On 2/28/26 11:17 AM, Krzysztof Kozlowski wrote: >>> On Fri, Feb 27, 2026 at 06:02:28PM +0530, Rakesh Kota wrote: >>>> PMM8654AU is a different PMIC from PMM8650AU, even though both share >>>> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC >>>> variant. >>>> >>>> The PMM8654AU PON block is compatible with the PMK8350 PON >>>> implementation, but PMM8654AU also implements additional PON registers >>> >>> So does that mean that PMM8654AU has 2 address spaces and PMK8350 has >>> only one? At least it looks, so I expect fixing the last if:then: - you >>> need to drop contains from PMK8350 if clause and add new if:then: for >>> PMM8654AU. >> >> The delta between them is such that within the already-described reg >> ranges, there is some additional bits and/or registers (can't remember >> but it doesn't matter for this point) >> >> This doesn't impact the described size, as all QC PMIC peripherals are >> by design allocated 0x100-wide windows > > I still expect that fixed. that = commit message? Konrad
On 04/03/2026 11:08, Konrad Dybcio wrote: > On 3/2/26 11:28 AM, Krzysztof Kozlowski wrote: >> On 02/03/2026 11:20, Konrad Dybcio wrote: >>> On 2/28/26 11:17 AM, Krzysztof Kozlowski wrote: >>>> On Fri, Feb 27, 2026 at 06:02:28PM +0530, Rakesh Kota wrote: >>>>> PMM8654AU is a different PMIC from PMM8650AU, even though both share >>>>> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC >>>>> variant. >>>>> >>>>> The PMM8654AU PON block is compatible with the PMK8350 PON >>>>> implementation, but PMM8654AU also implements additional PON registers >>>> >>>> So does that mean that PMM8654AU has 2 address spaces and PMK8350 has >>>> only one? At least it looks, so I expect fixing the last if:then: - you >>>> need to drop contains from PMK8350 if clause and add new if:then: for >>>> PMM8654AU. >>> >>> The delta between them is such that within the already-described reg >>> ranges, there is some additional bits and/or registers (can't remember >>> but it doesn't matter for this point) >>> >>> This doesn't impact the described size, as all QC PMIC peripherals are >>> by design allocated 0x100-wide windows >> >> I still expect that fixed. > > that = commit message? No, what I wrote in my first reply what has to be fixed. Best regards, Krzysztof
On Wed, Mar 04, 2026 at 11:11:38AM +0100, Krzysztof Kozlowski wrote:
> On 04/03/2026 11:08, Konrad Dybcio wrote:
> > On 3/2/26 11:28 AM, Krzysztof Kozlowski wrote:
> >> On 02/03/2026 11:20, Konrad Dybcio wrote:
> >>> On 2/28/26 11:17 AM, Krzysztof Kozlowski wrote:
> >>>> On Fri, Feb 27, 2026 at 06:02:28PM +0530, Rakesh Kota wrote:
> >>>>> PMM8654AU is a different PMIC from PMM8650AU, even though both share
> >>>>> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
> >>>>> variant.
> >>>>>
> >>>>> The PMM8654AU PON block is compatible with the PMK8350 PON
> >>>>> implementation, but PMM8654AU also implements additional PON registers
> >>>>
> >>>> So does that mean that PMM8654AU has 2 address spaces and PMK8350 has
> >>>> only one? At least it looks, so I expect fixing the last if:then: - you
> >>>> need to drop contains from PMK8350 if clause and add new if:then: for
> >>>> PMM8654AU.
> >>>
> >>> The delta between them is such that within the already-described reg
> >>> ranges, there is some additional bits and/or registers (can't remember
> >>> but it doesn't matter for this point)
> >>>
> >>> This doesn't impact the described size, as all QC PMIC peripherals are
> >>> by design allocated 0x100-wide windows
> >>
> >> I still expect that fixed.
> >
> > that = commit message?
>
> No, what I wrote in my first reply what has to be fixed.
>
Should i need to add something like below: (removing the contain for
PMK8350 and new if:then for PMM8654AU)
+ - if:
+ properties:
+ compatible:
+ const: qcom,pmk8350-pon
+ then:
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 2
+ reg-names:
+ minItems: 1
+ items:
+ - const: hlos
+ - const: pbs
+
- if:
properties:
compatible:
contains:
- const: qcom,pmk8350-pon
+ const: qcom,pmm8654au-pon
Note: PMM8654AU uses the same PON register regions as PMK8350. hlos and
pbs togater called PON module and there are no additional reg ranges/properties
needed for PMM8654AU, While PMM8654AU updates some register
definitions (offsets/bits added/removed).
Best regards
Rakesh kota
> Best regards,
> Krzysztof
© 2016 - 2026 Red Hat, Inc.