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: Thu, 15 May 2008 22:50:32 -0300	[thread overview]
Message-ID: <20080515225032.5a9235d7@gaivota> (raw)
In-Reply-To: <20080515160245.GA1936@cs181133002.pp.htv.fi>

On Thu, 15 May 2008 19:02:46 +0300
Adrian Bunk <bunk@kernel.org> wrote:

> On Wed, May 14, 2008 at 05:04:05PM -0300, Mauro Carvalho Chehab wrote:
> >...
> > > but otherwise that 
> > > would be a straightforward solution to solve these problems.
> > 
> > This will solve several troubles. Still, I think that there are still some
> > other missing dependencies (like INPUT, on drivers that select IR).
> 
> We could select INPUT from drivers/media/

Several drivers don't need INPUT (webcams, radio, etc). This is needed only by
the TV reception devices (analog and digital). 

Yet, I can't imagine any production kernel without INPUT. What happens if INPUT
is disabled? No keyboard, no tablet and no mouse at all?

> And FW_LOADER should really select HOTPLUG - there's no good reason for 
> FW_LOADER to be a user-visible option with dependencies.

It seems safe to select HOTPLUG instead of depending on it.

> But these two are problems that are only relevant for randconfig users 

True. Hotplug may eventually be relevant for embedded users. However,
"depends on HOTPLUG" is already present to all points where FW_LOADER is
needed (I added such patch at my previous pull request). So, the way it is
seems OK. I don't see much reason to change it.

> while the I2C troubles hit real users, so I want to attack the I2C 
> issues first.

Very true. Also, it is not obvious to the final user that he would need to
select I2C to have a video input driver.

> > > Any problem I miss or should I bake a patch?
> > 
> > I can't see any trouble on this approach. Feel free to work on it.
> 
> First issue when working on it:
> 
> The dependencies between VIDEO_IR and VIDEO_IR_I2C look wrong
> (consider VIDEO_IR=y and I2C=m).
> 
> It's not a problem since currently all users of VIDEO_IR also depend
> on I2C.

True. I got a compilation error with saa7134 that seems to be caused by this
trouble.
> 
> Should I fix the dependency or can I let VIDEO_IR select I2C and remove 
> VIDEO_IR_I2C?

The better would be to fix the dependency. The proper way seems to remove the
select from VIDEO_IR, and add an explicit select to VIDEO_IR_I2C where needed.

I would add an entry to allow the user to select this explicitly, for power
users, and select it implicitly. Something like:

select VIDEO_IR_I2C  if VIDEO_HELPER_CHIPS_AUTO

at the drivers under media/video that selects IR. This need to be mandatory for
a few drivers like saa7134, where some exported symbols at kbd-ir-i2c are used
there.

Cheers,
Mauro

  reply	other threads:[~2008-05-16  1:52 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
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 [this message]
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=20080515225032.5a9235d7@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®