missing dependencies for USB drivers in input
PATCH 1/1 missing dependencies for USB drivers in input
stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll end up with unbuildable configs.
--- 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(-)
drivers/input/joystick/Kconfig +1 -0
@@ -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.
drivers/input/misc/Kconfig +5 -0
@@ -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
drivers/input/mouse/Kconfig +1 -0
@@ -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.
drivers/input/tablet/Kconfig +4 -0
@@ -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
drivers/input/touchscreen/Kconfig +1 -0
@@ -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:
Signature · 1 line
1.5.0-rc2.GIT
[RFC] select and dependencies in Kconfig
Quoted 3 lines · Al Viro
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
Quoted 4 lines · Al Viro
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
Quoted 9 lines · Al Viro
Quoted 3 lines · Al Viro
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>.
Quoted 6 lines
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.
Quoted 2 lines · Al Viro
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.
Quoted 4 lines · Linus Torvalds
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
Quoted 49 lines · Satyam Sharma
Quoted 9 lines · Al Viro
Quoted 3 lines · Al Viro
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>.
Quoted 6 lines
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/332When 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.
Quoted 2 lines · Al Viro
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.
Quoted 4 lines · Linus Torvalds
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.
Quoted 7 lines
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
In reply to Al ViroQuoted 8 lines · Al Viro
Quoted 3 lines · Al Viro
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 DMABOUNCEarch/arm/common/Kconfig: bool
arch/arm/mach-ixp4xx/Kconfig:if ARCH_IXP4XXarch/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.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [RFC] select and dependencies in Kconfig
In reply to Al ViroQuoted 6 lines · Al Viro
Quoted 2 lines
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.
[...]
Quoted 2 lines
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).
Signature · 3 lines
Stefan Richter -=====-=-=== -=-= =---- http://arcgraph.de/sr/
Re: [RFC] select and dependencies in Kconfig
Quoted 3 lines · Stefan Richter
"A... select B" is just a flavor of "A... depends on B", with the additional instruction to the
KconfigUIs: 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
Quoted 2 lines
How about throwing "select" out of the
Kconfiglanguage 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'.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Re: [RFC] select and dependencies in Kconfig
Quoted 2 lines · Timur Tabi
Quoted 1 line · Stefan Richter
"A... select B" is just a flavor of "A... depends on B",
...
Quoted 2 lines
I think you mean "A... select B" is just a flavor of "B... depends on A".
No, A requires B's symbols.
Signature · 3 lines
Stefan Richter -=====-=-=== -=-= =---= http://arcgraph.de/sr/
Re: [RFC] select and dependencies in Kconfig
In reply to Timur TabiQuoted 11 lines · Timur Tabi
For example, if I want to add a new driver C that uses library B, I can just add this:
C
select BIf I have to use "depends on", then I would have to change the
Kconfigoption 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.
Signature · 3 lines
Stefan Richter -=====-=-=== -=-= =---= http://arcgraph.de/sr/
Re: [RFC] select and dependencies in Kconfig
In reply to Al ViroHi,
Quoted 8 lines · Al Viro
Quoted 3 lines · Al Viro
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