linux-kernel - Re: [PATCH v2 00/18] ARM64: meson: DT cleanups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2mvab88dh.fsf@baylibre.com>
Date:   Wed, 17 May 2017 14:46:02 -0700
From:   Kevin Hilman <khilman@...libre.com>
To:     Andreas Färber <afaerber@...e.de>
Cc:     linux-amlogic@...ts.infradead.org, Carlo Caione <carlo@...one.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Rob Herring <robh@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: Re: [PATCH v2 00/18] ARM64: meson: DT cleanups

Hi Andreas,

Andreas Färber <afaerber@...e.de> writes:

> 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.
>
> 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...

Your tone is a bit tiresome and frankly makes me hesitate before
reviewing the patches.  If you expect cordial dialogue and producitve
collaboration, please dial the accusations back a notch.

[ ... deep breath ... ]

Yes, your point was clear in v1, but that doesn't mean I agreed with it,
or that I particularily pay attention to that in my reviews because
honestly, alphabetical sorting is not very high on the list of things I
care about.  Over many years of being a kernel maintainer, I've had to
deal with my share of headaches, but conflicts caused by poorly sorted
DT files hs never been on my list of pain points.

That being said, I understand your concerns and similar ones raised
maintainers on other platforms.  I'm not a big fan of the churn caused
by this kind of rework, *but* I'm also not opposed to keeping things
better organized.  So, since there is an active contributor (and
reviewer) that is willing to put in the time and effort to clean things
up, I don't see a good (enough) reason to say no.

So, I will apply the series as is to my v4.13/dt64 branch

Going forward, I will try to keep an eye on the organization of DTS
files, but honestly, it's low priority for me, so if this is something
you care about, I trust that you will continue to help review DTS files.

I know you're already doing many reviews along with your contributions,
so thanks for that, and please keep it up. :)

> Similarly, Khadas Vim shouldn't have been merged with the "bcrmf" typo.
>
> 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.

Yes, this series will affect a few other series that are in flight, and
I apologize to those developers for the needed rebase, but I'd rather
apply a series like this that affects so many DT files early in the
cycle.

Thanks again for the fixes and cleanups,

Kevin