[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230314081735.GE143566@dragon>
Date: Tue, 14 Mar 2023 16:17:35 +0800
From: Shawn Guo <shawnguo@...nel.org>
To: Francesco Dolcini <francesco@...cini.it>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Philippe Schenker <dev@...henker.ch>,
devicetree@...r.kernel.org, Sascha Hauer <s.hauer@...gutronix.de>,
NXP Linux Team <linux-imx@....com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Frank Rowand <frowand.list@...il.com>,
linux-arm-kernel@...ts.infradead.org,
Fabio Estevam <festevam@...il.com>,
Philippe Schenker <philippe.schenker@...adex.com>,
linux-kernel@...r.kernel.org,
Marcel Ziswiler <marcel.ziswiler@...adex.com>
Subject: Re: [PATCH v1 03/25] arm64: dts: colibri-imx8x: Sort properties
On Thu, Mar 09, 2023 at 01:19:13PM +0100, Francesco Dolcini wrote:
> Hello Krzysztof, first thanks for your review.
>
> Let's try to get some clarity on this with the help of Shawn.
>
> On Wed, Mar 08, 2023 at 01:57:38PM +0100, Krzysztof Kozlowski wrote:
> > On 08/03/2023 13:52, Philippe Schenker wrote:
> > > From: Philippe Schenker <philippe.schenker@...adex.com>
> > >
> > > Sort properties according to the following order and inside these
> > > alphabetically.
> > >
> > > 1. compatible
> > > 2. reg
> > > 3. standard properties
> > > 4. specific properties
> > > 5. status
> >
> > Is this approved coding style for IMX DTS?
>
> I 100% understand your concerns here.
>
> With that said let me try to briefly explain the reasoning here, in
> various threads we were asked in the past to move node around based on
> some not 100% defined rules [0][1].
>
> On Sun, 2023-01-29 at 11:19 +0800, Shawn Guo wrote:
> >> +&usbotg1 {
> >> + adp-disable;
> >> + ci-disable-lpm;
> >> + hnp-disable;
> >> + over-current-active-low;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&pinctrl_usbotg1>;
> >
> >We generally want to put such generic properties before device specific
> >ones.
>
> In addition to that we find convenient to have properties sorted
> alphabetically when no other rule is available, it just prevents any
> kind of discussion, minimize merge conflicts and make comparing files
> easier.
>
> I also agree that the difference between "generic"/"specific" is fuzzy
> at best.
>
> With all that said ...
>
> Shawn: What should we do? We can of course avoid any kind of re-ordering
> from now on.
We are practically asking for 1, 2 and 5 for i.MX DTS files, but pretty
flexible for the rest.
> I am fine to be very pragmatic here, no-reordering on existing DTS
> files, newly added DTS files we discuss whatever is the reasoning of the
> reviewer/maintainer on a case-by-case basis.
Sounds good to me! While I personally like your ordering, I do not want
it to churn the existing DTS files.
I'm happy to take this patch as a special case though :)
Shawn
Powered by blists - more mailing lists