| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | # | 
					
						
							|  |  |  | # 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>. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-03-13 15:59:31 +01:00
										 |  |  | 	  Usbfs files can't handle Access Control Lists (ACL), which are the | 
					
						
							|  |  |  | 	  default way to grant access to USB devices for untrusted users of a | 
					
						
							|  |  |  | 	  desktop system. The usbfs functionality is replaced by real | 
					
						
							|  |  |  | 	  device-nodes managed by udev. These nodes live in /dev/bus/usb and | 
					
						
							|  |  |  | 	  are used by libusb. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | config USB_DEVICE_CLASS | 
					
						
							|  |  |  | 	bool "USB device class-devices (DEPRECATED)" | 
					
						
							|  |  |  | 	depends on USB | 
					
						
							| 
									
										
										
										
											2007-05-27 17:04:58 +02:00
										 |  |  | 	default y | 
					
						
							| 
									
										
										
										
											2007-03-13 15:59:31 +01:00
										 |  |  | 	---help--- | 
					
						
							|  |  |  | 	  Userspace access to USB devices is granted by device-nodes exported | 
					
						
							|  |  |  | 	  directly from the usbdev in sysfs. Old versions of the driver | 
					
						
							|  |  |  | 	  core and udev needed additional class devices to export device nodes. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	  These additional devices are difficult to handle in userspace, if | 
					
						
							| 
									
										
										
										
											2007-05-27 17:04:58 +02:00
										 |  |  | 	  information about USB interfaces must be available. One device | 
					
						
							|  |  |  | 	  contains the device node, the other device contains the interface | 
					
						
							|  |  |  | 	  data. Both devices are at the same level in sysfs (siblings) and one | 
					
						
							|  |  |  | 	  can't access the other. The device node created directly by the | 
					
						
							|  |  |  | 	  usb device is the parent device of the interface and therefore | 
					
						
							|  |  |  | 	  easily accessible from the interface event. | 
					
						
							| 
									
										
										
										
											2007-03-13 15:59:31 +01:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-05-27 17:04:58 +02:00
										 |  |  | 	  This option provides backward compatibility for libusb device | 
					
						
							|  |  |  | 	  nodes (lsusb) when usbfs is not used, and the following udev rule | 
					
						
							|  |  |  | 	  doesn't exist: | 
					
						
							|  |  |  | 	    SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \ | 
					
						
							|  |  |  | 	    NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644" | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 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 | 
					
						
							| 
									
										
											  
											
												[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-09-22 22:37:29 -07:00
										 |  |  | 	bool "USB selective suspend/resume and wakeup (EXPERIMENTAL)" | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	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 | 
					
						
							| 
									
										
											  
											
												[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-09-22 22:37:29 -07:00
										 |  |  | 	  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. | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	  If you are unsure about this, say N here. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-05-04 11:52:20 -04:00
										 |  |  | config USB_PERSIST | 
					
						
							|  |  |  | 	bool "USB device persistence during system suspend (DANGEROUS)" | 
					
						
							|  |  |  | 	depends on USB && PM && EXPERIMENTAL | 
					
						
							|  |  |  | 	default n | 
					
						
							|  |  |  | 	help | 
					
						
							| 
									
										
										
										
											2007-05-30 15:39:33 -04:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	  If you say Y here and enable the "power/persist" attribute | 
					
						
							|  |  |  | 	  for a USB device, the device's data structures will remain | 
					
						
							| 
									
										
										
										
											2007-05-04 11:52:20 -04:00
										 |  |  | 	  persistent across system suspend, even if the USB bus loses | 
					
						
							| 
									
										
										
										
											2007-05-30 15:39:33 -04:00
										 |  |  | 	  power.  (This includes hibernation, also known as swsusp or | 
					
						
							|  |  |  | 	  suspend-to-disk.)  The devices will reappear as if by magic | 
					
						
							|  |  |  | 	  when the system wakes up, with no need to unmount USB | 
					
						
							|  |  |  | 	  filesystems, rmmod host-controller drivers, or do anything | 
					
						
							|  |  |  | 	  else. | 
					
						
							| 
									
										
										
										
											2007-05-04 11:52:20 -04:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	  	WARNING: This option can be dangerous! | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	  If a USB device is replaced by another of the same type while | 
					
						
							|  |  |  | 	  the system is asleep, there's a good chance the kernel won't | 
					
						
							|  |  |  | 	  detect the change.  Likewise if the media in a USB storage | 
					
						
							|  |  |  | 	  device is replaced.  When this happens it's almost certain to | 
					
						
							|  |  |  | 	  cause data corruption and maybe even crash your system. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	  If you are unsure, say N here. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 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. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-04-02 10:18:09 -08:00
										 |  |  | config USB_OTG_BLACKLIST_HUB | 
					
						
							|  |  |  | 	bool "Disable external hubs" | 
					
						
							|  |  |  | 	depends on USB_OTG | 
					
						
							|  |  |  | 	help | 
					
						
							|  |  |  | 	  If you say Y here, then Linux will refuse to enumerate | 
					
						
							|  |  |  | 	  external hubs.  OTG hosts are allowed to reduce hardware | 
					
						
							|  |  |  | 	  and software costs by not supporting external hubs. | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 |