linux-kernel - Re: linux-next: Tree for Oct 8 (media/usb/gspca)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Oct 2014 07:30:52 -0300
From:	Mauro Carvalho Chehab <mchehab@....samsung.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Randy Dunlap <rdunlap@...radead.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Hans de Goede <hdegoede@...hat.com>,
	linux-media <linux-media@...r.kernel.org>
Subject: Re: linux-next: Tree for Oct 8 (media/usb/gspca)

Em Thu, 09 Oct 2014 08:45:28 +0200
Paul Bolle <pebolle@...cali.nl> escreveu:

> 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@...radead.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?

No. What we need to do, for all gspca sub-drivers that have optional
support for buttons is to only enable the buttons support if:

	CONFIG_INPUT=y
or
	CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m

If we use a reverse logic, we need to disable the code if:
	# CONFIG_INPUT is not set
or
	CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y

The rationale for disabling the code on the last expression is that a
builtin code cannot call a function inside a module.

Also, as the submodule is already being compiled, we know that
CONFIG_USB_GSPCA_submodule is either module or builtin.

So, either one of those expressions should work:
	#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && !IS_BUILTIN(CONFIG_USB_GSPCA_submodule))
or
	#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE))
or
	#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && IS_MODULE(CONFIG_USB_GSPCA_submodule))

> 
> > Probably the best would be to write another macro that would evaluate
> > like the above.
> 
> 
> Paul Bolle
> 
--
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/