Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

From: David Woodhouse
Date: Mon Feb 05 2007 - 08:35:29 EST


On Mon, 2007-02-05 at 09:45 +0100, Ingo Molnar wrote:
> LD vmlinux
> drivers/built-in.o: In function `cafe_nand_remove':
> cafe.c:(.text+0x19277a): undefined reference to `nand_release'
> drivers/built-in.o: In function `cafe_nand_cmdfunc':
> cafe.c:(.text+0x193036): undefined reference to `nand_wait_ready'
> drivers/built-in.o: In function `cafe_nand_probe':
> cafe.c:(.text+0x19359e): undefined reference to `nand_scan_ident'
> cafe.c:(.text+0x193658): undefined reference to `nand_scan_tail'
> distcc[1703] ERROR: compile (null) on localhost failed
> make: *** [vmlinux] Error 1

> so here's the fix for the 3 affected MTD drivers: DOC2000, DOC2001 and
> DOC2001PLUS.

Er, what?

For a start, the affected driver is the new CAFÃ NAND controller, not
the old versions of the DiskOnChip drivers which don't even use the
generic NAND code anyway.

Secondly, please don't _ever_ use 'select'. If ESR's Aunt Tillie
_really_ needs to configure a new kernel for her $100 laptop, but she
lacks the wit to realise that she might need to ask for NAND flash
support if she wants to be able to enable the NAND flash controller,
then I really couldn't care less.

We now have a fairly arbitrary mix of 'select' and proper dependencies
throughout the kernel, and it's getting harder and harder to configure a
minimal kernel by turning off subsystems we don't want, because
something 'helpfully' turns then back on again.

We could do with some coherent guidelines on _when_ to use 'select' and
when to use normal dependencies. Personally, I'm quite happy to tell
Aunt Tillie to go screw herself and for that guidance to be to _never_
use 'select'.

The correct fix is at
http://git.infradead.org/?p=mtd-2.6.git;a=commitdiff;h=aa8f1278553c554f1fb3fd6fb0987dd547c7d7cf;hp=4285431fb658263e98942ce2320b0b26eddcc06d

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/