Re: [PATCH 1/7] dt-bindings: interrupt-controller: mpm: Document power-domains property

On Mon, Aug 03, 2026 at 03:58:44PM +0530, Sneh Mankad wrote:
> 
> 
> On 15-Jul-26 2:24 PM, Marc Zyngier wrote:
> > On Wed, 15 Jul 2026 07:38:59 +0100,
> > Marek Szyprowski <[email protected]> wrote:
> >>
> >> On 13.07.2026 17:11, Marc Zyngier wrote:
> >>> On Mon, 13 Jul 2026 11:25:41 +0100,
> >>> Sneh Mankad <[email protected]> wrote:
> >>>> Remove #power-domain-cells property and add power-domains property for
> >>>> MPM device.
> >>>>
> >>>> Signed-off-by: Sneh Mankad <[email protected]>
> >>>> ---
> >>>>  .../devicetree/bindings/interrupt-controller/qcom,mpm.yaml          | 6 +++---
> >>>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
> >>>> index ebb40c48950ab3a8fc86f5708acfc33c33d68993..3f9645fbc3c20633077aaa589e5d5a43928dab51 100644
> >>>> --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
> >>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
> >>>> @@ -68,8 +68,8 @@ properties:
> >>>>          - description: MPM pin number
> >>>>          - description: GIC SPI number for the MPM pin
> >>>>  
> >>>> -  '#power-domain-cells':
> >>>> -    const: 0
> >>>> +  power-domains:
> >>>> +    maxItems: 1
> >>> What makes you think it is OK to change an existing binding in an
> >>> incompatible way?
> >>
> >>
> >> Ulf suggests that this has been modeled upside down in the initial
> >> submission:
> >>
> >> https://lore.kernel.org/all/CAPx+jO9d1qH12mxg-n1rkbp6Xd__sdrSMeoc7CPELE+jgxRYHA@mail.gmail.com/
> > 
> > Sure. We have collectively fucked up a lot of bindings over the years,
> > mostly because of the lack of accurate documentation and people not
> > giving a damn about the correctness of these descriptions. I'm glad
> > that Ulf is now able to make it right.
> > 
> > But that is not a license to invalidate DTs retrospectively. We don't
> > update DTs in lockstep with the kernel (I *never* do), and something
> > that existed must be supported in the long run.
> > 
> > Properties can be deprecated, but:
> > 
> > - they must be kept in the binding
> > 
> > - drivers must still honor them if they are present in the DT
> 
> Currently only two chipsets have #power-domain-cells property mentioned in MPM DT node,
> agatti and sm6375.
> 
> Agatti - does not execute CPU cluster LPMs as of now, so not handling the #power-domain-cells in
> driver will have no effect in functionality.

This is not true, they were disabled only for RB1 board.

> 
> sm6375 - Being an old chipset I am not aware of its status. 

Please become aware, in the end it's Qualcomm chipset. And it was
contributed several years ago by... Konrad.

> 
> If the driver honors the #power-domain-cells property, even the CPU level idle states will fail to
> probe on these devices, due to the reasoning provided in cover letter.
> 
> With these patches, the CPU level idle states will function properly, so will cluster level
> idle states if enabled.
> In addition to that, the fallback mechanism of registering for CPU PM notification when power-domains
> property is not mentioned in DT node will take care of the RPM notification when cluster idle state
> is entered.
> 
> As suggested by Konrad, I will add a brief explanation on the need for this bindings change in this patch.
> 
> Thanks,
> Sneh
> 

-- 
With best wishes
Dmitry