[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1299778653.15854.370.camel@gandalf.stny.rr.com>
Date: Thu, 10 Mar 2011 12:37:33 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@...hat.com>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
Michal Marek <mmarek@...e.cz>
Subject: Sucky dependencies found in video saa7134 rc
Running randconfigs with ktest seems to find this crap all over. It's
not just saa7134, it happens else where too, but this is the one that
I'm currently looking at.
I'm also not blaming the saa7134 driver, but I think we need to find a
way to fix Kconfig to handle this. Maybe it is in the works. I don't
know.
Here's the issue:
1) in the Makefile in drivers/media/video/saa7134/ we have:
aa7134-y := saa7134-cards.o saa7134-core.o saa7134-i2c.o
saa7134-y += saa7134-ts.o saa7134-tvaudio.o saa7134-vbi.o
saa7134-y += saa7134-video.o
saa7134-$(CONFIG_VIDEO_SAA7134_RC) += saa7134-input.o
2) in the Kconfig of that directory:
config VIDEO_SAA7134_RC
bool "Philips SAA7134 Remote Controller support"
depends on RC_CORE
depends on VIDEO_SAA7134
default y
3) in the Makefile of drivers/media/rc
obj-$(CONFIG_RC_CORE) += rc-core.o
4) in the Kconfig of that directory:
menuconfig RC_CORE
tristate "Remote Controller adapters"
depends on INPUT
default INPUT
And finally in the .config produced by randconfig:
CONFIG_RC_CORE=m
CONFIG_VIDEO_SAA7134=y
CONFIG_VIDEO_SAA7134_RC=y
Thus, RC_CORE is a module and the SAA7134 input file is built in, which
gives me the following error:
drivers/built-in.o: In function `saa7134_input_init1':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:737: undefined reference to `rc_allocate_device'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:780: undefined reference to `rc_register_device'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:787: undefined reference to `rc_free_device'
drivers/built-in.o: In function `saa7134_input_fini':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:799: undefined reference to `rc_unregister_device'
drivers/built-in.o: In function `ir_raw_decode_timer_end':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:400: undefined reference to `ir_raw_event_handle'
drivers/built-in.o: In function `build_key':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:93: undefined reference to `rc_keydown_notimeout'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:101: undefined reference to `rc_keydown_notimeout'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:102: undefined reference to `rc_keyup'
drivers/built-in.o: In function `saa7134_raw_decode_irq':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:920: undefined reference to `ir_raw_event_store_edge'
make[1]: *** [.tmp_vmlinux1] Error 1
I know this is just a randconfig and I doubt that people will actually
run into this problem, but randconfig should always produce a kernel
that can compile, and preferably boot ;)
I think the issue here is that we should never allowed that SAA7134_RC
be set to 'y' when RC_CORE is 'm'. I need to look at the kconfig code
and see if there's a way to prevent that 'y' if its dependencies have
'm'.
Hmm, but that may not work either :( This may be a Makefile issue, as
that 'y' is not really a builtin to the kernel but a builtin to a module
that may or may not be built into the kernel. Which makes this
dependency agnostic to the Kconfigs. God what a horrible tangled web we
weave!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists