[U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Stephen Warren]

On 08/14/2015 01:20 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 10 August 2015 at 21:47, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 08/07/2015 07:42 AM, Simon Glass wrote:
>>> Enable device tree control so that we can use driver model fully and avoid
>>> using platform data.
>>
>> I'm still not convinced about this change.
>>
>> Re: the commit message about: What about the driver model is not being
>> fully used without DT?
> 
> Device tree control?

I am not convince about that argument. It seems rather self-fulfilling,
and irrelevant to me.

The fact that a feature exists shouldn't necessarily mean that it
absolutely must be used in all cases. There needs to be some benefit
from using the feature. What stability, performance, ... benefit does DT
give to a maintainer or user?

On a system that sources device information from ACPI, must DT still be
used because DM has that feature and without using it, DM isn't being
fully used?

I would strongly hope that DM is not tied to any particular source of
device information. A device model should be generic. The actions of
enumerating what devices exist (via C structures, DT, ACPI, ...) should
be completely independent from the process that then manages all of
those devices once they're enumerating/instantiated.

>> Overall: What advantage does using DT have to either a developer or an
>> end-user?
>>
>> I don't believe this patch fixes and bugs or enables any new features
>> for an end-user.
>>
>> From the maintainer perspective: It seems to me that it's far simpler to
>> have a tiny struct for each device in the C code than to pull in a whole
>> slew of DT parsing cruft just to work out the same struct at run-time.
>> As such, this patch can only make it harder to maintain the code since
>> there's more of it, and it's more complex.
>>
>> I just don't see the advantage of switching to DT for U-Boot control.
> 
> It allows us to share configuration with the kernel (same device tree
> file). This should be more familiar to people coming from there than
> our own configuration system. It's nice to have all the configuration
> in one place. We can then avoid using platform data in U-Boot unless
> it is necessary.

But at the cost of extra complexity in the U-Boot code that I don't
think is warranted. Equally, U-Boot's DT support is built on some
assumptions about DT structure and parsing rules that are inaccurate
(e.g. not honoring #address-cells, not parsing the DT in a hierarchical
manner thus not ensuring correct driver "probe" ordering, missing
features such as clock frameworks with pushback on supporting the
standard clock bindings rather than implementing U-Boot-specific
properties, etc.). It's not quite DT, but almost. It's quite unlikely
that any Linux DT will "just work". Once it doesn't always just work,
the advantage of similarity with kernel DTs is lost. As someone who's
ported U-Boot to various Tegra and RPi SoCs/boards, I honestly don't
think that using DT rather the C structures would have saved me any
time, and likely has caused me to spend more time debugging and fixing
DT issues in U-Boot.

> I really don't like the idea of filling up the code with platform data
> when that approach has already been rejected by Linux.

The Linux situation is entirely different from U-Boot.

Linux distros want to distribute a single generic Linux kernel binary
(and indeed generic install media, etc.) that runs on arbitrary systems
without having to worry about system-specific details. Ideally, the
distro can ship a single OS image which will work on arbitrary systems,
provided the system vendor ships the DT as part of the firmware and
provides it to the kernel. Of course, that hasn't actually happened yet
since the DTs are still in the kernel source tree and DT ABI isn't
anywhere near universal.

A bootloader or firmware is by definition system-specific. There's no
concept of a single image working across *arbitrary* systems. (Of
course, some U-Boot builds run on a small number of boards via runtime
detection, but by no means is any U-Boot binary entirely generic).
There's no need for it to be generic, since system vendors or
enterprising users build and install the firmware for a specific known
board/system.

As such, any arguments about Linux having chosen to use DT are likely
irrelevant to whether a firmware or bootloader should use it.