On Thu, Sep 26, 2019 at 1:09 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > 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... Yep, no worry -- and I appreciate that effort. > [...] > > > > > 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. Right, so with that chain: - People who care should review ... and - The people who currently care are the kernel folks ... and - Kernel folks always want to see the user of something at the same time since it aids review to see how things are used ... which means - Having bindings and DTSI and one (or more) DTS instantiations and include and driver go together ... which means - I don't see how we can do this outside of the kernel tree. But, again, derivative DTS/product instantiations could be just fine to track elsewhere. -Olof
