Re: [PATCH 1/2] staging: octeon: delete driver

From: Guenter Roeck
Date: Wed Feb 05 2020 - 08:52:55 EST


On 2/5/20 1:03 AM, Geert Uytterhoeven wrote:
On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck <linux@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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