[U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi

[Stephen Warren]

On 07/28/2015 09:44 AM, Simon Glass wrote:
> On 28 July 2015 at 07:55, Tom Rini <trini at konsulko.com> wrote:
...
>> Maybe examples like these are why we will need (and want) to keep
>> platform data as a possibility in our DM work.  There's value in keeping
>> the DT that we use as minimal as possible (so that it can work as
>> broadly as possible) and then do run-time fixups.  The other option here
>> might be something like device tree overlays or at least exposing the
>> running DT (... more readily, I bet you could kludge it today) so that
>> the existing cli infrasturcture can modify it).
> 
> I really like the idea of keeping the DT minimal rather than
> slavishing adding a whole lot of detail for every board. If things can
> be probed then I think it is acceptable to probe them to avoid an
> explosion of DTs. We can do run-time fix ups even if they are
> currently not very efficient. The 'fdt' command can modify the running
> FDT I think, but it currently breaks everything since by then we have
> devices and have recorded the DT offsets. We could add a DT library to
> fix this, but for now fix-ups need to be done before relocation.

There are two cases for probing:

a) Standard buses that are probe-able in a standard way, like USB.

It makes sense to probe these since the probing code is generic across a
wide variety of systems and hence the code can be considered generic.

b) Device-specific information sources (such as the RPi firmware etc.).

Code for this isn't at all re-usable across systems. In the kernel,
there's been some tendency to push for SW that runs before the kernel to
probe these information sources and add the relevant information into
the DT (or just include the information statically in DT source files),
rather than including system-specific code in the kernel to do the
probing. This keeps kernel code size down and avoids lots of non-generic
code.

Related, if the kernel knew it booted on nvidia,jetson-tk1, then that
information is enough to tell the kernel the entire set of devices that
are attached (aside from anything attached to the USB, PCIe, HDMI
controllers). We could probe a board file from just the board name:-)

DT schema/content is intended to be identical across all SW stacks so
that it can be shared. There's a bit of friction here re: what a
bootloader and OS kernel might want in DT vs. what they could/prefer-to
probe themselves using device-specific code:-(