From: "Andreas Färber" <afaerber@suse.de>
To: Rob Herring <robh@kernel.org>, Tom Rini <trini@konsulko.com>
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>,
LAKML <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: Thu, 6 Dec 2018 14:32:27 +0100 [thread overview]
Message-ID: <2474284e-8a55-639f-2cfa-f811741099f3@suse.de> (raw)
In-Reply-To: <CAL_JsqKO3v0pgVfNhVNOkpZ4sePrybDgZG0riN-tutvwOZ4zYg@mail.gmail.com>
Am 05.12.18 um 05:17 schrieb Rob Herring:
> 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.
I'd be okay with distinguishing source vs. install location. Due to the
issue I mention below (and more) we can't use install_dtbs for openSUSE
and had to reimplement it, which we'd need to (and can) adjust.
>> 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.
Sounds like you're twisting words... The keyword was "hardcoded" paths -
one way or another (not "and") depending on the kernel choices being
flat for arm, vendor subdir for arm64.
>> 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.
Fine, but unrelated.
>> 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.
Read again: a) Breaking DT changes and b) the desire to use Overlays
instead of replacing the bootloaders for each change are _reasons_ why
people depend on .dtb filenames from the kernel source tree for their
boot flow today. Nothing to do with downstream .dtbo files.
For example, remember when I reported that the kernel didn't compile DTs
with -@? No reaction except for Frank asking to be CC'ed - was it ever
fixed??? Do EDK2's or U-Boot's built-in DTs compile with -@ today?
Raspberry Pi overlays in U-Boot work because it switched to passing the
DT through from the proprietary firmware.
Point being that while it would be nice to get a current, compatible DT
via UEFI tables and ignore .dtb filenames outside of a few bootloaders,
in reality we're not quite there yet for all platforms.
I see no problem (except for naming choices) moving new targets like RDA
to subfolders because we can then hardcode it the new way; I also assume
deeply embedded targets like stm32f4 or targets with no mainline
bootloaders yet like owl-s500 could be refactored.
I do see problems refactoring widely used SBC targets like sunXi though.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
_______________________________________________
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-06 13:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 18:36 Moving ARM dts files Rob Herring
2018-12-04 18:47 ` Alexandre Belloni
2018-12-04 19:09 ` Rob Herring
2018-12-04 22:21 ` Simon Horman
2018-12-05 1:22 ` Andreas Färber
2018-12-05 4:17 ` Rob Herring
2018-12-05 17:33 ` Tom Rini
2018-12-06 13:32 ` Andreas Färber [this message]
2018-12-06 19:06 ` Rob Herring
2018-12-06 20:06 ` Mark Brown
2018-12-06 20:49 ` Olof Johansson
2018-12-07 14:57 ` Rob Herring
2018-12-07 15:16 ` Mark Brown
2018-12-07 15:29 ` Rob Herring
2018-12-06 20:14 ` Tom Rini
2018-12-05 4:18 ` Masahiro Yamada
2018-12-05 9:48 ` Michal Simek
2018-12-05 6:02 ` Jisheng Zhang
2018-12-05 8:19 ` Linus Walleij
2018-12-05 8:34 ` Jisheng Zhang
2018-12-05 9:04 ` Linus Walleij
2018-12-05 15:01 ` Rob Herring
2018-12-05 21:03 ` Linus Walleij
2018-12-06 13:39 ` Uwe Kleine-König
2018-12-06 13:58 ` Rob Herring
2018-12-06 14:05 ` Alexandre Belloni
2018-12-06 14:30 ` Linus Walleij
2018-12-06 16:57 ` Rob Herring
2018-12-06 22:12 ` Linus Walleij
2018-12-07 23:35 ` Tony Lindgren
2018-12-05 8:13 ` Nicolas.Ferre
2018-12-05 15:14 ` Neil Armstrong
2018-12-05 17:36 ` Li Yang
2018-12-07 22:33 ` Rob Herring
2018-12-08 9:25 ` Krzysztof Kozlowski
2018-12-08 22:40 ` Linus Walleij
2018-12-11 15:58 ` Olof Johansson
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=2474284e-8a55-639f-2cfa-f811741099f3@suse.de \
--to=afaerber@suse.de \
--cc=Grant.Likely@arm.com \
--cc=agraf@suse.de \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@lunn.ch \
--cc=andy.gross@linaro.org \
--cc=arm@kernel.org \
--cc=boot-architecture@lists.linaro.org \
--cc=daniel@zonque.org \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=gregory.clement@bootlin.com \
--cc=horms@verge.net.au \
--cc=jason@lakedaemon.net \
--cc=joel@jms.id.au \
--cc=khilman@kernel.org \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=liviu.dudau@arm.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=michal.simek@xilinx.com \
--cc=robh@kernel.org \
--cc=shawnguo@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=tony@atomide.com \
--cc=trini@konsulko.com \
--cc=yamada.masahiro@socionext.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).