On Tue, Apr 12, 2022 at 4:41 PM T.Michael Turney
<quic_mturney@xxxxxxxxxxx> wrote:
>
> Rob,
> Thanks for response on previous query, hopefully over summer, when we
> have intern on project we will be able to spare cycles to push warning
> as error flag for dtc.
>
> Along with rolling out dt-schema support on our non-kernel project, we
> are also prototyping how best to use overlay support, which leads to
> this post.
>
> Since a typical overlay source file doesn't follow standard DeviceTree
> format/syntax, dt-schema doesn't seem compatible with overlay files. I
> hope I'm missing something.
Most of the syntax is the same, so it's compatible from that
perspective. And we already handle most of the meta-data that's
generated and added to the DTB. The examples in the schemas are in
fact built as overlays (primarily for the allowing of unresolved
phandles feature).
> This is simple overlay source file we are using and confirmed it works
> on target, in so far as libfdt calls execute without error and runtime
> code sees new and updated properties.
>
> /dts-v1/;
> /plugin/;
>
> &soc {
> compatible = "abc,xyz-soc", "abc,xyz-soc-platform", "abc,xyz", "abc,soc";
> new_property = <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07>;
> };
>
> &sw {
> boot {
> /* client trace verbose */
> config = <0x0001 0x0001 0x0001>;
> };
> };
>
> Both &soc and &sw nodes are defined in base dtb.
>
> When we run basic dt-schema checks on above as a dts file we get the
> following errors:
>
> /: fragment@0: 'anyOf' conditional failed, one must be fixed:
> 'reg' is a required property
> 'ranges' is a required property
>
> /: fragment@1: 'anyOf' conditional failed, one must be fixed:
> 'reg' is a required property
> 'ranges' is a required property
>
> /: 'compatible' is a required property
>
> /: 'model' is a required property
>
> /: '#address-cells' is a required property
>
> /: '#size-cells' is a required property
>
> I'm assuming dt-schema is looking for a root node and the required
> properties in the root node and not finding it in the overlay file.
Indeed. The required property errors would be easy to handle. We do
that already for disabled nodes as they may be incomplete.
> Is there a basic incompatibility between dt-schema and overlay support,
> or is this cockpit error?
A lot depends on how you are using overlays. If you are using them to
add random properties on existing nodes (which isn't something that
can easily work at runtime), that's not going to work for validating
the overlay on its own (nor the base DT, if the base DT is not valid
on its own). If the overlays are adding complete nodes or subtrees
such as for an expansion card, then I would expect the overlay can
mostly be validated with perhaps some tweaks. The former case only
makes sense to validate the DT with overlays applied. If you look at
the overlay build support in the kernel, you'll see all the overlays
are applied at build time.
Rob
