[PATCH] missing dependencies for USB drivers in input

[PATCH] missing dependencies for USB drivers in input

[Al Viro]

stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
end up with unbuildable configs.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 drivers/input/joystick/Kconfig    |    1 +
 drivers/input/misc/Kconfig        |    5 +++++
 drivers/input/mouse/Kconfig       |    1 +
 drivers/input/tablet/Kconfig      |    4 ++++
 drivers/input/touchscreen/Kconfig |    1 +
 5 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 82f563e..b002345 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -255,6 +255,7 @@ config JOYSTICK_JOYDUMP
 
 config JOYSTICK_XPAD
 	tristate "X-Box gamepad support"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use the X-Box pad with your computer.
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6013ace..842a7b4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -84,6 +84,7 @@ config INPUT_ATLAS_BTNS
 
 config INPUT_ATI_REMOTE
 	tristate "ATI / X10 USB RF remote control"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use an ATI or X10 "Lola" USB remote control.
@@ -99,6 +100,7 @@ config INPUT_ATI_REMOTE
 
 config INPUT_ATI_REMOTE2
 	tristate "ATI / Philips USB RF remote control"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use an ATI or Philips USB RF remote control.
@@ -114,6 +116,7 @@ config INPUT_ATI_REMOTE2
 config INPUT_KEYSPAN_REMOTE
 	tristate "Keyspan DMR USB remote control (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use a Keyspan DMR USB remote control.
@@ -128,6 +131,7 @@ config INPUT_KEYSPAN_REMOTE
 
 config INPUT_POWERMATE
 	tristate "Griffin PowerMate and Contour Jog support"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use Griffin PowerMate or Contour Jog devices.
@@ -144,6 +148,7 @@ config INPUT_POWERMATE
 config INPUT_YEALINK
 	tristate "Yealink usb-p1k voip phone"
 	depends EXPERIMENTAL
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to enable keyboard and LCD functions of the
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 2ccc114..eb0167e 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -111,6 +111,7 @@ config MOUSE_SERIAL
 
 config MOUSE_APPLETOUCH
 	tristate "Apple USB Touchpad support"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use an Apple USB Touchpad.
diff --git a/drivers/input/tablet/Kconfig b/drivers/input/tablet/Kconfig
index 12dfb0e..d371c0b 100644
--- a/drivers/input/tablet/Kconfig
+++ b/drivers/input/tablet/Kconfig
@@ -13,6 +13,7 @@ if INPUT_TABLET
 
 config TABLET_USB_ACECAD
 	tristate "Acecad Flair tablet support (USB)"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use the USB version of the Acecad Flair
@@ -25,6 +26,7 @@ config TABLET_USB_ACECAD
 
 config TABLET_USB_AIPTEK
 	tristate "Aiptek 6000U/8000U tablet support (USB)"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use the USB version of the Aiptek 6000U
@@ -49,6 +51,7 @@ config TABLET_USB_GTCO
 
 config TABLET_USB_KBTAB
 	tristate "KB Gear JamStudio tablet support (USB)"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use the USB version of the KB Gear
@@ -61,6 +64,7 @@ config TABLET_USB_KBTAB
 
 config TABLET_USB_WACOM
 	tristate "Wacom Intuos/Graphire tablet support (USB)"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  Say Y here if you want to use the USB version of the Wacom Intuos
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 5e640ae..4f09180 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -166,6 +166,7 @@ config TOUCHSCREEN_UCB1400
 
 config TOUCHSCREEN_USB_COMPOSITE
 	tristate "USB Touchscreen Driver"
+	depends on USB_ARCH_HAS_HCD
 	select USB
 	help
 	  USB Touchscreen driver for:
-- 
1.5.0-rc2.GIT

[RFC] select and dependencies in Kconfig

[Al Viro]

On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> 
> stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> end up with unbuildable configs.

BTW, this kind of situation happens often enough, so how about doing
the following: teach kconfig that if FOO selects BAR and BAR depends
on <expr>, we should act as if FOO had explicit depends on <expr>.

Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
turning FOO on will land us into unbuildable configuration (BAR turned on,
dependencies of BAR are not satisfied).  It really happens often enough to
be very annoying.  And we have fsckloads of dependencies that are there
only because of such scenarios.  Gets especially nasty when BAR is selected
by several dozens of options and dependencies of BAR change...

Implementing that is pretty simply; the only thing I'm not sure how to deal
with is how to show such inherited dependencies in menuconfig et.al.

Comments?

Re: [RFC] select and dependencies in Kconfig

