* (unknown), @ 2016-05-18 16:26 Warner Losh [not found] ` <CANCZdfow154vh3kHqUNUM6CoBsC9Vu3_+SEjFG1dz=FOkc9vsg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Warner Losh @ 2016-05-18 16:26 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA 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. 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). 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. 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CANCZdfow154vh3kHqUNUM6CoBsC9Vu3_+SEjFG1dz=FOkc9vsg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [not found] ` <CANCZdfow154vh3kHqUNUM6CoBsC9Vu3_+SEjFG1dz=FOkc9vsg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-05-18 18:02 ` Rob Herring [not found] ` <CAL_Jsq+s3PjzKCaT03EaqNCoyuwDQ6dXHDF808+U=hjvvfRYdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Rob Herring @ 2016-05-18 18:02 UTC (permalink / raw) To: Warner Losh Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA +devicetree-spec which is the right list. On Wed, May 18, 2016 at 11:26 AM, Warner Losh <imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> 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 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAL_Jsq+s3PjzKCaT03EaqNCoyuwDQ6dXHDF808+U=hjvvfRYdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: cpp to pre-process dts [not found] ` <CAL_Jsq+s3PjzKCaT03EaqNCoyuwDQ6dXHDF808+U=hjvvfRYdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-05-18 21:40 ` Frank Rowand [not found] ` <573CE131.6060101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-05-18 22:01 ` Warner Losh 1 sibling, 1 reply; 5+ messages in thread From: Frank Rowand @ 2016-05-18 21:40 UTC (permalink / raw) To: Warner Losh Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA 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-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> 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 > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <573CE131.6060101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: cpp to pre-process dts [not found] ` <573CE131.6060101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2016-05-18 21:41 ` Frank Rowand 0 siblings, 0 replies; 5+ messages in thread From: Frank Rowand @ 2016-05-18 21:41 UTC (permalink / raw) To: Warner Losh, Rob Herring Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA 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-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [not found] ` <CAL_Jsq+s3PjzKCaT03EaqNCoyuwDQ6dXHDF808+U=hjvvfRYdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-05-18 21:40 ` cpp to pre-process dts Frank Rowand @ 2016-05-18 22:01 ` Warner Losh 1 sibling, 0 replies; 5+ messages in thread From: Warner Losh @ 2016-05-18 22:01 UTC (permalink / raw) To: Rob Herring Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA On Wed, May 18, 2016 at 12:02 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > +devicetree-spec which is the right list. > > On Wed, May 18, 2016 at 11:26 AM, Warner Losh <imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-05-18 22:01 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-18 16:26 (unknown), Warner Losh [not found] ` <CANCZdfow154vh3kHqUNUM6CoBsC9Vu3_+SEjFG1dz=FOkc9vsg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-05-18 18:02 ` Rob Herring [not found] ` <CAL_Jsq+s3PjzKCaT03EaqNCoyuwDQ6dXHDF808+U=hjvvfRYdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-05-18 21:40 ` cpp to pre-process dts Frank Rowand [not found] ` <573CE131.6060101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-05-18 21:41 ` Frank Rowand 2016-05-18 22:01 ` Warner Losh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.