Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp58645ybv; Wed, 5 Feb 2020 01:05:32 -0800 (PST) X-Google-Smtp-Source: APXvYqxGoeqGogbzPQdGHRw5evY7szkTibXrdkYNNo9gDfxt/1o979fOr+lJ/BAu1gR2gfmfNYvb X-Received: by 2002:a05:6830:1498:: with SMTP id s24mr26909176otq.79.1580893532321; Wed, 05 Feb 2020 01:05:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580893532; cv=none; d=google.com; s=arc-20160816; b=Bow2TIRcmCILNFQdy2ik8Ji+0AhQ+VIME5zi7VyRCPDx5F71tx+F2PU+pcqV0sKGeV NjC+3nCL5+aEhvBWXR/Xp1GYdEXUVeztqDiknze2DjowX5cMClLH14C79CZozW7pYF7R c12McW7nv21w5mLFToiBnVha4Xik5AbBE67rt/F7SHtXdLPZycB7T1oIkEUtDLwY1t3J sh8NCjm8ehO8lcx1cHrEtWKFiIfuwRUybCO8vR6EttUGfGVk5eJvGQypMSn2KiK0YrW/ wCaeIeRXb6renCINyIHqdD7rGLO45VIC53poYXRKsjTrG+pWQUFiNC2CQL3B51BUXRFb 7phw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=ly8+3gmEudftYUIeu3tPerclxKuHSskVOT90fOPXZhE=; b=Fsz8fZpLPpFeJEVfryrq+z4rMNXpxcXt6AG+QwkEeWDK71rsQI/upiKvRuo8jUkoPE 5pXTQYch0rsu1WMatfOEwS1xsnchKORfy9JFUFBGOG7+ac2FK3QEFWVqnD3gCSiHc36Y cDhoeFn7RSGJJsiR+/9sAB4p2BitoWjXD7Kqz27oT/G4NyRnIaLi8yAqBq0Zv6hgvUXA HV0AqQqO/Wj32xHDEQGanaZrgLd1GX7TDTQ+vRjs4Hx+OQLUKXudPajtY/mSsGCVuwcC FiFPM05/Gzto1e8zw3+ppiqR8KP1nte+spjZoYbT43Hdix8VKuQLRIHL4Wy4Frzde+0S yYwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si11481252oiz.237.2020.02.05.01.05.19; Wed, 05 Feb 2020 01:05:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728122AbgBEJDb (ORCPT + 99 others); Wed, 5 Feb 2020 04:03:31 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:44763 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728035AbgBEJDb (ORCPT ); Wed, 5 Feb 2020 04:03:31 -0500 Received: by mail-ot1-f66.google.com with SMTP id h9so1217376otj.11 for ; Wed, 05 Feb 2020 01:03:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ly8+3gmEudftYUIeu3tPerclxKuHSskVOT90fOPXZhE=; b=OKVItxpeqmP98QfrRFgIARI97k/FesAMPoFEs+csAYh2WoKBfsZmp0kyKjgZd+QNBT nr0+feMKU7Xvrd3Hw8YrbTcGMstPKDI2yXsznDc3cODw5DTaAW2U7PhSSie0dtfibbr7 pe9b/wd4W0ObtLDGFT5ANPUR/4BJRJn8S//9jCWX6TSjqO9PXE+svk4trBKsreVlqpY8 zuY+2J38cQNjc+BHjv9LaENX5LEwurJ5WWveILB05vj/T/xeuCJaC5hAEDC4ku7YC++f uTwFmMMkav5BUjZhjJ1wU7yilDcEXnCjbRh7IoPxZI6U+snKN7n/MLnM61I0s+N4t7Ch Fpnw== X-Gm-Message-State: APjAAAWeEv+b7rDLoCzAfl/+iUUTfl3aEmztR6LUcz7dd1XxLpIcBw/U e2dTKJRNdSzbAhx+bC4klnOrKgNsbENUpyxBf8s= X-Received: by 2002:a9d:8f1:: with SMTP id 104mr23691249otf.107.1580893410632; Wed, 05 Feb 2020 01:03:30 -0800 (PST) MIME-Version: 1.0 References: <20191210091509.3546251-1-gregkh@linuxfoundation.org> <6f934497-0635-7aa0-e7d5-ed2c4cc48d2d@roeck-us.net> <20200204070927.GA966981@kroah.com> <1a90dc4c62c482ed6a44de70962996b533d6f627.camel@alliedtelesis.co.nz> <20200204203116.GN8731@bombadil.infradead.org> <20200205033416.GT1778@kadam> In-Reply-To: From: Geert Uytterhoeven Date: Wed, 5 Feb 2020 10:03:18 +0100 Message-ID: Subject: Re: [PATCH 1/2] staging: octeon: delete driver To: Guenter Roeck Cc: Dan Carpenter , Matthew Wilcox , Chris Packham , "devel@driverdev.osuosl.org" , "brandonbonaby94@gmail.com" , "julia.lawall@lip6.fr" , "yuehaibing@huawei.com" , "paulburton@kernel.org" , "aaro.koskinen@iki.fi" , "gregkh@linuxfoundation.org" , "fw@strlen.de" , "linux-kernel@vger.kernel.org" , "ddaney@caviumnetworks.com" , "bobdc9664@seznam.cz" , "sandro@volery.com" , "ivalery111@gmail.com" , "ynezz@true.cz" , "davem@davemloft.net" , "wambui.karugax@gmail.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck wrote: > On 2/4/20 7:34 PM, Dan Carpenter wrote: > > On Tue, Feb 04, 2020 at 12:31:16PM -0800, Matthew Wilcox wrote: > >> On Tue, Feb 04, 2020 at 08:06:14PM +0000, Chris Packham wrote: > >>> On Tue, 2020-02-04 at 07:09 +0000, gregkh@linuxfoundation.org wrote: > >>>> On Tue, Feb 04, 2020 at 04:02:15AM +0000, Chris Packham wrote: > >>> On Tue, 2020-02-04 at 10:21 +0300, Dan Carpenter wrote: > >>>> My advice is to delete all the COMPILE_TEST code. That stuff was a > >>>> constant source of confusion and headaches. > >>> > >>> I was also going to suggest this. Since the COMPILE_TEST has been a > >>> source of trouble I was going to propose dropping the || COMPILE_TEST > >>> from the Kconfig for the octeon drivers. > >> > >> Not having it also causes problems. I didn't originally add it for > >> shits and giggles. > > > > I wonder if the kbuild bot does enough cross compile build testing these > > days to detect compile problems. It might have improved to the point > > where COMPILE_TEST isn't required. It depends... > Not really. Looking at the build failures in the mainline kernel right now: > > Failed builds: > alpha:allmodconfig > arm:allmodconfig > i386:allyesconfig > i386:allmodconfig > m68k:allmodconfig > microblaze:mmu_defconfig > mips:allmodconfig > parisc:allmodconfig > powerpc:allmodconfig > s390:allmodconfig > sparc64:allmodconfig I did receive a report from noreply@ellerman.id.au for the m68k build failure. But that was sent to me only, not to the offender, and I do my own builds anyway. More interesting, that report happened after the offending commit landed upstream, while it had been in next for 4 weeks. > Many of those don't even _have_ specific configurations causing the build failures. Exactly. These are the "easy" ones, as the all*config builds enable as much infrastructure as possible. It's much harder if some common dependency is not fulfilled in some specific config. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds