New 'make dtbs_check W=1' warnings
Arnd Bergmann
arnd at kernel.org
Mon Apr 12 14:14:14 BST 2021
On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:
> >
> > 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.
I checked out the bindings from linux-next, which seems to have covered
most of these. Sometimes it pays off to be lazy and merge them after
everyone else.
> 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.
Right, that would certainly help. Some maintainers send all binding
updates both to the driver maintainers and to the soc tree, along
with the other changes that only go into one tree. That is of course
also more work on your side, but it solves the problem entirely.
> > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports:
> > 'port at 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@mail.gmail.com/
Ok, thanks.
Arnd
More information about the linux-arm-kernel
mailing list