On 1/7/2022 7:12 AM, Tom Rini wrote: > On Thu, Jan 06, 2022 at 01:14:40PM -0800, Troy Kisky wrote: >> On 12/28/2021 5:11 AM, Tom Rini wrote: >>> On Tue, Dec 28, 2021 at 01:33:05AM -0700, Simon Glass wrote: >>>> Hi Troy, >>>> >>>> On Fri, 17 Dec 2021 at 16:02, Troy Kisky <troy.ki...@boundarydevices.com> >>>> wrote: >>>>> >>>>> This series intends to let board specific files live in the boards >>>>> directory. The last patch moves files for nitrogen6x. >>>>> I have tested it with buildman >>>>> >>>>> ./tools/buildman/buildman boundary -b denx_master >>>>> >>>>> But it is likely the more scripts then just tools/genboardscfg.py would >>>>> need to be updated. >>>>> >>>>> Troy Kisky (5): >>>>> kconfig: allow defconfigs to live in board directory >>>>> dts: allow dts files in board directory >>>>> scripts: Makefile.autoconf: allow CONFIG_SYS_CONFIG_NAME file to live >>>>> in board directory >>>>> genboardcfg: allow defconfigs in board directory >>>>> nitrogen6x: move board specific files to nitrogen6x directory >>>>> >>>>> arch/arm/dts/Makefile | 3 -- >>>>> board/boundary/nitrogen6x/MAINTAINERS | 13 ------- >>>>> board/boundary/nitrogen6x/Makefile | 13 +++++++ >>>>> .../nitrogen6x}/imx6dl-nitrogen6x.dts | 0 >>>>> .../boundary/nitrogen6x}/imx6q-nitrogen6x.dts | 0 >>>>> .../boundary/nitrogen6x}/imx6q-sabrelite.dts | 0 >>>>> .../nitrogen6x}/imx6qdl-nitrogen6x.dtsi | 0 >>>>> .../nitrogen6x}/imx6qdl-sabrelite.dtsi | 0 >>>>> .../nitrogen6x}/mx6qsabrelite_defconfig | 0 >>>>> .../nitrogen6x}/nitrogen6dl2g_defconfig | 0 >>>>> .../nitrogen6x}/nitrogen6dl_defconfig | 0 >>>>> .../nitrogen6x}/nitrogen6q2g_defconfig | 0 >>>>> .../boundary/nitrogen6x}/nitrogen6q_defconfig | 0 >>>>> .../nitrogen6x}/nitrogen6s1g_defconfig | 0 >>>>> .../boundary/nitrogen6x}/nitrogen6s_defconfig | 0 >>>>> .../boundary/nitrogen6x}/nitrogen6x.h | 2 +- >>>>> dts/Makefile | 11 +++++- >>>>> scripts/Makefile.autoconf | 9 ++++- >>>>> scripts/Makefile.lib | 1 + >>>>> scripts/kconfig/Makefile | 9 ++++- >>>>> tools/genboardscfg.py | 37 ++++++++++++++++++- >>>>> 21 files changed, 75 insertions(+), 23 deletions(-) >>>>> rename {arch/arm/dts => board/boundary/nitrogen6x}/imx6dl-nitrogen6x.dts >>>>> (100%) >>>>> rename {arch/arm/dts => board/boundary/nitrogen6x}/imx6q-nitrogen6x.dts >>>>> (100%) >>>>> rename {arch/arm/dts => board/boundary/nitrogen6x}/imx6q-sabrelite.dts >>>>> (100%) >>>>> rename {arch/arm/dts => >>>>> board/boundary/nitrogen6x}/imx6qdl-nitrogen6x.dtsi (100%) >>>>> rename {arch/arm/dts => >>>>> board/boundary/nitrogen6x}/imx6qdl-sabrelite.dtsi (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/mx6qsabrelite_defconfig >>>>> (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/nitrogen6dl2g_defconfig >>>>> (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/nitrogen6dl_defconfig >>>>> (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/nitrogen6q2g_defconfig >>>>> (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/nitrogen6q_defconfig (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/nitrogen6s1g_defconfig >>>>> (100%) >>>>> rename {configs => board/boundary/nitrogen6x}/nitrogen6s_defconfig (100%) >>>>> rename {include/configs => board/boundary/nitrogen6x}/nitrogen6x.h (98%) >>>>> I'm not about the goal. >>>> >>>> Can you please add a few notes about the motivation for this change? >>> >>> Sorry for the delayed reply here. I'm also not entirely sure this is a >>> good idea. Moving the defconfig files? Maybe. It does make checking >>> all configs a bit more tricky, but indeed the configs directory is >>> unwieldy. Moving the dts files? Those should be a direct cp from the >>> kernel, so that makes things less clear to me. Especially since it will >>> need other common files that will still be elsewhere. >>> >> >> They will still be a direct copy. Notice the 100% rename. Common files still >> living in the dts >> directory is less clear. I can try to address the "piecemeal building of >> .dts files" if this >> still has a chance of being accepted. > > So, here's my worry. Today, in an ideal world that we're not yet at, I > could do: > 1. cd ~/src/linux; git checkout v5.16 > 2. cd ~/src/u-boot; for DTS in arch/arm/dts/*.dts*; do \ > [ -f ~/src/linux/$DTS ] && cp ~/src/linux/$DTS $DTS; done >
Still, a script could easily check that a dts file exists before overwriting it and find the correct directory to put it in. A little more complicated, but not a lot. > And now we're resynced with v5.16. That gets a lot more complex with > board/*/*/*.dts* too. And since those files should be direct imports > I'm not sure how them residing in board/ helps. One thing that maybe be worth remembering, at one time, Linus was suggesting that dtb's would NOT be a permanent part of Linux. That has probably changed, but maybe eventually, that master repo will be vendor specific. > > But! I can see how having board-u-boot.dtsi exist under board/ might > help. Or at least, having those files reside somewhere that's NOT where > the unmodified imported dts files also live. Long term I think we need > to move towards making it easier to import the dts files, and clearer > that they should be "read only" other than when being resynced, than it > is today. > If you guys are OK with any of the patches, let me know, and I'll submit a restricted series. Thanks Troy