| # | |
| # 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" | |
| 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>. | |
| 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 | |
| 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 selective suspend/resume and wakeup" | |
| depends on USB && PM | |
| 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 | |
| select 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. | |