On Wednesday 07 May 2014 16:06:49 Eric Nelson wrote: > On 05/07/2014 03:20 PM, Bjorn Andersson wrote: > > On Wed, May 7, 2014 at 12:52 PM, Eric Nelson > > <eric.nelson@xxxxxxxxxxxxxxxxxxx> wrote: > > [...] > >> > >> I still wonder about the choice of not allowing inclusion > >> of at least include/generated/autoconf.h. > > > > Because what you just showed is the use case where you have 1 defconfig, build 1 > > zImage and then you can have a completely separate delivery of X number of > > dtbs, all defining some variant of your original board. > > All without recompiling, or even have the source available. > > > > I agree that there's some benefit in being able to generate > different DTBs, and it's an advantage (size, speed) to customize > the .config as well. > > When those clearly go together, it seems natural to define them as > such. > > I've heard (and appreciate) the pointers about how to get > past our current issue(s), but what's the rationale > for not allowing the inclusion of autoconf.h and > conditionals in the DTS? > > Is it a concern that things will become polluted and > hard to read? You should be able to take any recent enough Fedora/Debian/OpenSUSE/Ubuntu/OpenWRT kernel binary and install it on all ARMv7 machines to get a working system, keeping your existing .dtb file. There are still a few issues to be worked out for that (e.g. some drivers still can't be described in DT, and in some exceptional cases we break backwards compatibility), but if the .dtb file depends on the kernel configuration, it can never work, because the person building the kernel does not know what hardware you have. Arnd -- 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
