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

[Philip Li]

On Fri, May 06, 2022 at 09:17:44AM +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 3:09 AM Philip Li <philip.li at 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 at intel.com> wrote:
> > > >> From: kernel test robot <lkp at 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 at intel.com>
> > > >> Signed-off-by: kernel test robot <lkp at 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.
> >
> > Thanks for the suggestion Dave, We will change current process to be more
> > conservative and to avoid false patch by adding human analysis.
> 
> For the returnvar.cocci false-positives, I wonder if it's possible to find them
> using another coccinelle helper that detects badly formed macros which
> access variables out of scope. I can't think of how this would be expressed,
> but maybe someone has an idea.
> 
> Something else went wrong in this particular patch,  and I can't explain
> how this happened: the subject line contains the name of the wrong platform,
> "dove" rather than "omap2". My guess is that this was human error copying
> the subject line from another patch, but if this came from a script, you
> may want to check how this gets generated.

Thanks Arnd, we will investigate this to fix our side issue. And thanks for
taking time to check the detail, as mentioned in other reply, we will not
send out patch unless it is carefully reviewed/acked by members of 0day.

> 
>        Arnd