Re: [PATCH v3] schemas: Add schema for U-Boot driver model 'phase tags'

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

On Mon, Oct 10, 2022 at 11:34:00AM -0500, Rob Herring wrote:
> On Tue, Oct 4, 2022 at 6:22 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Until recently it has not been possible to add any U-Boot-specific
> > properties to the device tree schema. Now that it is somewhat separated
> > from Linux and people are feeling the enormous pain of the bifurcated
> > schema, it seems like a good time to add this and other U-Boot-specific
> > bindings.
> 
> It's been possible provided there was agreement on the properties.
> There just wasn't in this case.
> 
> What's the pain point precisely? I can think of several. Syncing dts
> files from Linux tree, running schema validation on a dtb from u-boot,
> or ...?

So, we have a few related pain points. As background, one thing we do
today is have a "-u-boot.dtsi" file and then cmd_dtc in
scripts/Makefile.lib (which is +- the same as Linux) has logic to find
and -include it. This file is supposed to include all of the properties
that U-Boot needs added (and this patch schema is intended to start
addressing) to produce the dtb we need. This information can't be
accepted in the upstream dts files as there's no binding schema
associated with it. It's only a pain point during re-sync when trees
have been fixed upstream and now node names change and so forth. But it
does mean that we can't just drop in new dts files. We aren't attempting
to run validation ourselves right now, but getting something like this
merged means we can change our new dts requirement from "must be in
Linus' tree or at least linux-next" to "must be in Linus' tree or at
least linux-next and passing the dtschema check".

[snip]
> > - Some U-Boot phases needs to run before the clocks are properly set up,
> >   where the CPU may be running very slowly. Therefore it is important to
> >   bind only those devices which are actually needed in that phase
> > - Unlike Linux or UEFI, U-Boot uses lazy initialisation for its devices,
> >   with 'bind' and 'probe' being separate steps. Even if a device is bound,
> >   it is not actually probed until it is used. This is necessary to keep
> >   the boot time reasonable, e.g. to under a second
> 
> Linux could do this now if we wanted. There's a full dependency graph.
> Once you have that, it's just an implementation decision whether you
> probe top down or bottom up. We have this graph because Linux specific
> probing hint properties in DT was rejected. (Not saying u-boot needs
> to go implement a dependency graph, but rather u-boot is not unique
> here and there's more than one way to solve it.)

Further points in the commit message that need to be reworded as what
U-Boot does and not what other projects might not be doing.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]