From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: "Andreas Färber" <afaerber-l3A5Bk7waGM@public.gmane.org> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>, Alexandre Belloni <alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>, Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>, Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>, Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Gregory CLEMENT <gregory.clement-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, ARM-SoC Maintainers <arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>, Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Architecture Mailman List <boot-architecture-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org> Subject: Re: Moving ARM dts files Date: Tue, 4 Dec 2018 22:17:15 -0600 [thread overview] Message-ID: <CAL_JsqKO3v0pgVfNhVNOkpZ4sePrybDgZG0riN-tutvwOZ4zYg@mail.gmail.com> (raw) In-Reply-To: <9c2b5528-679a-928e-3150-aa383a4f0405-l3A5Bk7waGM@public.gmane.org> On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber <afaerber@suse.de> wrote: > > Rob, > > Am 04.12.18 um 19:36 schrieb Rob Herring: > > I've put together a script to move the dts files and update the > > makefiles. It doesn't handle files not following a common prefix which > > isn't many and some includes within the dts files will need some fixups > > by hand. > > > > MAINTAINERS will also need updating. > > > > A few questions: > > > > Do we want to move absolutely everything to subdirs? > > This refactoring is a terrible idea! How do you really feel? > While it would've been nice to have more structure from the start, > bootloaders like U-Boot expect a flat structure for arm .dtb files now. > If you start installing them into subdirs instead, they won't find the > files anymore under the hardcoded name. > > Doing this only for new platforms would be much less invasive and allow > to prepare bootloaders accordingly. That was my suggestion where this started for the new RDA platform. Olof preferred to move everything and that's my desire too. > Alternatively, white-list which ones > are safe to move around. I'd prefer to know which ones the distros don't want moved. That should be easier to figure out. We also need that anyways in context of what platforms we care about compatibility. Another option is dtbs_install target could flatten the installed dtbs. That is the only part the distros should depend on. > But don't just script a refactoring because it > looks nicer in the source tree, without testing what side effects this > can have for board/distro users of the compiled files in practice. > We already had that discussion for arm64 because Debian chose to ignore > the kernel-installed subdirectories and installed .dtb files into a flat > directory, which collided with openSUSE sticking to the kernel choice. So everyone already deals with subdirs or not with arm and arm64 already, seems like they can deal with this. I will raise the topic on the cross-distro list though. > This topic becomes even more important with EBBR: There is neither a > mechanism in place to sync .dts files into U-Boot or EDK2 source trees, > nor are capsule updates implemented in U-Boot for easily deploying such > bootloaders with new .dts sources or paths yet. EBBR actually says firmware (including dtbs) goes in directories named by vendor. > And I can assure you > that just getting users to dd the right bootloader can be difficult... > Since DT forward and backward compatibility is often being neglected, > for example with optional properties or renamed compatibles that break > booting with previous drivers, new kernel versions often need updated > Device Trees to make use of new/enhanced drivers. Therefore it is > unfortunately often enough a necessity to load newer kernel-based .dtb > files matching the kernel (as opposed to the dream of kernel-independent > hardware descriptions) when working with the latest -rc or -next kernels > at least. For examples of DTs needing updates, look no further than > Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where > .dtb paths may be hardcoded, ditto for arm; and Armada was an example > where the upstream bindings for the network IP changed incompatibly. Compatibility is an issue, yes, but that really has nothing to do with this. > DT overlays are another topic that is not making any progress upstream > according to the ELCE BoF, so beyond the Raspberry Pi the only known > working way to apply them is to write a U-Boot boot.scr script, which > can either reuse $fdtcontroladdr DT or use the filename $fdtfile or > hardcode one, the latter two of which would break with your renaming. DT overlays also have nothing to do with this as there aren't any in the kernel. I'm not inclined to take any either with a flat tree. We're already at 1800+ files. Rob _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: "Andreas Färber" <afaerber@suse.de> Cc: Andrew Lunn <andrew@lunn.ch>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Tony Lindgren <tony@atomide.com>, Linus Walleij <linus.walleij@linaro.org>, Liviu Dudau <liviu.dudau@arm.com>, Alexander Graf <agraf@suse.de>, Masahiro Yamada <yamada.masahiro@socionext.com>, Thierry Reding <thierry.reding@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Kevin Hilman <khilman@kernel.org>, Gregory CLEMENT <gregory.clement@bootlin.com>, Michal Simek <michal.simek@xilinx.com>, Krzysztof Kozlowski <krzk@kernel.org>, ARM-SoC Maintainers <arm@kernel.org>, Joel Stanley <joel@jms.id.au>, Andy Gross <andy.gross@linaro.org>, devicetree@vger.kernel.org, Architecture Mailman List <boot-architecture@lists.linaro.org>, Jason Cooper <jason@lakedaemon.net>, Simon Horman <horms@verge.net.au>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, Grant Likely <Grant.Likely@arm.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Shawn Guo <shawnguo@kernel.org>, Daniel Mack <daniel@zonque.org> Subject: Re: Moving ARM dts files Date: Tue, 4 Dec 2018 22:17:15 -0600 [thread overview] Message-ID: <CAL_JsqKO3v0pgVfNhVNOkpZ4sePrybDgZG0riN-tutvwOZ4zYg@mail.gmail.com> (raw) In-Reply-To: <9c2b5528-679a-928e-3150-aa383a4f0405@suse.de> On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber <afaerber@suse.de> wrote: > > Rob, > > Am 04.12.18 um 19:36 schrieb Rob Herring: > > I've put together a script to move the dts files and update the > > makefiles. It doesn't handle files not following a common prefix which > > isn't many and some includes within the dts files will need some fixups > > by hand. > > > > MAINTAINERS will also need updating. > > > > A few questions: > > > > Do we want to move absolutely everything to subdirs? > > This refactoring is a terrible idea! How do you really feel? > While it would've been nice to have more structure from the start, > bootloaders like U-Boot expect a flat structure for arm .dtb files now. > If you start installing them into subdirs instead, they won't find the > files anymore under the hardcoded name. > > Doing this only for new platforms would be much less invasive and allow > to prepare bootloaders accordingly. That was my suggestion where this started for the new RDA platform. Olof preferred to move everything and that's my desire too. > Alternatively, white-list which ones > are safe to move around. I'd prefer to know which ones the distros don't want moved. That should be easier to figure out. We also need that anyways in context of what platforms we care about compatibility. Another option is dtbs_install target could flatten the installed dtbs. That is the only part the distros should depend on. > But don't just script a refactoring because it > looks nicer in the source tree, without testing what side effects this > can have for board/distro users of the compiled files in practice. > We already had that discussion for arm64 because Debian chose to ignore > the kernel-installed subdirectories and installed .dtb files into a flat > directory, which collided with openSUSE sticking to the kernel choice. So everyone already deals with subdirs or not with arm and arm64 already, seems like they can deal with this. I will raise the topic on the cross-distro list though. > This topic becomes even more important with EBBR: There is neither a > mechanism in place to sync .dts files into U-Boot or EDK2 source trees, > nor are capsule updates implemented in U-Boot for easily deploying such > bootloaders with new .dts sources or paths yet. EBBR actually says firmware (including dtbs) goes in directories named by vendor. > And I can assure you > that just getting users to dd the right bootloader can be difficult... > Since DT forward and backward compatibility is often being neglected, > for example with optional properties or renamed compatibles that break > booting with previous drivers, new kernel versions often need updated > Device Trees to make use of new/enhanced drivers. Therefore it is > unfortunately often enough a necessity to load newer kernel-based .dtb > files matching the kernel (as opposed to the dream of kernel-independent > hardware descriptions) when working with the latest -rc or -next kernels > at least. For examples of DTs needing updates, look no further than > Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where > .dtb paths may be hardcoded, ditto for arm; and Armada was an example > where the upstream bindings for the network IP changed incompatibly. Compatibility is an issue, yes, but that really has nothing to do with this. > DT overlays are another topic that is not making any progress upstream > according to the ELCE BoF, so beyond the Raspberry Pi the only known > working way to apply them is to write a U-Boot boot.scr script, which > can either reuse $fdtcontroladdr DT or use the filename $fdtfile or > hardcode one, the latter two of which would break with your renaming. DT overlays also have nothing to do with this as there aren't any in the kernel. I'm not inclined to take any either with a flat tree. We're already at 1800+ files. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2018-12-05 4:17 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-04 18:36 Moving ARM dts files Rob Herring 2018-12-04 18:36 ` Rob Herring 2018-12-04 18:47 ` Alexandre Belloni 2018-12-04 18:47 ` Alexandre Belloni 2018-12-04 19:09 ` Rob Herring 2018-12-04 19:09 ` Rob Herring 2018-12-04 22:21 ` Simon Horman 2018-12-04 22:21 ` Simon Horman 2018-12-05 1:22 ` Andreas Färber 2018-12-05 1:22 ` Andreas Färber [not found] ` <9c2b5528-679a-928e-3150-aa383a4f0405-l3A5Bk7waGM@public.gmane.org> 2018-12-05 4:17 ` Rob Herring [this message] 2018-12-05 4:17 ` Rob Herring 2018-12-05 17:33 ` Tom Rini 2018-12-05 17:33 ` Tom Rini 2018-12-06 13:32 ` Andreas Färber 2018-12-06 13:32 ` Andreas Färber 2018-12-06 19:06 ` Rob Herring 2018-12-06 19:06 ` Rob Herring 2018-12-06 20:06 ` Mark Brown 2018-12-06 20:06 ` Mark Brown [not found] ` <20181206200652.GB3084-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2018-12-06 20:49 ` Olof Johansson 2018-12-06 20:49 ` Olof Johansson 2018-12-07 14:57 ` Rob Herring 2018-12-07 14:57 ` Rob Herring 2018-12-07 15:16 ` Mark Brown 2018-12-07 15:16 ` Mark Brown [not found] ` <20181207151625.GC6510-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2018-12-07 15:29 ` Rob Herring 2018-12-07 15:29 ` Rob Herring 2018-12-06 20:14 ` Tom Rini 2018-12-06 20:14 ` Tom Rini 2018-12-05 4:18 ` Masahiro Yamada 2018-12-05 4:18 ` Masahiro Yamada 2018-12-05 9:48 ` Michal Simek 2018-12-05 9:48 ` Michal Simek 2018-12-05 6:02 ` Jisheng Zhang 2018-12-05 6:02 ` Jisheng Zhang 2018-12-05 8:19 ` Linus Walleij 2018-12-05 8:19 ` Linus Walleij 2018-12-05 8:34 ` Jisheng Zhang 2018-12-05 8:34 ` Jisheng Zhang 2018-12-05 9:04 ` Linus Walleij 2018-12-05 9:04 ` Linus Walleij 2018-12-05 15:01 ` Rob Herring 2018-12-05 15:01 ` Rob Herring 2018-12-05 21:03 ` Linus Walleij 2018-12-05 21:03 ` Linus Walleij 2018-12-06 13:39 ` Uwe Kleine-König 2018-12-06 13:39 ` Uwe Kleine-König 2018-12-06 13:58 ` Rob Herring 2018-12-06 13:58 ` Rob Herring 2018-12-06 14:05 ` Alexandre Belloni 2018-12-06 14:05 ` Alexandre Belloni 2018-12-06 14:30 ` Linus Walleij 2018-12-06 14:30 ` Linus Walleij 2018-12-06 16:57 ` Rob Herring 2018-12-06 16:57 ` Rob Herring 2018-12-06 22:12 ` Linus Walleij 2018-12-06 22:12 ` Linus Walleij 2018-12-07 23:35 ` Tony Lindgren 2018-12-07 23:35 ` Tony Lindgren 2018-12-05 8:13 ` Nicolas.Ferre 2018-12-05 8:13 ` Nicolas.Ferre 2018-12-05 15:14 ` Neil Armstrong 2018-12-05 15:14 ` Neil Armstrong 2018-12-05 17:36 ` Li Yang 2018-12-05 17:36 ` Li Yang 2018-12-07 22:33 ` Rob Herring 2018-12-07 22:33 ` Rob Herring 2018-12-08 9:25 ` Krzysztof Kozlowski 2018-12-08 9:25 ` Krzysztof Kozlowski 2018-12-08 22:40 ` Linus Walleij 2018-12-08 22:40 ` Linus Walleij 2018-12-11 15:58 ` Olof Johansson 2018-12-11 15:58 ` Olof Johansson 2018-12-08 10:07 ` Ian Campbell 2018-12-08 10:07 ` Ian Campbell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAL_JsqKO3v0pgVfNhVNOkpZ4sePrybDgZG0riN-tutvwOZ4zYg@mail.gmail.com \ --to=robh-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \ --cc=afaerber-l3A5Bk7waGM@public.gmane.org \ --cc=agraf-l3A5Bk7waGM@public.gmane.org \ --cc=alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org \ --cc=andrew-g2DYL2Zd6BY@public.gmane.org \ --cc=andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=boot-architecture-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=gregory.clement-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org \ --cc=horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org \ --cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \ --cc=joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org \ --cc=khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=liviu.dudau-5wv7dgnIgG8@public.gmane.org \ --cc=michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \ --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \ --cc=yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.