Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

From: Lee Jones
Date: Fri Feb 12 2021 - 16:27:32 EST


On Fri, 12 Feb 2021, Lee Jones wrote:

> On Fri, 12 Feb 2021, Stephen Boyd wrote:
>
> > Quoting Lee Jones (2021-02-12 01:20:16)
> > > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > >
> > > > Quoting Lee Jones (2021-02-11 13:10:54)
> > > > > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > > > >
> > > > > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > > > > This set is part of a larger effort attempting to clean-up W=1
> > > > > > > kernel builds, which are currently overwhelmingly riddled with
> > > > > > > niggly little warnings.
> > > > > > >
> > > > > > > This is the last set. Clock is clean after this.
> > > > > >
> > > > > > Is it possible to slam in some patch that makes W=1 the default for the
> > > > > > clk directory? I'm trying to avoid seeing this patch series again.
> > > > >
> > > > > One of my main goals of this project is that everyone (contributors,
> > > > > maintainers auto-builder robots etc) will be enabling W=1 builds
> > > > > *locally*.
> > > > >
> > > > > This isn't something you'll want to do at a global (i.e. in Mainline)
> > > > > level. That's kinda the point of W=1.
> > > > >
> > > >
> > > > Agreed, but is it possible to pass W=1 in the drivers/clk/Makefile?
> > >
> > > That would circumvent the point of W=1. Level-1 warnings are deemed,
> > > and I'm paraphrasing/making this up "not worth rejecting pull-requests
> > > over". In contrast, if Linus catches any W=0 warnings at pull-time,
> > > he will reject the pull-request as 'untested'.
> > >
> > > W=1 is defiantly something you'll want to enable locally though, and
> > > subsequently push back on contributors submitting code adding new
> > > ones.
> > >
> >
> > Why should I install a land mine for others to trip over? Won't that
> > just take them more time because they won't know to compile with W=1 and
> > then will have to go for another round of review while I push back on
> > them submitting new warnings?
>
> The alternative is to not worry about it and review the slow drip of
> fixes that will occur as a result. The issues I just fixed were built
> up over years. They won't get to that level again.
>
> In my mind contributors should be compiling their submissions with W=1
> enabled by default. I'm fairly sure the auto-builders do this now.
>
> Once W=1 warnings are down to an acceptable level in the kernel as a
> whole, we can provide some guidance in SubmittingPatches (or similar)
> on how to enable them (hint: you add "W=1" on the compile line).
>
> Enabling W=1 in the default build will only serve to annoy Linus IMHO.
> If he wants them to be enabled by default, they wouldn't be W=1 in the
> first place, they'd be W=0 which *is* the default build.

Just to add real quick - my advice is to enable them for yourself and
send back any issues along with your normal review. A W=1 issue is no
different to a semantic or coding style one.

--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog