Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221219191038.1973807-1-robh@kernel.org> <87edsua5q4.fsf@balbi.sh>
 <CAL_JsqKgGWN93QJ=V34=X3hC2bgdcd3vwO0Mne-8z8HOfVDz-g@mail.gmail.com>
 <878riy9ztm.fsf@balbi.sh> <20221223235712.h54lggnjjuu3weol@synopsys.com>
 <CAL_Jsq+gCi8g0jY2ic1tJebc_JijMU-GntWQg09q+X41O3=1RA@mail.gmail.com> <87o7rlffi7.fsf@balbi.sh>
In-Reply-To: <87o7rlffi7.fsf@balbi.sh>
From:   Rob Herring <robh@kernel.org>
Date:   Fri, 30 Dec 2022 10:54:40 -0600
Message-ID: <CAL_Jsq+viP_aY3n378WC7WpxZFnsTc-vKjW9Ojvcy0Ef-z09Ng@mail.gmail.com>
Subject: Re: [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property
To:     Felipe Balbi <balbi@kernel.org>
Cc:     Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
        Heiko Stuebner <heiko@sntech.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        "linux-rockchip@lists.infradead.org" 
        <linux-rockchip@lists.infradead.org>,
        Johan Jonker <jbx6244@gmail.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Dec 30, 2022 at 2:43 AM Felipe Balbi <balbi@kernel.org> wrote:
>
>
> Hi,
>
> Rob Herring <robh@kernel.org> writes:
> > On Fri, Dec 23, 2022 at 5:57 PM Thinh Nguyen <Thinh.Nguyen@synopsys.com> wrote:
> >> > Rob Herring <robh@kernel.org> writes:
> >> > >> > The Rockchip RK3399 DWC3 node has 'power-domain' property which isn't
> >> > >> > allowed by the schema:
> >> > >> >
> >> > >> > usb@fe900000: Unevaluated properties are not allowed ('power-domains' was unexpected)
> >> > >> >
> >> > >> > Allow DWC3 nodes to have a single power-domains entry. We could instead
> >> > >> > move the power-domains property to the parent wrapper node, but the
> >> > >> > could be an ABI break (Linux shouldn't care). Also, we don't want to
> >> > >> > encourage the pattern of wrapper nodes just to define resources such as
> >> > >> > clocks, resets, power-domains, etc. when not necessary.
> >> > >> >
> >> > >> > Signed-off-by: Rob Herring <robh@kernel.org>
> >> > >> > ---
> >> > >> >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 3 +++
> >> > >> >  1 file changed, 3 insertions(+)
> >> > >> >
> >> > >> > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >> > >> > index 6d78048c4613..bcefd1c2410a 100644
> >> > >> > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >> > >> > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >> > >> > @@ -91,6 +91,9 @@ properties:
> >> > >> >          - usb2-phy
> >> > >> >          - usb3-phy
> >> > >> >
> >> > >> > +  power-domains:
> >> > >> > +    maxItems: 1
> >> > >>
> >> > >> AFAICT this can be incorrect. Also, you could have Cc the dwc3
> >> > >> maintainer to get comments.
> >>
> >> Felipe is correct. We have 2 power-domains: Core domain and PMU.
> >
> > Power management unit? Performance management unit?
> >
> > That doesn't change that the rk3399 is 1 and we're stuck with it. So I
> > can say 1 or 2 domains, or we add the 2nd domain when someone needs
> > it.
>
> Isn't the snps,dwc3.yaml document supposed to document dwc3's view of
> the world? In that case, dwc3 expects 2 power domains. It just so
> happens that in rk3399 they are fed from the same power supply, but
> dwc3' still thinks there are two of them. No?

Yes. That is how bindings *should* be. However, RK3399 defined one PD
long ago and it's an ABI. So we are stuck with it. Everyone else put
power-domains in the parent because obviously the DWC3 has 0
power-domains.

> It's a similar situation when you have multiple clock domains with the
> same parent clock.

Yes, that's a common problem in clock bindings too. Not really
anything we can do about that other than require a detailed reference
manual with every binding and someone (me) reviewing the manual
against the binding. Neither of those are going to happen. Even on Arm
Primecell blocks which clearly (and publicly) document the clocks,
we've gotten these wrong (or .dts authors just didn't follow the
binding).

Rob