kernel-fxtec-pro1x/drivers/usb/core/Kconfig
David Brownell f3f3253d64 [PATCH] root hub updates (greater half)
This patch associates hub suspend and resume logic (including for root hubs)
with CONFIG_PM -- instead of CONFIG_USB_SUSPEND as before -- thereby unifying
two troublesome versions of suspend logic into just one.  It'll be easier to
keep things right from now on.

  - Now usbcore _always_ calls hcd->hub_suspend as needed, instead of
    only when USB_SUSPEND is enabled:
     * Those root hub methods are now called from hub suspend/resume;
       no more skipping between layers during device suspend/resume;
     * It now handles cases allowed by sysfs or autosuspended root hubs,
       by forcing the hub interface to resume too.

  - All devices, including virtual root hubs, now get the same treatment
    on their resume paths ... including re-activating all their interfaces.

Plus it gets rid of those stub copies of usb_{suspend,resume}_device(), and
updates the Kconfig to match the new definition of USB_SUSPEND:  it provides
(a) selective suspend, downstream from hubs; and (b) remote wakeup, upstream
from any device configuration which supports it.

This calls for minor followup patches for most HCDs (and their PCI glue).

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

 drivers/usb/core/Kconfig |   11 ++-
 drivers/usb/core/hub.c   |  163 +++++++++++++++++++++++++----------------------
 2 files changed, 97 insertions(+), 77 deletions(-)
2005-10-28 16:47:40 -07:00

102 lines
3.4 KiB
Text

#
# USB Core configuration
#
config USB_DEBUG
bool "USB verbose debug messages"
depends on USB
help
Say Y here if you want the USB core & hub drivers to produce a bunch
of debug messages to the system log. Select this if you are having a
problem with USB support and want to see more of what is going on.
comment "Miscellaneous USB options"
depends on USB
config USB_DEVICEFS
bool "USB device filesystem"
depends on USB
---help---
If you say Y here (and to "/proc file system support" in the "File
systems" section, above), you will get a file /proc/bus/usb/devices
which lists the devices currently connected to your USB bus or
busses, and for every connected device a file named
"/proc/bus/usb/xxx/yyy", where xxx is the bus number and yyy the
device number; the latter files can be used by user space programs
to talk directly to the device. These files are "virtual", meaning
they are generated on the fly and not stored on the hard drive.
You may need to mount the usbfs file system to see the files, use
mount -t usbfs none /proc/bus/usb
For the format of the various /proc/bus/usb/ files, please read
<file:Documentation/usb/proc_usb_info.txt>.
Please note that this code is completely unrelated to devfs, the
"/dev file system support".
Most users want to say Y here.
config USB_BANDWIDTH
bool "Enforce USB bandwidth allocation (EXPERIMENTAL)"
depends on USB && EXPERIMENTAL
help
If you say Y here, the USB subsystem enforces USB bandwidth
allocation and will prevent some device opens from succeeding
if they would cause USB bandwidth usage to go above 90% of
the bus bandwidth.
If you say N here, these conditions will cause warning messages
about USB bandwidth usage to be logged and some devices or
drivers may not work correctly.
config USB_DYNAMIC_MINORS
bool "Dynamic USB minor allocation (EXPERIMENTAL)"
depends on USB && EXPERIMENTAL
help
If you say Y here, the USB subsystem will use dynamic minor
allocation for any device that uses the USB major number.
This means that you can have more than 16 of a single type
of device (like USB printers).
If you are unsure about this, say N here.
config USB_SUSPEND
bool "USB selective suspend/resume and wakeup (EXPERIMENTAL)"
depends on USB && PM && EXPERIMENTAL
help
If you say Y here, you can use driver calls or the sysfs
"power/state" file to suspend or resume individual USB
peripherals.
Also, USB "remote wakeup" signaling is supported, whereby some
USB devices (like keyboards and network adapters) can wake up
their parent hub. That wakeup cascades up the USB tree, and
could wake the system from states like suspend-to-RAM.
If you are unsure about this, say N here.
config USB_OTG
bool
depends on USB && EXPERIMENTAL
select USB_SUSPEND
default n
config USB_OTG_WHITELIST
bool "Rely on OTG Targeted Peripherals List"
depends on USB_OTG
default y
help
If you say Y here, the "otg_whitelist.h" file will be used as a
product whitelist, so USB peripherals not listed there will be
rejected during enumeration. This behavior is required by the
USB OTG specification for all devices not on your product's
"Targeted Peripherals List".
Otherwise, peripherals not listed there will only generate a
warning and enumeration will continue. That's more like what
normal Linux-USB hosts do (other than the warning), and is
convenient for many stages of product development.