mirror of
				https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
				synced 2025-10-31 09:36:25 +00:00 
			
		
		
		
	 6d60261009
			
		
	
	
		6d60261009
		
	
	
	
	
		
			
			With patch as1329 (USB: convert to the runtime PM framework), we make USB_SUSPEND depend on PM_RUNTIME instead of CONFIG_PM. Also, CONFIG_USB_OTG selects CONFIG_USB_SUSPEND. If PM_RUNTIME is not enabled, and we try to enable USB_OTG, we will end up with CONFIG_USB_SUSPEND selected. This is due to a known bug with the select statement. This makes the build break on various OMAP configs (which have CONFIG_USB_OTG set by default, but do not yet have CONFIG_PM_RUNTIME enabled). Avoid this by changing the logic for CONFIG_USB_OTG from "select USB_SUSPEND" to "depends on USB_SUSPEND" Signed-off-by: Anand Gadiyar <gadiyar@ti.com> CC: Michal Marek <mmarek@suse.cz> CC: Tony Lindgren <tony@atomide.com> CC: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
		
			
				
	
	
		
			143 lines
		
	
	
		
			5.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			143 lines
		
	
	
		
			5.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| #
 | |
| # 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.
 | |
| 
 | |
| config USB_ANNOUNCE_NEW_DEVICES
 | |
| 	bool "USB announce new devices"
 | |
| 	depends on USB
 | |
| 	default N
 | |
| 	help
 | |
| 	  Say Y here if you want the USB core to always announce the
 | |
| 	  idVendor, idProduct, Manufacturer, Product, and SerialNumber
 | |
| 	  strings for every new USB device to the syslog.  This option is
 | |
| 	  usually used by distro vendors to help with debugging and to
 | |
| 	  let users know what specific device was added to the machine
 | |
| 	  in what location.
 | |
| 
 | |
| 	  If you do not want this kind of information sent to the system
 | |
| 	  log, or have any doubts about this, say N here.
 | |
| 
 | |
| comment "Miscellaneous USB options"
 | |
| 	depends on USB
 | |
| 
 | |
| config USB_DEVICEFS
 | |
| 	bool "USB device filesystem (DEPRECATED)"
 | |
| 	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>.
 | |
| 
 | |
| 	  Modern Linux systems do not use this.
 | |
| 
 | |
| 	  Usbfs entries are files and not character devices; usbfs 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 lived in /dev/bus/usb and are used by libusb.
 | |
| 
 | |
| config USB_DEVICE_CLASS
 | |
| 	bool "USB device class-devices (DEPRECATED)"
 | |
| 	depends on USB
 | |
| 	default y
 | |
| 	---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
 | |
| 	  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.
 | |
| 
 | |
| 	  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"
 | |
| 
 | |
| config USB_DYNAMIC_MINORS
 | |
| 	bool "Dynamic USB minor allocation"
 | |
| 	depends on USB
 | |
| 	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 runtime power management (suspend/resume and wakeup)"
 | |
| 	depends on USB && PM_RUNTIME
 | |
| 	help
 | |
| 	  If you say Y here, you can use driver calls or the sysfs
 | |
| 	  "power/level" file to suspend or resume individual USB
 | |
| 	  peripherals and to enable or disable autosuspend (see
 | |
| 	  Documentation/usb/power-management.txt for more details).
 | |
| 
 | |
| 	  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
 | |
| 	depends on USB_SUSPEND
 | |
| 	default n
 | |
| 
 | |
| 
 | |
| config USB_OTG_WHITELIST
 | |
| 	bool "Rely on OTG Targeted Peripherals List"
 | |
| 	depends on USB_OTG || EMBEDDED
 | |
| 	default y if USB_OTG
 | |
| 	default n if EMBEDDED
 | |
| 	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".  "Embedded Hosts" are likewise
 | |
| 	  allowed to support only a limited number of peripherals.
 | |
| 
 | |
| 	  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.
 | |
| 
 | |
| config USB_OTG_BLACKLIST_HUB
 | |
| 	bool "Disable external hubs"
 | |
| 	depends on USB_OTG || EMBEDDED
 | |
| 	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.  So
 | |
| 	  are "Embedded Hosts" that don't offer OTG support.
 | |
| 
 |