On Thu, Apr 7, 2022 at 1:45 PM T.Michael Turney <quic_mturney@xxxxxxxxxxx> wrote: > > Folks, > I posted some queries to this list a couple of years back when we were > first getting started. As I discovered our basic model differs from the > kernel use-case in one very important area: we want our builds to fail > when anything is out of whack. > > For example, DTC only throws an error on syntax and we want all of the > semantic warnings to cause an error and halt the build. We addressed > this by creating a wrapper script that handles CPP + DTC invocation and > catches all warnings/errors and exits with error-code on any warning or > error. Why work-around what you want? Contribute to dtc and add the option. > We are now starting to use dt-schema and experiencing deja-vu. We want > all warnings/errors to break things. We have again created some wrapper > scripts and are well down the path, but a couple of questions remain. The current state of affairs is if we errored out on everything, no one would be able to run the tools. It's all I can do to keep the errors we do have from getting merged. The bindings are generally warning free, but dts files have 1000s. > 1. There is tight coupling of compatible property with .yaml file for > dt-schema. Is there a way to force a rule that if a compatible property > is found in the tree there must be a corresponding yaml file as well? I wish. There's a couple of things we could do. The problem is how do you extract compatible strings from the C code? For drivers that are modules, the compatible strings do end up in the module meta-data for autoloading. That could be extracted and checked. That doesn't get the non-module cases. The other idea I have is to extract properties and type information from schema (that's already done) and put that into C structures to use to validate calls reading properties. That of course would need to be a debug feature. Something similar with checking compatible strings could be possible too. We already extract all compatibles in schemas into a generated schema for checking undocumented compatibles in dts files. If for what you care about has a dts file(s), then checking the kernel side would be redundant. > 2. Since a lot of our devicetree nodes have a 1-1 mapping to a C struct, > is there a way to enforce property ordering with dt-schema and yaml > files today? You should not depend on property or node ordering. That is NOT part of the ABI. Rob
