]> err.no Git - linux-2.6/commit
V4L/DVB (7974): fix MEDIA_TUNER && FW_LOADER build error
authorIngo Molnar <mingo@elte.hu>
Tue, 20 May 2008 22:34:09 +0000 (19:34 -0300)
committerMauro Carvalho Chehab <mchehab@infradead.org>
Thu, 5 Jun 2008 09:35:53 +0000 (06:35 -0300)
commit6637dea60ec93916ea0623a0e9bcc2b1769cbc11
tree427a5f49390e5237d2635c06ccb125f57ad6db1a
parent18dcd55a8bf8aa7009c647725b5234c9589c6985
V4L/DVB (7974): fix MEDIA_TUNER && FW_LOADER build error

-tip testing found the following build failure:

  LD      .tmp_vmlinux1
  drivers/built-in.o: In function `generic_set_freq':
  tuner-xc2028.c:(.text+0xbd896): undefined reference to `request_firmware'
  tuner-xc2028.c:(.text+0xbdd7a): undefined reference to `release_firmware'
  drivers/built-in.o: In function `xc_load_fw_and_init_tuner':
  xc5000.c:(.text+0xc68e6): undefined reference to `request_firmware'
  xc5000.c:(.text+0xc6abe): undefined reference to `release_firmware'

with this config:

  http://redhat.com/~mingo/misc/config-Tue_May_20_18_11_34_CEST_2008.bad

the reason is another kconfig tool bug that has to be worked around in
the driver's Kconfig file: if FW_LOADER is selected in a second
dependency, that is not properly propagated up the dependencies.

in this case, FW_LOADER is selected from MEDIA_TUNER_XC2028:

  config MEDIA_TUNER_XC2028
        tristate "XCeive xc2028/xc3028 tuners"
        depends on VIDEO_MEDIA && I2C
        depends on HOTPLUG
        select FW_LOADER

which got selected by MEDIA_TUNER:

  config MEDIA_TUNER
        tristate
        default VIDEO_MEDIA && I2C
        depends on VIDEO_MEDIA && I2C
        select FW_LOADER if !MEDIA_TUNER_CUSTOMIZE && HOTPLUG

but the kconfig tool did not pick up this second-order dependency and
allowed CONFIG_FW_LOADER=m to be selected - in which case the build
fails.

the workaround i found was to move the select of FW_LOADER one level up,
so that the buggy kconfig tool can notice it and can act appropriately.
This problem can probably be worked around in other ways as well, i went
for the minimal fix.

Obviously, the kconfig tool should be fixed, it is not reasonable to
expect driver authors to do manual dependency resolution (that kconfig
itself already does) and uglify the Kconfig files. The kconfig tool did
nothing to warn about this situation and did not prevent this faulty
.config from being constructed.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
drivers/media/common/tuners/Kconfig