
On Mon, Oct 19, 2015 at 02:57:22PM +0200, Linus Walleij wrote:
Jon & Grant especially:
On Mon, Oct 19, 2015 at 2:44 PM, Simon Glass sjg@chromium.org wrote:
Me
I will go in and answer the comment on the DT mailing list so there is some push atleast.
Perhaps if we could see some movement then it would provide encouragement to continue. So far I cannot recall seeing a single U-Boot device tree change accepted in the 4 years I've been involved. That's not to say it hasn't happened, and I hope it is just a reflection on my memory rather than the difficulty level.
OK this isn't working.
I think the problem is that DT bindings have traditionally been merged to the kernel by different subsystem maintainers. That means mailing them and their mailing lists and this is IMO too complex for U-Boot people (or other external people) to have to deal with. As subsystem maintainer I'm not very happy about being the one responsible either.
The MAINTAINERS entry for device tree bindings does not state a git tree and I've never seen any of the maintainers send a pull request for DT binding files. (Beat me up properly if you have, guys.) I've seen Grant send some at times.
From Rob Herring Date Tue, 1 Sep 2015 16:20:13 -0500 Subject [GIT PULL] DeviceTree for 4.3
https://lkml.org/lkml/2015/9/1/526
I suggest sending U-Boot DT bindings to not only devicetree@vger.kernel.org but also, as indicated, to Jon Corbet and linux-doc.
I have no problem with patches going to an extended set of lists.
If noone cares to comment in two weeks, Jon can merge them, breaking the status quo on external DT bindings.
The DT bindings maintainance has sadly been a very sad story and if the Linux kernel should be the canon repository for them, we need to find a simple way for external projects to contribute. Just mailing them to devicetree@vger obviously stands the risk of just ending up in the memory hole.
Rob, we should organise rotating the reponsibility of picking things up.
I'd been meaning to organise something official previously, and this is a good kick to do so.
Thanks, Mark.