On Wed, May 18, 2016 at 12:02 PM, Rob Herring <robh@xxxxxxxxxx> wrote: > +devicetree-spec which is the right list. > > On Wed, May 18, 2016 at 11:26 AM, Warner Losh <imp@xxxxxxxxxx> wrote: >> Greetings, >> >> I was looking at the draft link posted here >> https://github.com/devicetree-org/devicetree-specification-released/blob/master/prerelease/devicetree-specification-v0.1-pre1-20160429.pdf >> a while ago. I hope this is the right place to ask about it. >> >> It raised a bit of a question. There's nothing in it talking about the >> current >> practice of using CPP to pre-process the .dts/.dtsi files before passing >> them >> into dtc to compile them into dtb. > > Can't say I'm really a fan of it. Yes. But fan or no, there's a huge base that depends on it, and on some quirky behavior to boot. So better to accept and document and move on. >> Normally, I see such things outside the scope of standardization. However, >> many of the .dts files that are in the wild today use a number of #define >> constants to make things more readable (having GPIO_ACTIVE_HIGH >> instead of '0' makes the .dts files easier to read). However, there's a >> small >> issue that I've had. The files that contain those definitions are currently >> in the Linux kernel and have a wide variety of licenses (including none >> at all). > > Yes, this is a problem. In lieu of any explicit license, I'd say the > license defaults to GPL. There is also the same issue with the > Documentation as we plan to move some of the common bindings such as > clocks, gpio, etc. into the spec which is Apache licensed. I tend to agree. > In both cases, we're going to need to get permission of the authors to > re-license. For the headers, these should be patches to the kernel. > For the docs, we just need to record the permission when committing > the addition to the spec. Neither should be too hard as they should > not be changing much and we have complete history in git. Personally, I'd opt to cut the original authors completely out of the loop and generate the files. I have nothing against the original authors, but to be maximally interoperable, I think this option should be seriously considered. >> So before even getting to the notion of licenses and such (which past >> expereince suggests may be the worst place to start a discussion), I'm >> wondering where that will be defined, and if these #defines will become >> part of the standard for each of the bindings that are defined. > > Perhaps. We need to at least define the standard flag values if not > the symbolic name. I don't think it makes sense to both document and > maintain headers of the defines. We should ideally just have 1 source > for all and generate what we need from it. There's been some related > discussion around having machine parseable bindings as both the > documentation source and binding validation source, but nothing > concrete. I think it would make sense to have a machine-parseable format that allows generation of the header files. Once they become generated, the license issue goes away. None of these files have much creative content anyway, and they certainly don't need to have what little creative content they have if it were included as part of a machine-parseable file. >> I'm also wondering where the larger issue of using cpp to process the dts >> files will be discussed, since FreeBSD's BSDL dtc suffers interoperability >> due to this issue. Having the formal spec will also be helpful for its care and >> feeding since many fine points have had to be decided based on .dts >> files in the wild rather than a clear spec. >> >> Thanks again for spear-heading the effort to get a new version out now >> that ePAPR has fallen on hard times. >> >> Warner >> >> P.S. I'm mostly a FreeBSD guy, but just spent some time digging into this >> issue for another of the BSDs that's considering adopting DTS files. > > We certainly need and want the BSD folks involved in the spec. Excellent! There's many people that are quire interested. Warner -- 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
