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) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