[Linus Torvalds]

On Wed, 16 May 2007, Al Viro wrote:
> 
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.

Sounds sane. I wonder if there are any non-obvious gotchas, and I worry 
that the indirect dependency ends up getting really confusing at times, 
but I don't think the notion is broken - just worrying about how to *show* 
this to explain what is going on when people say "why can't I select X".

		Linus

Re: [RFC] select and dependencies in Kconfig

[Satyam Sharma]

On 5/16/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.
>
> Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
> turning FOO on will land us into unbuildable configuration (BAR turned on,
> dependencies of BAR are not satisfied).  It really happens often enough to
> be very annoying.  And we have fsckloads of dependencies that are there
> only because of such scenarios.  Gets especially nasty when BAR is selected
> by several dozens of options and dependencies of BAR change...

[ First off, "select"ing BAR that itself "depends on" BAZ is evil and
should be avoided, except where BAR is strictly library-like and thus
has simple or few basic dependencies. Still, like you say, dependencies
of BAR can change over time, or one could want to be lazy and wish to
avoid burdening users with having to pick dependencies _before_ the
option they're interested in -- especially with menuconfig not even
showing options whose dependencies are not satisfied already. ]

Anyway, I'd gotten into a couple of threads discussing precisely this over
the last couple of weeks, and thought of more-or-less a similar solution:
http://lkml.org/lkml/2007/5/7/332

