[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YWPQwVd9+qvmoD6O@atomide.com>
Date: Mon, 11 Oct 2021 08:50:57 +0300
From: Tony Lindgren <tony@...mide.com>
To: Rob Herring <robh@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, linux-omap@...r.kernel.org,
Suman Anna <s-anna@...com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Simon Horman <horms+renesas@...ge.net.au>
Subject: Re: [PATCH 3/3] dt-bindings: bus: ti-sysc: Update to use yaml binding
Hi,
* Rob Herring <robh@...nel.org> [211008 20:39]:
> On Thu, Oct 07, 2021 at 03:48:58PM +0300, Tony Lindgren wrote:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - ti,sysc-omap2
> > + - ti,sysc-omap2
> > + - ti,sysc-omap4
> > + - ti,sysc-omap4-simple
> > + - ti,sysc-omap2-timer
> > + - ti,sysc-omap4-timer
> > + - ti,sysc-omap3430-sr
> > + - ti,sysc-omap3630-sr
> > + - ti,sysc-omap4-sr
> > + - ti,sysc-omap3-sham
> > + - ti,sysc-omap-aes
> > + - ti,sysc-mcasp
> > + - ti,sysc-dra7-mcasp
> > + - ti,sysc-usb-host-fs
> > + - ti,sysc-dra7-mcan
> > + - ti,sysc-pruss
> > + - const: ti,sysc
> > + - items:
> > + - const: ti,sysc
>
> This doesn't really match what the old doc said nor the old example.
> Fine to fix in the conversion if wrong, but just highlight that in the
> commit msg.
OK yes we currently always need "ti,sysc" as the clockdomain autoidle
handling still relies on auxdata.
> > +
> > + reg: true
>
> Any number of register areas is valid?
Yes the number of registers is known, I'll update to use max three reg.
> > +
> > + reg-names: true
>
> You've thrown out the names defined before.
Yup these are known too.
> > +
> > + clocks: true
>
> Any number of clocks is valid?
I think 8 clocks is the highest seen :)
> > + clock-names: true
>
> You've thrown out the names defined before.
Hmm fck and ick can be named, the rest are device specific though.
> > +
> > + power-domains: true
>
> How many?
Just one should be enough here.
> > +additionalProperties: true
>
> This can be restricted to child nodes only? If so:
>
> additionalProperties:
> type: object
OK great, this can be limited to child nodes only.
Regards,
Tony
Powered by blists - more mailing lists