On Tue, Jan 31, 2017 at 08:24:48AM +0000, Ian Campbell wrote: > On Tue, 2017-01-31 at 10:49 +1100, David Gibson wrote: > > On Mon, Jan 30, 2017 at 09:13:05AM +0000, Ian Campbell wrote: > > > Hello, > > > > > > I wasn't sure how/where to make a wishlist bug report, so I hope this > > > will suffice, am happy to be pointed in a different direction though. > > > > > > I recently[0] stumbled over around 1,000 of these: > > > Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name > > > Warning (unit_address_vs_reg): Node /soc/main-oscillator has a reg or ranges property, but no unit name > > > Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name > > > Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name > > > Warning (unit_address_vs_reg): Node /soc/main-oscillator has a reg or ranges property, but no unit name > > > Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name > > > Warning (unit_address_vs_reg): Node /soc/main-oscillator has a reg or ranges property, but no unit name > > > > > > When building the split device tree repo[1] from the Linux source > > > (essential it's a build of every single dts in the kernel source). > > > > > > The cause of the warning is an issue which needs to be fixed but I > > > thought I would mention that it would be very useful (I expect) if dtc > > > would include the offending file in warnings (like e.g. gcc would), not > > > just because of the number of *.dtb being built here but also due to > > > #include and /include/ of .dtsi files. > > > > Right, having the filenames - and line numbers - there would certainly > > be helpful. Unfortunately, it's not at all trivial to implement. As > > someone said in a different thread, these checks take place (and have > > to) after the tree is completely parsed and we no longer have source > > locations readily to hand. > > Would it be easier (or possible) to print the name of the eventually- > to-be-output binary? At the moment the user is left guessing which one > of 1,200 *.dtb files they just built produced each of the similar > number of warnings. If the message was instead: > > Warning (unit_address_vs_reg): arch/arm/boot/dts/foo.dtb: Node /soc has a ... > > Then that would at least be something to go on. > > In fact, given the checks are on the final tree, naming the output file > in the messages seems fairly logical (you could even imagine doing > these checks in a separate linter tool after the fact, given the *.dtb > as input, I suppose) Hm, possible, though a bit messy to do within dtc. The output file is currently passed into that section of the code, but I guess we could add it. However, it seems this would more easily be fixed from the Makefile side: if you echo a (suitably abbreviated) dtc command line, then it should become obvious which dtb the errors are associated with. > > It might be possible to attach (optional) srcpos * markers to each > > node and property in the live tree. However, that runs into other > > complications: when using dts includes nodes can be merges of > > information from several different dtsi files. So, a node can be > > composed of information from several non-contiguous chunks of source > > from different files. It's not clear what should be printed in that > > case. > > Yeah, tricky! > > Hopefully the above suggesting will suffice for 99% of cases. Actually, this might be made more feasible by some of the overlay stuff in the works. We're looking at doing the overlay merges in a separate pass after parsing is complete. There are some interesting edge cases about whether checks get run before or after that merge, but I'm hoping most of the checks can run before. For those that do, we should have a well defined chunk of source from which each node and property comes. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
