From: Guenter Roeck <linux@roeck-us.net> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Dan Carpenter <dan.carpenter@oracle.com>, Matthew Wilcox <willy@infradead.org>, Chris Packham <Chris.Packham@alliedtelesis.co.nz>, "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>, "brandonbonaby94@gmail.com" <brandonbonaby94@gmail.com>, "julia.lawall@lip6.fr" <julia.lawall@lip6.fr>, "yuehaibing@huawei.com" <yuehaibing@huawei.com>, "paulburton@kernel.org" <paulburton@kernel.org>, "aaro.koskinen@iki.fi" <aaro.koskinen@iki.fi>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "fw@strlen.de" <fw@strlen.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>, "bobdc9664@seznam.cz" <bobdc9664@seznam.cz>, "sandro@volery.com" <sandro@volery.com>, "ivalery111@gmail.com" <ivalery111@gmail.com>, "ynezz@true.cz" <ynezz@true.cz>, "davem@davemloft.net" <davem@davemloft.net>, "wambui.karugax@gmail.com" <wambui.karugax@gmail.com> Subject: Re: [PATCH 1/2] staging: octeon: delete driver Date: Wed, 5 Feb 2020 05:52:50 -0800 [thread overview] Message-ID: <dd09609d-d504-9a9e-453e-6b0ef66e6211@roeck-us.net> (raw) In-Reply-To: <CAMuHMdXKtJEvwRViRpy4nHbxv68P_rCFWbpikw=BMM5XnBvD2A@mail.gmail.com> On 2/5/20 1:03 AM, Geert Uytterhoeven wrote: > On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck <linux@roeck-us.net> 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. > m68k in -next builds fine for me, and did for a while. I have not seen a build failure there. There must be a context commit causing this failure, or what is (or was) in -next differs from what is in mainline. >> 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. > Yes, that is correct. But that doesn't mean that it would be a good idea to retire COMPILE_TEST. Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>, "brandonbonaby94@gmail.com" <brandonbonaby94@gmail.com>, "bobdc9664@seznam.cz" <bobdc9664@seznam.cz>, "fw@strlen.de" <fw@strlen.de>, "paulburton@kernel.org" <paulburton@kernel.org>, "aaro.koskinen@iki.fi" <aaro.koskinen@iki.fi>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "yuehaibing@huawei.com" <yuehaibing@huawei.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Matthew Wilcox <willy@infradead.org>, "ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>, "julia.lawall@lip6.fr" <julia.lawall@lip6.fr>, "sandro@volery.com" <sandro@volery.com>, Chris Packham <Chris.Packham@alliedtelesis.co.nz>, "ivalery111@gmail.com" <ivalery111@gmail.com>, "ynezz@true.cz" <ynezz@true.cz>, "davem@davemloft.net" <davem@davemloft.net>, Dan Carpenter <dan.carpenter@oracle.com>, "wambui.karugax@gmail.com" <wambui.karugax@gmail.com> Subject: Re: [PATCH 1/2] staging: octeon: delete driver Date: Wed, 5 Feb 2020 05:52:50 -0800 [thread overview] Message-ID: <dd09609d-d504-9a9e-453e-6b0ef66e6211@roeck-us.net> (raw) In-Reply-To: <CAMuHMdXKtJEvwRViRpy4nHbxv68P_rCFWbpikw=BMM5XnBvD2A@mail.gmail.com> On 2/5/20 1:03 AM, Geert Uytterhoeven wrote: > On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck <linux@roeck-us.net> 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. > m68k in -next builds fine for me, and did for a while. I have not seen a build failure there. There must be a context commit causing this failure, or what is (or was) in -next differs from what is in mainline. >> 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. > Yes, that is correct. But that doesn't mean that it would be a good idea to retire COMPILE_TEST. Guenter _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-02-05 13:52 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-10 9:15 [PATCH 1/2] staging: octeon: delete driver Greg Kroah-Hartman 2019-12-10 9:15 ` Greg Kroah-Hartman 2019-12-10 9:15 ` [PATCH 2/2] staging: octeon-usb: delete the octeon usb host controller driver Greg Kroah-Hartman 2019-12-10 9:15 ` Greg Kroah-Hartman 2019-12-10 19:31 ` Aaro Koskinen 2019-12-10 19:31 ` Aaro Koskinen 2019-12-10 20:19 ` Greg Kroah-Hartman 2019-12-10 20:19 ` Greg Kroah-Hartman 2019-12-10 21:27 ` Aaro Koskinen 2019-12-10 21:27 ` Aaro Koskinen 2019-12-11 7:42 ` Greg Kroah-Hartman 2019-12-11 7:42 ` Greg Kroah-Hartman 2020-02-04 4:06 ` Chris Packham 2020-02-04 4:06 ` Chris Packham 2020-02-04 7:15 ` gregkh 2020-02-04 7:15 ` gregkh 2020-02-04 7:21 ` Dan Carpenter 2020-02-04 7:21 ` Dan Carpenter 2019-12-10 10:42 ` [PATCH 1/2] staging: octeon: delete driver Guenter Roeck 2019-12-10 10:42 ` Guenter Roeck 2020-02-04 4:02 ` Chris Packham 2020-02-04 4:02 ` Chris Packham 2020-02-04 7:09 ` gregkh 2020-02-04 7:09 ` gregkh 2020-02-04 20:06 ` Chris Packham 2020-02-04 20:06 ` Chris Packham 2020-02-04 20:31 ` Matthew Wilcox 2020-02-04 20:31 ` Matthew Wilcox 2020-02-04 22:53 ` gregkh 2020-02-04 22:53 ` gregkh 2020-02-05 3:34 ` Dan Carpenter 2020-02-05 3:34 ` Dan Carpenter 2020-02-05 3:44 ` Matthew Wilcox 2020-02-05 3:44 ` Matthew Wilcox 2020-02-05 3:56 ` Guenter Roeck 2020-02-05 3:56 ` Guenter Roeck 2020-02-05 9:03 ` Geert Uytterhoeven 2020-02-05 9:03 ` Geert Uytterhoeven 2020-02-05 13:52 ` Guenter Roeck [this message] 2020-02-05 13:52 ` Guenter Roeck 2020-02-06 8:18 ` Geert Uytterhoeven 2020-02-06 8:18 ` Geert Uytterhoeven 2020-02-04 20:57 ` [SPAM] " Guenter Roeck 2019-12-10 11:40 ` Sandro Volery 2019-12-10 11:40 ` Sandro Volery 2019-12-10 12:01 ` Greg Kroah-Hartman 2019-12-10 12:01 ` Greg Kroah-Hartman 2019-12-10 12:54 ` Sandro Volery 2019-12-10 12:54 ` Sandro Volery 2019-12-10 19:46 ` Aaro Koskinen 2019-12-10 19:46 ` Aaro Koskinen 2019-12-10 20:15 ` Guenter Roeck 2019-12-10 20:15 ` Guenter Roeck 2019-12-10 21:48 ` Aaro Koskinen 2019-12-10 21:48 ` Aaro Koskinen 2019-12-10 22:48 ` Guenter Roeck 2019-12-10 22:48 ` Guenter Roeck 2019-12-11 7:22 ` Dan Carpenter 2019-12-11 7:22 ` Dan Carpenter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=dd09609d-d504-9a9e-453e-6b0ef66e6211@roeck-us.net \ --to=linux@roeck-us.net \ --cc=Chris.Packham@alliedtelesis.co.nz \ --cc=aaro.koskinen@iki.fi \ --cc=bobdc9664@seznam.cz \ --cc=brandonbonaby94@gmail.com \ --cc=dan.carpenter@oracle.com \ --cc=davem@davemloft.net \ --cc=ddaney@caviumnetworks.com \ --cc=devel@driverdev.osuosl.org \ --cc=fw@strlen.de \ --cc=geert@linux-m68k.org \ --cc=gregkh@linuxfoundation.org \ --cc=ivalery111@gmail.com \ --cc=julia.lawall@lip6.fr \ --cc=linux-kernel@vger.kernel.org \ --cc=paulburton@kernel.org \ --cc=sandro@volery.com \ --cc=wambui.karugax@gmail.com \ --cc=willy@infradead.org \ --cc=ynezz@true.cz \ --cc=yuehaibing@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.