When user picks FOO, we select BAR and note its dependencies (i.e. BAZ).
Build a complete dependency tree (FOO upwards), and show to the user all
the other config options (such as BAZ) that will now have to be picked
to satisfy user's selection of FOO without causing build breakages. If
user says yes, we *select* BAZ too (so now it can't be un-selected). If
user says no, FOO is not picked at all.

On 5/16/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> Implementing that is pretty simply; the only thing I'm not sure how to deal
> with is how to show such inherited dependencies in menuconfig et.al.

On 5/16/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
> that the indirect dependency ends up getting really confusing at times,
> but I don't think the notion is broken - just worrying about how to *show*
> this to explain what is going on when people say "why can't I select X".

For menuconfig / xconfig it _could_ simply be another dialog box that
pops up the moment user picks FOO.

For config/oldconfig/etc non-curses/graphics-based ones, we could do
something like what "yum" does for package dependencies on Red Hat
and Fedora. Once the entire thing is done, just run through the entire
.config just generated, and build these complete dependency trees for
all picked options, and thus compiling a list of all the BAZ'es that also
need to be picked now to satisfy user's demand for the FOO's.
Simple Y/n then follows.

Satyam

Re: [RFC] select and dependencies in Kconfig

[Satyam Sharma]

On 5/16/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 5/16/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> > >
> > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > > end up with unbuildable configs.
> >
> > BTW, this kind of situation happens often enough, so how about doing
> > the following: teach kconfig that if FOO selects BAR and BAR depends
> > on <expr>, we should act as if FOO had explicit depends on <expr>.
> >
> > Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
> > turning FOO on will land us into unbuildable configuration (BAR turned on,
> > dependencies of BAR are not satisfied).  It really happens often enough to
> > be very annoying.  And we have fsckloads of dependencies that are there
> > only because of such scenarios.  Gets especially nasty when BAR is selected
> > by several dozens of options and dependencies of BAR change...
>
> [ First off, "select"ing BAR that itself "depends on" BAZ is evil and
> should be avoided, except where BAR is strictly library-like and thus
> has simple or few basic dependencies. Still, like you say, dependencies
> of BAR can change over time, or one could want to be lazy and wish to
> avoid burdening users with having to pick dependencies _before_ the
> option they're interested in -- especially with menuconfig not even
> showing options whose dependencies are not satisfied already. ]
>
> Anyway, I'd gotten into a couple of threads discussing precisely this over
> the last couple of weeks, and thought of more-or-less a similar solution:
> http://lkml.org/lkml/2007/5/7/332
>
> When user picks FOO, we select BAR and note its dependencies (i.e. BAZ).
> Build a complete dependency tree (FOO upwards), and show to the user all
> the other config options (such as BAZ) that will now have to be picked
> to satisfy user's selection of FOO without causing build breakages. If
> user says yes, we *select* BAZ too (so now it can't be un-selected). If
> user says no, FOO is not picked at all.
>
> On 5/16/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> > Implementing that is pretty simply; the only thing I'm not sure how to deal
> > with is how to show such inherited dependencies in menuconfig et.al.
>
> On 5/16/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
> > that the indirect dependency ends up getting really confusing at times,
> > but I don't think the notion is broken - just worrying about how to *show*
> > this to explain what is going on when people say "why can't I select X".
>
> For menuconfig / xconfig it _could_ simply be another dialog box that
> pops up the moment user picks FOO.
>
> For config/oldconfig/etc non-curses/graphics-based ones, we could do
> something like what "yum" does for package dependencies on Red Hat
> and Fedora. Once the entire thing is done, just run through the entire
> .config just generated, and build these complete dependency trees for
> all picked options, and thus compiling a list of all the BAZ'es that also
> need to be picked now to satisfy user's demand for the FOO's.
> Simple Y/n then follows.

One minor glitch here: BAZ may not be a "select"able dependency at all.
Like Al wrote, it could be an <expr> that is something like !SMP etc that
can't be meaningfully selected.
For that case, menuconfig / xconfig could simply show up a dialog
explaining why the user's selection of FOO can't be allowed, and
config/oldconfig/etc can simply refuse to write out the broken .config.

Re: [RFC] select and dependencies in Kconfig

[Russell King]

On Wed, May 16, 2007 at 04:33:35AM +0100, Al Viro wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> > 
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
> 
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.

We first need to ensure that we don't have any cases which explore the
current behaviour.  I wonder how the following will be interpreted with
the ARCH_IXP4XX=y and ARCH_IXP4XX=n cases:

arch/arm/common/Kconfig:config SA1111
arch/arm/common/Kconfig:        bool
arch/arm/common/Kconfig:        select DMABOUNCE
arch/arm/common/Kconfig:
arch/arm/common/Kconfig:config DMABOUNCE
arch/arm/common/Kconfig:        bool

arch/arm/mach-ixp4xx/Kconfig:if ARCH_IXP4XX
arch/arm/mach-ixp4xx/Kconfig:
...
arch/arm/mach-ixp4xx/Kconfig:config DMABOUNCE
arch/arm/mach-ixp4xx/Kconfig-   bool
arch/arm/mach-ixp4xx/Kconfig-   default y
arch/arm/mach-ixp4xx/Kconfig-   depends on PCI
...
arch/arm/mach-ixp4xx/Kconfig:endif


We also have:

arch/arm/mm/Kconfig:config CPU_32v6K
arch/arm/mm/Kconfig-    bool "Support ARM V6K processor extensions" if !SMP
arch/arm/mm/Kconfig-    depends on CPU_V6
arch/arm/mm/Kconfig-    default y if SMP

which gives: option available on V6 CPUs, user selectable on V6 UP, always
selected on V6 SMP.

and:

arch/arm/mm/Kconfig:config CPU_V7
arch/arm/mm/Kconfig:    bool "Support ARM V7 processor"
arch/arm/mm/Kconfig:    depends on ARCH_INTEGRATOR
arch/arm/mm/Kconfig:    select CPU_32v6K

It would be undesirable for CPU_V7 to depend on CPU_V6 being set.  (V7
always has V6K.)  I guess V6K would have to become:

config CPU_32v6K
	bool "Support ARM V6K processor extensions" if !SMP && !CPU_V7
	depends on CPU_V6 || CPU_V7
	default y if SMP || CPU_V7

and the select statement removed from CPU_V7.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [RFC] select and dependencies in Kconfig

[Stefan Richter]

Al Viro wrote:
>> stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
>> end up with unbuildable configs.
> 
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.

"A... select B" is just a flavor of "A... depends on B", with the
additional instruction to the Kconfig UIs:  Don't hide A if you can
silently switch on B.

So, since it is just a flavor of 'depend on', it is very obvious that it
has to propagate indirect dependencies just like 'depends on' does.

[...]
> the only thing I'm not sure how to deal
> with is how to show such inherited dependencies in menuconfig et.al.

How about throwing "select" out of the Kconfig language and improving
the UIs instead, so that users find what they want and need?

Compare to software package management.  I think most of the package
management systems store merely plain dependencies in the package
metadata.  The package manager UIs then allow users to auto-select all
packages which package A depends on, show him what was selected, let him
edit his choice before massive downloads, et cetera.  Also, package
manager UIs often offer some collections of typically used packages and
so on.  I don't think the package metadata already contain some
instructions which stuff to pre-select for the user.  It's all in the UIs.

Back to Kconfig.

We have

  - driver-like options which enable building of certain functionality.
    They often depend on multiple other options higher up, either by
    directly depending on one other option which itself may depend on
    others, or even by directly depending on several options (which each
    may depend others.)
    The driver-like options are the ones that are most relevant to users
    because they ultimately decide what the kernel can do.

  - Tunables which modify how those driver-like code will behave.

  - Infrastructure (subsystem cores), libraries.
    Nobody really cares about these on their own, we only want have all
    those of them built which serve above mentioned driver-like options.

Did I forget anything?

So, we put

  - metadata about kernel parts (what do they, what are their
    dependencies)
    into Kconfig files,

  - methods to produce .configs (which honor the dependencies and
    reflect which kernel functionality the user wanted)
    into "make fooconfig" programs,

  - user interfaces which control these methods
    into "make fooconfig" programs.

The goal is to let the user safely and efficiently enable everything he
needs/ disable everything he doesn't need.

The question is:  Which kind of information has to be put into the
Kconfig files to achieve this objective --- besides the plain
information about dependencies and human-readable information about the
functionality of the options?

Do we need instructions like "select" in Kconfig files, or do we rather
need more powerful "make fooconfig" programs?

PS:  Actually, the problems with "select" which Al pointed out in the
parent post show that "select" doesn't really let us get by with less
powerful "make fooconfig" programs, because proper treatment of
"depends" is sometimes nontrivial.

PPS:  Other current discussions indicate that additional metadata in the
Kconfigs might perhaps be useful, e.g. metadata about a kernel part's
lifecycle status (experimental, deprecated et al).
-- 
Stefan Richter
-=====-=-=== -=-= =----
http://arcgraph.de/sr/

Re: [RFC] select and dependencies in Kconfig

[Timur Tabi]

Stefan Richter wrote:

> "A... select B" is just a flavor of "A... depends on B", with the
> additional instruction to the Kconfig UIs:  Don't hide A if you can
> silently switch on B.

I think you mean "A... select B" is just a flavor of "B... depends on A".  There is one 
minor difference between the two.

If A is a driver and B is a library, then it's more intuitive to update the Kconfig option 
for A then it is to update the Kconfig option for B.  For example, if I want to add a new 
driver C that uses library B, I can just add this:

C
	select B

If I have to use "depends on", then I would have to change the Kconfig option for B like this:

B
	depends on A || C

And every time I create a new driver that depends on library B, I have to update that 
"depends on" line *in addition to* creating the Kconfig line for the new driver.  If 10 
drivers use library B, you'll have this:

B
	depends on A || C || D || E || F || G || H || I || J || K

> How about throwing "select" out of the Kconfig language and improving
> the UIs instead, so that users find what they want and need?

I know a lot of people don't like 'select', but I prefer it over 'depends on'.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: [RFC] select and dependencies in Kconfig

[Stefan Richter]

Timur Tabi wrote:
> Stefan Richter wrote:
>> "A... select B" is just a flavor of "A... depends on B",
...
> I think you mean "A... select B" is just a flavor of "B... depends on
> A".

No, A requires B's symbols.
-- 
Stefan Richter
-=====-=-=== -=-= =---=
http://arcgraph.de/sr/

Re: [RFC] select and dependencies in Kconfig

[Stefan Richter]

Timur Tabi wrote:
> For example, if I want to add a new driver C that uses library B, I can
> just add this:
> 
> C
>     select B
> 
> If I have to use "depends on", then I would have to change the Kconfig
> option for B like this:
> 
> B
>     depends on A || C

You mean, "B... serves A, C".

However, it shouldn't matter which way around the dependencies are
written down in the Kconfigs.  What does matter is how "make
{old,menu,...}config" deal with it.
-- 
Stefan Richter
-=====-=-=== -=-= =---=
http://arcgraph.de/sr/

Re: [RFC] select and dependencies in Kconfig

[Roman Zippel]

Hi,

On Wed, 16 May 2007, Al Viro wrote:

> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> > 
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
> 
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.

select was really intended to override the dependencies (Russell gave a 
few examples), the other usage is what is abusing select (I can 
understand why people are doing it, but it still is).
So I'd really like to get the focus away from select and rather see it as 
a new syntax.

One problem with your idea is that a symbol itself has no normal 
dependencies. A symbol has properties and these have the dependencies, so 
it's not that easy. What could be used is the visibility value of a symbol 
of a symbol, but that can't be used in expressions yet.

The problem is now being able to select visible and nonvisible symbols. 
One way is to introduce a new syntax for the behaviour you suggest or we 
change the current select syntax and mark nonvisible symbols as being 
selectable. Considering the current problems I sort of like the latter.

bye, Roman