On Wed, Jun 26, 2019 at 9:16 AM Paul Walmsley <paul.walmsley@xxxxxxxxxx> wrote: > > On Tue, 25 Jun 2019, Rob Herring wrote: > > > Minimally, for anyone submitting and applying schema patches, > > 'dt_binding_check' should pass and not have warnings. Just like > > compiling C code. I'd like to make it part of the default target, but > > things are a bit immature still and once we have all 3500 bindings > > converted, it will be too slow. > > Maybe it would be better if dt_binding_check respected the ARCH > environment variable in the kernel tree? That would speed things up, and > most kernel developers are probably only concerned with DT files in their > particular architecture. Then the existing 'dt_binding_check' > functionality that ignores ARCH could be renamed to something like > 'dt_binding_check_all'. The vast majority of bindings have nothing to do with the $ARCH. You could do things like artificially associate the SiFive UART with RiscV, but then when things happen like Freescale PPC networking chips moving to Arm or just the mixture between arm and arm64 that all breaks. We could add support for doing 'make Documentation/devicetree/bindings/riscv/' like you can for any other kernel directory if you only want to build 1 directory. We'd have to start explicitly listing every schema file in makefies though. > > Then there is 'dtbs_check' for dts files (in riscv specifically for > > you). > > Looks like this one ignores ARCH also. Any objections to someone changing > that? That's not right. Only the dtbs for the $ARCH are built and checked. All the schema are used though. Besides what I said above, it needs to be all schema so that 2 bindings can't define the same thing in different ways. For example, we have to make sure there's only one 'foo,bar' binding. Which dts directory is the *only* dependency on $ARCH now. It used to depend on the $ARCH compiler, but I got tired of searching for cross compilers just to build dts files. So I fixed that and now we use the host compiler (preprocessor). And there's no more arch specific make rules either because every arch did them slightly differently. > > 'dtbs_check' will probably have warnings already, but you should be > > aware of what each schema adds to that. That can be tested by setting > > 'DT_SCHEMA_FILES' to a single schema file. While the schema checks of > > examples are new, testing your dts files against the schema would have > > also caught this problem as examples tend to be copied from dts files. > > Then for new warnings either we have to adjust the schema to fix the > > warnings or fix the dts files. At this point, we're adding warnings and > > are nowhere close to be warning free. Ideally, if you add new dts files, > > they should pass schema checks. > > OK thanks. > > > BTW, much of this applies to just building dtbs with W=1 or W=12 which > > turns on a bunch of dtc checks. Hopefully, riscv can be warning free > > from the start (before you have a 1000 boards). > > The upstream RISC-V DTBs don't generate any warnings for "make dtbs W=2", > so I think we're in pretty good shape there. Note that 'W=2' doesn't include what 'W=1' turns on. You have to do 'W=12' for everything and the more important things are in 'W=1'. Not the most obvious interface IMO. > > For this case specifically, I'll look at how to restructure the cpu > > schemas. You need to fix the dtc warnings. > > I wasn't aware of 'dt_binding_check' and 'dtbs_check'. Thanks for the > pointer. I'll look at the YAML-derived dtc warnings. > > Sounds like 'make dt_binding_check' and 'make dtbs_check' need to be added > to Documentation/process/submitting-patches.rst, if the expectation is > that everyone should run them. See Documentation/devicetree/writing-schema.md The DT specifics for submitting patches are in: Documentation/devicetree/bindings/submitting-patches.txt Still, we probably need to add something about schema there. Then there's only 1 entry point for people to not read. Rob
