On Thu, Sep 26, 2019 at 3:14 PM Emmanuel Vadot <manu@xxxxxxxxxxxxxxxx> wrote: > > > Hello all, > > On Thu, 26 Sep 2019 13:58:35 -0600 > Steve McIntyre <steve.mcintyre@xxxxxxxxxx> wrote: > > > Arg, missed the CC to the devicetree-spec list. > > > > ----- Forwarded message from Steve McIntyre <steve.mcintyre@xxxxxxxxxx> ----- > > > > From: Steve McIntyre <steve.mcintyre@xxxxxxxxxx> > > To: dte-all@xxxxxxxxxx > > Cc: dan.handley@xxxxxxx, Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>, > > broonie@xxxxxxxxxx > > Date: Thu, 26 Sep 2019 18:07:30 +0100 > > Subject: Meeting notes: Planning around splitting devicetree data out of the > > Linux tree > > User-Agent: Mutt/1.10.1 (2018-07-13) > > > > 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. > > > > (probably incomplete) list of attendees > > ======================================= > > Steve McIntyre, Arm/Linaro > > Bill Fletcher, Linaro > > Bruce Ashfield, Xilinx > > Mark Brown, Arm > > Stefano Stabellini, Xilinx > > Arnd Bergmann, Linaro > > Grant Likely, Arm > > Mathieu Poirier, Linaro > > Loic Pallardy, ST > > ???, Socionext > > > > Notes > > ===== > > > > Please correct me if you think I'm missed/mis-described something... > > > > We believe that it's time to move arm and arm64 DT data out of the > > kernel tree to a separate repo, on github. Arnd showed a graph showing > > the number of dts files, grouped by architecture. Vast majority are > > for arm/arm64, with a small number elsewhere. *Still* not all arm > > platforms have moved across to DT totally (e.g. omap2). > > > > What work needs to be done? > > > > * create repo (github.com/devicetree.org/dts) > > * move the dts files, bindings, and header files across *together* - > > they make no sense separately. > > > > Is anybody else except Linux using the header files we have? not that > > we know of. > > If you are talking about the headers include/dt-bindings at least > FreeBSD, NetBSD and OpenBSD are using it to some extent. > Talking just about FreeBSD now, we include them in our kernel drivers > when the licence is fine with us (X11 was chosen for some reason). Anything with an SPDX tag should use "MIT" instead. Uses of X11 are likely a mistake. X11 in the SPDX definition is a specific copyright too. > We need them for clocks/reset/etc... ids. > When the licence isn't okay for us (GPL) we redifine the ID in our > drivers. I've always wondered if such include should/can be licenced > anyway, those are just numbers that we need to know. IANAL, so someone should ask one. Perhaps someone wants to write a script to extract author email's with git blame and email authors' for permission to dual-license. I'm pretty sure we have a "good" mixture of licenses and no one really pays attention on what's combined together or copied around. Trying to do a better job on schemas... > > As the first aim, we'd copy things from the external repo into the > > kernel tree periodically - just like we do with dtc already. Later on, > > we might revisit that decision. > > What would be the difference with the devicetree-rebasing repo ? > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > This is the one I'm using to import DTS into the FreeBSD source tree. That's good to know. The lack of knowledge (or perceived lack) about it seems to be part of what's driving all this. It's good to hear it's being used (I was only aware of barebox using it) and any issues around it. > > if we move the DTS files out, would we still want to build them with > > the kernel? Why? Should the kernel build sync things across > > automatically at build time? Sometimes mips and ppc build the DTB > > files into a bootable image format, so there is a dependency there for > > those arches. Not for arm/arm64. > > > > We have a prototype patchset for the kernel which would add support > > for out-of-tree dts files. Needs re-evaluating, it's gone stale. > > DTS are known to break backward compatibility so a kernel (Linux or > *BSD) needs to be in sync with them. We need people to yell and complain when that happens. It should not be okay except in the early stages of adding support. Testing compatibility with older and newer DTs in kernel-CI as mentioned elsewhere should help. Rob
