[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080513124630.111c465b@gaivota>
Date: Tue, 13 May 2008 12:46:30 -0300
From: Mauro Carvalho Chehab <mchehab@...radead.org>
To: "Michael Krufky" <mkrufky@...uxtv.org>
Cc: "Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
"Guennadi Liakhovetski" <g.liakhovetski@...gutronix.de>,
"Mike Isely" <isely@...ox.com>
Subject: Re: [patch] video: build fix for drivers/media/video/pvrusb2/
On Tue, 13 May 2008 00:03:02 -0400
"Michael Krufky" <mkrufky@...uxtv.org> wrote:
> On Mon, May 12, 2008 at 10:54 PM, Mauro Carvalho Chehab
> <mchehab@...radead.org> wrote:
> >
> > On Sun, 11 May 2008 08:34:06 -0400
> > "Michael Krufky" <mkrufky@...uxtv.org> wrote:
> >
> > > On Sun, May 11, 2008 at 3:21 AM, Ingo Molnar <mingo@...e.hu> wrote:
> > > >
> > > > x86.git testing found the following build failure:
> > > >
> > > > drivers/built-in.o: In function `pvr2_dvb_feed_thread':
> > > > pvrusb2-dvb.c:(.text+0x127e78): undefined reference to `dvb_dmx_swfilter'
> > > > drivers/built-in.o: In function `pvr2_dvb_adapter_exit':
> > > > pvrusb2-dvb.c:(.text+0x128357): undefined reference to `dvb_net_release'
> > > > pvrusb2-dvb.c:(.text+0x12836f): undefined reference to `dvb_dmxdev_release'
> > > > [...]
> > > >
> > > > with this config:
> > > >
> > > > http://redhat.com/~mingo/misc/config-Sun_May_11_07_06_35_CEST_2008.bad
> > > >
> > > > the reason for the missing symbols is this combination:
> > > >
> > > > CONFIG_VIDEO_PVRUSB2=y
> > > > CONFIG_DVB_CORE=m
> > > >
> > > > i.e. pvrusb2 is built-in, dvb-core is modular.
> > > >
> > > > This patch solves the problem by adding a dependency on DVB_CORE - this
> > > > is used by other drivers such as au0828 as well. This way the pvrusb2
> > > > driver can still be built, but if dvb-core is a module then it will
> > > > correctly be a module as well and cannot be built-in.
> > > >
> > > > Signed-off-by: Ingo Molnar <mingo@...e.hu>
> > > > ---
> > > > drivers/media/video/pvrusb2/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Index: linux/drivers/media/video/pvrusb2/Kconfig
> > > > ===================================================================
> > > > --- linux.orig/drivers/media/video/pvrusb2/Kconfig
> > > > +++ linux/drivers/media/video/pvrusb2/Kconfig
> > > > @@ -1,6 +1,6 @@
> > > > config VIDEO_PVRUSB2
> > > > tristate "Hauppauge WinTV-PVR USB2 support"
> > > > - depends on VIDEO_V4L2 && I2C
> > > > + depends on VIDEO_V4L2 && I2C && DVB_CORE
> > > > select FW_LOADER
> > > > select MEDIA_TUNER
> > > > select VIDEO_TVEEPROM
> > > >
> > >
> > > Ingo,
> > >
> > > VIDEO_PVRUSB2 should not depend on DVB_CORE unless VIDEO_PVRUSB2_DVB
> > > is selected, which already depends on DVB_CORE.
> > >
> > > For example, if a user has VIDEO_PVRUSB2_DVB not selected, then your
> > > patch would generate a false dependency on DVB_CORE.
> >
> > Maybe we can make pvrusb2 dependent of VIDEO_MEDIA. This is a DVB_CORE ||
> > VIDEO_DEV. So, pvrusb should be 'm' in this case.
>
> That sounds like it would be OK, although something like this would
> probably be better:
>
> config VIDEO_PVRUSB2
> tristate "Hauppauge WinTV-PVR USB2 support"
> - depends on VIDEO_V4L2 && I2C
> + depends on VIDEO_V4L2 && I2C && (DVB_CORE if VIDEO_PVRUSB2_DVB)
> select FW_LOADER
> select MEDIA_TUNER
> select VIDEO_TVEEPROM
This doesn't look to be a good idea, since VIDEO_PVRUSB2_DVB depends on
VIDEO_PVRUSB2. So, you'll create a circular dependency. The syntax I've
proposed seems cleaner. Of course, it needs to be tested. IMO, all hybrid
devices should be dependent of VIDEO_MEDIA. This will help to avoid this kind
of issue.
> I don't know if that syntax works for "depends on" , but it does work
> for select.
>
> if "depends on FOO if BAR" doesnt work, would adding "select DVB_CORE
> if VIDEO_PVRUSB2_DVB" solve the problem?
Also, this leads into a circular reference.
Cheers,
Mauro
--
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