Message-ID: <5fb0130c-473e-dc15-b60c-e5b6144031ad@suse.de>
Date:   Mon, 15 May 2017 21:10:58 +0200
From:   Andreas Färber <afaerber@...e.de>
To:     Neil Armstrong <narmstrong@...libre.com>,
        linux-amlogic@...ts.infradead.org
Cc:     Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Kevin Hilman <khilman@...libre.com>,
        linux-kernel@...r.kernel.org, Carlo Caione <carlo@...one.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 00/18] ARM64: meson: DT cleanups

Hi Neil,

Am 15.05.2017 um 10:16 schrieb Neil Armstrong:
> Hi Andreas,
> 
> On 05/13/2017 04:33 PM, Andreas Färber wrote:
>> Hello Kevin,
>>
>> This series fixes several cosmetic issues, on top of your for-next branch.
>>
>> Patches 3-6 rename a node, the rest should all be non-functional changes.
> 
> These are OK.
> 
>> PLEASE STOP merging random new nodes at the bottom of DT files!
>> Just like it's a convention to sort new nodes by unit address, it has been
>> a convention to sort by-label nodes by their label. As discussed here and
>> elsewhere, this helps avoid merge conflicts and makes nodes easy to find.
>> I don't care whether we order A0 before A or after, but adding new HDMI
>> or CVBS nodes at the very bottom is totally out of alphabetical order.
>> Since my v1 you really should've known that...
> 
> It's not perfect, but now it's done, live with it, this has already been discussed.

No.

Copy&pasting your comment N times does not make it any more valid. My
files, my rules - I insist on vega-s95, gxbb and gx, which you guys
refactored out from my gxbb, to be tidy.

> Please try to refactor boards DTS with their parent reference design instead
> like it was done with the P212 and what I did with the Wetek Hub and Play2.

Negative, that means any additions and changes for the reference boards
will slip through into boards that you do not test.

We've already seen how "well" that works with R-Box Pro having inherited
a broken U-Boot network configuration due to internal vs. external PHY.

>> Similarly, Khadas Vim shouldn't have been merged with the "bcrmf" typo.
> 
> Well, this is why we have 7 rc releases after the merge window...

If Kevin is the maintainer, then he needs to carefully review patches.
It is not my job to review all patches when BayLibre gets paid for it!

>> Which proves my point that we need to fix these issues now so that they
>> don't keep spreading (Broken Window Theory). New boards have not been
>> checked for sort order, only boards already touched in v1.
>>
>> Board and Makefile order affect my pending R-Box Pro patches.
>> Node order affects Martin's pending Bluetooth patches among others.
> 
> Please order S905x after S905d, and we'll be OK.

Isn't the historical SoC order S905X before S905D?

Otherwise your strict interpretation leads to meson-gxbb before meson8,
which seems unlogical to me.

>> Patches 7-9 (had and) have no dependency, please start applying.
> 
> I'll wait for Kevin's advice, but I'm against these since they are
> only purely cosmetic and will break bisect and add unnecessary complexity
> to handle further patches on these board.

See the gxbb patch for why that statement is wrong.

Also note that not cleaning up an existing mess and making it worse are
two things.

I will also remind that I was forced to clean up the node order in ALL
exynos5250 .dts files before I could get my new exynos5250-spring.dts
merged, so I have zero understanding about these "churn" and "live with
it" comments here. The same rules need to apply to all (that's égalité
for you!), BayLibre is not above everyone else.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Powered by blists - more mailing lists