On 5/18/2016 2:40 PM, Frank Rowand wrote: > And adding a non-blank subject so people won't ignore the thread. > > -Frank > > On 5/18/2016 11:02 AM, Rob Herring 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. >> >>> 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. >> >> 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. >> >>> 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 The header files will exist in the linux kernel source tree because drivers use the defines. I would expect the number of defines for values in the document to be small enough and the document to be stable enough that the linux kernel header files and and other kernel's header files (such as the BSDs) can be manually maintained and kept in sync with the document. We will find out if my guess is accurate as we add bindings to the spec - no need to optimize prematurely today. >> discussion around having machine parseable bindings as both the >> documentation source and binding validation source, but nothing >> concrete. >> >>> 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. >> >> Rob >> -- >> 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 >> > > -- 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
