On Mon, Nov 18, 2013 at 12:38:11PM -0700, Stephen Warren wrote: > On 11/18/2013 12:28 PM, Jason Cooper wrote: > > On Mon, Nov 18, 2013 at 12:23:48PM -0700, Stephen Warren wrote: > >> On 11/18/2013 12:19 PM, Jason Cooper wrote: > >>> On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote: > >>>> On 11/18/2013 11:38 AM, Jason Cooper wrote: > >>>>> Unlike other build products in the Linux kernel, the devicetree blobs > >>>>> are simply the name of their source file, s/dts/dtb/. There is also no > >>>>> 'make *install' mechanism to put them in a standard place with a > >>>>> standard naming structure. > >>>>> > >>>>> Unfortunately, users have begun scripting pulling the needed dtbs from > >>>>> within the kernel tree, thus hardcoding the dtbs names. In turn, this > >>>>> means any changes to the dts filenames breaks these scripts. > >>>>> > >>>>> This patch is an attempt to fix this problem. Akin to 'make install', > >>>>> this creates a new make target, dtbs_install. The script that gets > >>>>> called defers to a vendor or distribution supplied installdtbs binary, > >>>>> if found in the system. Otherwise, the default action is to install a > >>>>> given dtb into > >> ... > >>>> This only appears to create ${compat}.dtb, and not ${dtb} too. > >>> > >>> See my comment, above. > >>> > >>>> So, it doesn't seem to address part of the cover letter, "In addition, > >>>> some vendors have done a diligent job naming their devicetree source > >>>> files appropriately and we don't want to break their setups." Was that > >>>> deliberate? If so, I guess I need to send some patches to U-Boot. > >>> > >>> I assume you are still pulling from arch/arm/boot/dts/*.dtb, right? > >>> Those build products don't go away with this patch, so you should be > >>> fine. Unless I'm mis-understanding your workflow... > >> > >> Yes, but I thought the whole point of this was that everyone would/could > >> switch to running "make dtbs_install", then pulling out the files from > >> the install tree, instead of any use-case requiring obtaining files > >> directly from the source/build tree? > > > > Yes, in the script, it checks for the existence of /sbin/installdtbs. > > If it's there, it will override the default behavior and execute that > > script. > > But that means everyone (a lot of people, and all distros) has to write, > or at least download and install, such a script. They would already be modifying their build environment to make use of 'make dtbs_install', and few extra lines of shell script to integrate with existing systems certainly isn't unreasonable? > Equally, that script would incorrectly affect the naming of non-Tegra > DTBs that follow the new convention. The naming of the Tegra DTBs is > based more on the fact that they're the Tegra DTBs than the fact that > I'm using them. Umm, I wrote that script in 2 minutes. I'm sure you could come up with something Tegra-specific (perhaps using fdtget?) that places only the Tegra dtbs in the location that works with Tegra's u-boot. The point is, we're trying to set a reasonable default, _and_ respect the pre-existing workflows. I don't think 15 lines of script is too much to ask. Especially since it would be written to adopt a *new* workflow, not fix a workflow broken by callous kernel maintainers. ;-) thx, Jason. -- 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