linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Bolle <pebolle@tiscali.nl>
To: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Hans de Goede <hdegoede@redhat.com>,
	linux-media <linux-media@vger.kernel.org>
Subject: Re: linux-next: Tree for Oct 8 (media/usb/gspca)
Date: Thu, 09 Oct 2014 08:45:28 +0200	[thread overview]
Message-ID: <1412837128.21441.9.camel@x220> (raw)
In-Reply-To: <20141008225011.2d034c1e@recife.lan>

On Wed, 2014-10-08 at 22:50 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 08 Oct 2014 13:53:33 -0700
> Randy Dunlap <rdunlap@infradead.org> escreveu:
> > On 10/08/14 11:31, Mauro Carvalho Chehab wrote:
> > > From gpsca's PoV, IMHO, it should be fine to disable the webcam buttons if
> > > the webcam was compiled as builtin and the input subsystem is compiled as 
> > > module. The core feature expected on a camera is to capture streams. 
> > > Buttons are just a plus.
> > > 
> > > Also, most cams don't even have buttons. The gspca subdriver has support 
> > > for buttons for the few models that have it.
> > > 
> > > So, IMHO, it should be ok to have GSPCA=y and INPUT=m, provided that 
> > > the buttons will be disabled.
> > 
> > Then all of the sub-drivers that use IS_ENABLED(CONFIG_INPUT) should be
> > changed to use IS_BUILTIN(CONFIG_INPUT).
> > 
> > But that is too restrictive IMO.  The input subsystem will work fine when
> > CONFIG_INPUT=m and the GSPCA drivers are also loadable modules.
> 
> Agreed.
> 
> Maybe the solution would be something more complex like 
> (for drivers/media/usb/gspca/zc3xx.c):
> 
> #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && !IS_BUILTIN(CONFIG_USB_GSPCA_ZC3XX))

The above discussion meanders a bit, and I just stumbled onto it, but
would
    #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && defined(MODULE))

cover your requirements when using macros?

> Probably the best would be to write another macro that would evaluate
> like the above.


Paul Bolle

  reply	other threads:[~2014-10-09  6:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08  6:49 linux-next: Tree for Oct 8 Stephen Rothwell
2014-10-08 17:13 ` linux-next: Tree for Oct 8 (media/usb/gspca) Randy Dunlap
2014-10-08 18:31   ` Mauro Carvalho Chehab
2014-10-08 20:53     ` Randy Dunlap
2014-10-09  1:50       ` Mauro Carvalho Chehab
2014-10-09  6:45         ` Paul Bolle [this message]
2014-10-09 10:30           ` Mauro Carvalho Chehab
2014-10-09 11:26             ` Paul Bolle
2014-10-09 11:52               ` 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=1412837128.21441.9.camel@x220 \
    --to=pebolle@tiscali.nl \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=rdunlap@infradead.org \
    --cc=sfr@canb.auug.org.au \
    /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;
as well as URLs for NNTP newsgroup(s).