Re: [PATCH] ARM: dove: fix returnvar.cocci warnings

From: Ard Biesheuvel <ardb@kernel.org>
To: Philip Li <philip.li@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Arnd Bergmann <arnd@arndb.de>, kernel test robot <lkp@intel.com>,
	kbuild-all@lists.01.org,
	Linux Memory Management List <linux-mm@kvack.org>,
	Tony Lindgren <tony@atomide.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-omap <linux-omap@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: dove: fix returnvar.cocci warnings
Date: Fri, 6 May 2022 09:24:26 +0200	[thread overview]
Message-ID: <CAMj1kXEznFy3GeJJwwyHCHTQoYKmE92BDHisqNM84FoyFFw7rg@mail.gmail.com> (raw)
In-Reply-To: <YnR1OTpYADQy6Xa8@rli9-dbox>

On Fri, 6 May 2022 at 03:12, Philip Li <philip.li@intel.com> wrote:
>
> On Thu, May 05, 2022 at 09:31:37AM -0700, Dave Hansen wrote:
> > On 5/3/22 00:21, Arnd Bergmann wrote:
> > > On Tue, May 3, 2022 at 4:45 AM kernel test robot <lkp@intel.com> wrote:
> > >> From: kernel test robot <lkp@intel.com>
> > >>
> > >> arch/arm/mach-omap2/dma.c:82:10-16: Unneeded variable: "errata". Return "0" on line 161
> > >>
> > >>  Remove unneeded variable used to store return value.
> > >>
> > >> Generated by: scripts/coccinelle/misc/returnvar.cocci
> > >>
> > >> Reported-by: kernel test robot <lkp@intel.com>
> > >> Signed-off-by: kernel test robot <lkp@intel.com>
> > > I checked the patch, and unfortunately it is wrong, the current code
> > > needs to stay.
> > > The problem is the SET_DMA_ERRATA() macro that accesses the
> > > local 'errata' variable.
> >
> > 0day folks, do we have humans looking over these before they're going
> > out to the list?  If not, can we add some?  If so, can the humans get a
> > little more discerning? ;)
>
> Sorry all for the bad patch. So far, we pick up several cocci warnings that
> we have confidence based on early result analysis and feedback, for these
> warnings, 0day sends out patch automatically.
>

Could you please add a special header or something to such emails so I
can filter them out? I am strongly opposed to such automatic spambot
patch generation, as it wastes valuable reviewer bandwidth to save the
bot operator some time, but it think it should be the other way
around.

We expect contributors to carefully prepare their patch submissions
before sending them to the list, and automatically generated patches
simply don't mesh with that. The fact that you use a bot does not mean
you can ignore these rules.