On Wed, Apr 13, 2022 at 7:32 PM T.Michael Turney <quic_mturney@xxxxxxxxxxx> wrote: > > > >> > >> 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. > > > > Can you point me to example of handling required property errors for > disabled nodes? Is this in schema or meta-schema files or ?? dt-validate does the filtering. > >> 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. > > > > The base DT would be valid and pass dt-schema checks as well as dtc > syntax and semantic warnings. This DT would define a v1.0 SOC. > Possible overlays to apply would be if newer SOC version required > changes or if a platform introduced new nodes/properties. You could have issues if you have board specific, required properties. I guess the SOC DT can have defaults or the node disabled if that's required. > The overlays would be applied at runtime and most overlay files would be > similar to example I provided, where an existing node in base DT has a > property changed or added. I suppose we could provide a root node in > the overlay files to satisfy the dt-schema checks but were hoping to > avoid this as it adds to the runtime footprint of these files and > minimizing this footprint is one of the reasons we are embracing overlays. If footprint is your main concern I have to wonder if doing that automatically would be better than manually maintaining the split between overlays and base DTs. Imagine a tool that's passed N DTBs and it extracts everything common between the N DTBs into a base DTB and N overlays. Such a tool would not be hard to implement. > Are you indicating it is a "fool's errand" to try to do dt-schema checks > on an arbitrary overlay file that has no other context associated, other > than the few nodes/properties being added or changed? I guess if the > overlay file doesn't include a compatible property then dt-schema has > nothing to work with and if a compatible property is provided and the > overlay doesn't include all of the required properties, dt-schema is > going to flag these as error cases anyway? I think it's going to depend on what the overlays look like. You could do some validation as some schemas are always applied, but vendor specific properties for example would mostly not get checked without compatible to match on. Common properties could have at least type checks. Don't you want to check that all the combinations of base DT and overlays can be applied before you deploy them to a running system? If you do that, then you can run the schema checks too. > I am concerned about this: > > If you are using them to > > add random properties on existing nodes (which isn't something that > > can easily work at runtime), > This is exactly our basic use-case for overlays, we are planning on > using the APIs in fdt_overlay.c at runtime. Are you suggesting this > isn't a robust use of the overlay support? If 'at runtime' means before anything uses the DT (or parts that could be modified), then it is fine. It's allowing modifications at any point in time that's problematic (and why there's not a general purpose overlay applying interface exposed to userspace) If a driver already probed and a new property shows up, how do you handle that? Applying at runtime in early boot is fine. Rob
