On Thu, Sep 26, 2019 at 2:46 PM Olof Johansson <olof@xxxxxxxxx> wrote: > > On Thu, Sep 26, 2019 at 12:34 PM Rob Herring <Rob.Herring@xxxxxxx> wrote: > > > > On 9/26/19 12:07 PM, Steve McIntyre wrote: > > > Hi all, > > > > > > A large group of us met yesterday at Linaro Connect in San Diego to > > > discuss this topic. I hope most people are on one of the two the > > > mailing lists here already - please forward if you think somebody is > > > not and should see this. > > Could have been cool to be cc:d. Luckily I don't filter the mailing > list out of my inbox today so I spotted it. Sorry, was mainly just trying to get it to *some* public list... [...] > > > So we do all arches, or just arm? Start with arm, iron out the > > > kinks. Once we're happy, move risc-v, ppc, etc. as/when their > > > maintainers care. There are a number of quiet arches with very few dts > > > files, as seen already. The SoC maintainers and Rob will clearly end > > > up maintaining the new tree to start with. > > > > Last we talked Arnd was not on board with maintaining this. Don't know > > about Olof. > > > > And let's not kid ourselves, there is no 'to start with' here. > > Whomever wants to split DTS files out of the kernel tree, gets to > maintain it. That includes the usual maintainership responsibilities > of making sure the quality of the contributions are at the expected > level, etc. > > My main opinion remains unchanged though -- given the way development > happens today, we should have at least a superset DT target in the > kernel -- usually this is a development/eval board for an SoC. > Derivative/product platforms based on that could live in an external > repo maintained elsewhere. But splitting up main DT and the > kernel/driver side today, including completely separate review/merge > paths would make for a more complicated setup, not a simpler one. > > Today we often rely on subsystem/driver maintainers to review and > chime in on bindings, header files, etc. If we do completely different > flows for the two efforts, it'll add significant overhead for > contributors and maintainers. Those reviews on bindings are a key sticking point for me. I don't see that getting transferred out of the kernel. Sure, maybe some can be coaxed into signing up to review those subsystem bindings in a new repository, but once the patches don't go thru their tree they'll eventually stop paying attention. Rob
