Hi Arnd, On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. Thanks for running these checks! > See below for the other platforms, and the new warnings that I found. > If these are > valid, please send a fixup before the merge window, and let me know if > you have ideas > for how we should handle these in the future. > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > know if you disagree), but in the long run we may want to gradually enforce > a rule about not merging changes that introduce any new warnings, in order to > have a chance of cleaning up the existing ones. This may not be as simple as it sounds, as DT binding updates typically follow a different path than DTS(i) updates. DT bindings updates may be picked up by a subsystem maintainer, by Rob, or by the platform maintainer. For trivial updates (e.g. adding a compatible value, and sometimes extending a limit), a DTS(i) update may be accepted by the platform maintainer before the corresponding DT binding update. The latter may even be merged one or more kernel revisions later, especially when involving subsystems that are not traditionally rooted into platforms using DT. Of course we could mention any expected warning regressions in our pull requests for soc. > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > 'port@0' is a required property [...] I've replied to these as a response to your PR reply, see https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@xxxxxxxxxxxxxx/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
