mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Adrian Bunk <bunk@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-dvb-maintainer@linuxtv.org, video4linux-list@redhat.com,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [GIT PATCHES] V4L/DVB fixes for 2.6.26
Date: Wed, 14 May 2008 14:55:54 -0300	[thread overview]
Message-ID: <20080514145554.10e3385c@gaivota> (raw)
In-Reply-To: <20080514165434.GC22115@cs181133002.pp.htv.fi>

On Wed, 14 May 2008 19:54:34 +0300
Adrian Bunk <bunk@kernel.org> wrote:

> On Wed, May 14, 2008 at 11:49:10AM -0300, Mauro Carvalho Chehab wrote:
> >...
> > PS.: There are yet a number of other Kconfig potential breakages at V4L/DVB. I'm 
> > currently working on fixing those issues. Basically, what users do is to select 
> > I2C, DVB and V4L as module. This works fine, but more complex scenarios where
> > you mix 'M' and 'Y' inside the subsystem generally cause compilation breakage.
> > Those scenarios are more theorical, since there's not much practical sense on
> > having a DVB driver foo as module, and V4L driver bar as in-kernel. However,
> > the better is to not allow compilation of the scenarios that don't work.
> > 
> > The main trouble at drivers/media Kbuild is that several rules there assumed that
> > "select" would check the "depends on" dependencies of the selected drivers.
> > However, this feature doesn't exist at the current Kbuild implementation. Even
> > if implemented, I suspect that this will generate circular dependency errors on
> > some cases.
> >...
> 
> The basic problem is that drivers/media/ does the most fancy kconfig 
> stuff in the kernel since it tries to both have very fine grained 
> dependencies and offer a usable kconfig UI to the user, which results
> in very complicated dependencies.

True.

> We are not getting this solved by any changes in the kconfig 
> implementation.
> 
> Thinking about reasonable ways to reduce the problem space:
> 
> Where could we reduce the complexity without big disadvantages?
> 
> Could we e.g. let VIDEO_DEV select I2C which would remove all the 
> fiddling with I2C dependencies (which is a bigger part of recent
> problems)?

This seems to be reasonable. However, there are quite a few devices that don't
need I2C (for example, some legacy ISA radio modules - also, some webcam
drivers don't use i2c layer to communicate with their i2c sensor - so - they
don't need I2C. The same also applies to some DVB drivers).

So, I'm not sure if this would be a good idea, since it will force I2C even for
devices that don't need. This is bad, for example, on embedded devices like
set-top-boxes and maybe on cellular phones with non-i2c webcams.

> I can make a patch for it after this pull went into Linus' tree if it is 
> considered an acceptable option.

It would be nice if you could help on fixing those issues.

One dependency that will probably solve is to add "depends on VIDEO_MEDIA &&
I2C" to all devices that are hybrid (bttv, saa7134, cx88, pvrusb, em28xx).

Cheers,
Mauro

  reply	other threads:[~2008-05-14 17:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 14:49 Mauro Carvalho Chehab
2008-05-14 16:54 ` Adrian Bunk
2008-05-14 17:55   ` Mauro Carvalho Chehab [this message]
2008-05-14 19:38     ` Adrian Bunk
2008-05-14 20:04       ` Mauro Carvalho Chehab
2008-05-15 16:02         ` Adrian Bunk
2008-05-16  1:50           ` Mauro Carvalho Chehab
2008-05-16 11:25             ` Adrian Bunk
2008-05-17 10:58               ` Mauro Carvalho Chehab
2008-05-15  0:51       ` [v4l-dvb-maintainer] " Trent Piepho
2008-05-15  2:10         ` Mauro Carvalho Chehab
  -- strict thread matches above, loose matches on Subject: below --
2008-04-30 21:10 Mauro Carvalho Chehab
2008-04-30  3:27 Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080514145554.10e3385c@gaivota \
    --to=mchehab@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=linux-dvb-maintainer@linuxtv.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®