From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A712CC433FE for ; Fri, 6 May 2022 07:24:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1389506AbiEFH2Z (ORCPT ); Fri, 6 May 2022 03:28:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352462AbiEFH2X (ORCPT ); Fri, 6 May 2022 03:28:23 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 407CB66FB6; Fri, 6 May 2022 00:24:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AF851B832C1; Fri, 6 May 2022 07:24:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62E86C385B1; Fri, 6 May 2022 07:24:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651821878; bh=StWfG862y0u2kQU0M4ZLAPlW/rb52wK1Pm4BbpZO+tE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FPuuz+QYQLJsxFXdf+bWPOaMtjdb7DlpsLJjGzqAmr4sijr00SCJZOQ958vkODYIG ecJxJo6UccWgEhFTEIDXXBAmSYRGQUfX95ch1ICCP4V6Q3rxF+eh8YagyL1VUS8FT+ VpMDAyAa2jPwihzq6+p24zAUuCHqeG/YXwd5xY7nKWdnnUtiM8cAfX2CFJfLkisUxl 5tK4bZY7vNa8Kchbwqf/jDMGqmn1ejSJ1lAGm01EbWRMmrPWIl2NmNMH0rn+LcKocY g0uNR5dFzbLr52Vf86Gn9dFHEsETNLuJYYUJ+3fkRi9OgZbkcDtSkR3yrCQGBrIHG4 Gj3/WkbwlaZQA== Received: by mail-ot1-f41.google.com with SMTP id y14-20020a9d460e000000b00605ee347da1so4419805ote.8; Fri, 06 May 2022 00:24:38 -0700 (PDT) X-Gm-Message-State: AOAM533g5E/XK4o1jpTV5GTW31tuJ3gjLnWa+1pMpWClXXcJw2PAH6L3 j0OatiyBW7hjHK+xXqwOrwnu9Mf55I5qZCmBZ6M= X-Google-Smtp-Source: ABdhPJwuFrRQYlf5wXREq8n4UegLU54tdjjmaysEtlWvqoHMsjkC01J7C/wN4KWbcr8LtHuSJmnoRa9yPqiRTKOk/YM= X-Received: by 2002:a05:6830:9c2:b0:606:1e0a:cc8d with SMTP id y2-20020a05683009c200b006061e0acc8dmr598659ott.265.1651821877389; Fri, 06 May 2022 00:24:37 -0700 (PDT) MIME-Version: 1.0 References: <202205031017.4TwMan3l-lkp@intel.com> <8704209d-d487-a297-b05a-5db99f5f808c@intel.com> In-Reply-To: From: Ard Biesheuvel Date: Fri, 6 May 2022 09:24:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] ARM: dove: fix returnvar.cocci warnings To: Philip Li Cc: Dave Hansen , Arnd Bergmann , kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , Tony Lindgren , Russell King , linux-omap , Linux ARM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 6 May 2022 at 03:12, Philip Li 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 wrote: > > >> From: kernel test robot > > >> > > >> 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 > > >> Signed-off-by: kernel test robot > > > 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.