Messages in this thread |  | | Subject | Re: [PATCH 1/2] staging: octeon: delete driver | From | Guenter Roeck <> | Date | Wed, 5 Feb 2020 05:52:50 -0800 |
| |
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
|  |