1What: /sys/bus/usb/device/.../authorized 2Date: July 2008 3KernelVersion: 2.6.26 4Contact: David Vrabel <david.vrabel@csr.com> 5Description: 6 Authorized devices are available for use by device 7 drivers, non-authorized one are not. By default, wired 8 USB devices are authorized. 9 10 Certified Wireless USB devices are not authorized 11 initially and should be (by writing 1) after the 12 device has been authenticated. 13 14What: /sys/bus/usb/device/.../wusb_cdid 15Date: July 2008 16KernelVersion: 2.6.27 17Contact: David Vrabel <david.vrabel@csr.com> 18Description: 19 For Certified Wireless USB devices only. 20 21 A devices's CDID, as 16 space-separated hex octets. 22 23What: /sys/bus/usb/device/.../wusb_ck 24Date: July 2008 25KernelVersion: 2.6.27 26Contact: David Vrabel <david.vrabel@csr.com> 27Description: 28 For Certified Wireless USB devices only. 29 30 Write the device's connection key (CK) to start the 31 authentication of the device. The CK is 16 32 space-separated hex octets. 33 34What: /sys/bus/usb/device/.../wusb_disconnect 35Date: July 2008 36KernelVersion: 2.6.27 37Contact: David Vrabel <david.vrabel@csr.com> 38Description: 39 For Certified Wireless USB devices only. 40 41 Write a 1 to force the device to disconnect 42 (equivalent to unplugging a wired USB device). 43 44What: /sys/bus/usb/drivers/.../new_id 45Date: October 2011 46Contact: linux-usb@vger.kernel.org 47Description: 48 Writing a device ID to this file will attempt to 49 dynamically add a new device ID to a USB device driver. 50 This may allow the driver to support more hardware than 51 was included in the driver's static device ID support 52 table at compile time. The format for the device ID is: 53 idVendor idProduct bInterfaceClass. 54 The vendor ID and device ID fields are required, the 55 interface class is optional. 56 Upon successfully adding an ID, the driver will probe 57 for the device and attempt to bind to it. For example: 58 # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id 59 60 Reading from this file will list all dynamically added 61 device IDs in the same format, with one entry per 62 line. For example: 63 # cat /sys/bus/usb/drivers/foo/new_id 64 8086 10f5 65 dead beef 06 66 f00d cafe 67 68 The list will be truncated at PAGE_SIZE bytes due to 69 sysfs restrictions. 70 71What: /sys/bus/usb-serial/drivers/.../new_id 72Date: October 2011 73Contact: linux-usb@vger.kernel.org 74Description: 75 For serial USB drivers, this attribute appears under the 76 extra bus folder "usb-serial" in sysfs; apart from that 77 difference, all descriptions from the entry 78 "/sys/bus/usb/drivers/.../new_id" apply. 79 80What: /sys/bus/usb/drivers/.../remove_id 81Date: November 2009 82Contact: CHENG Renquan <rqcheng@smu.edu.sg> 83Description: 84 Writing a device ID to this file will remove an ID 85 that was dynamically added via the new_id sysfs entry. 86 The format for the device ID is: 87 idVendor idProduct. After successfully 88 removing an ID, the driver will no longer support the 89 device. This is useful to ensure auto probing won't 90 match the driver to the device. For example: 91 # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id 92 93 Reading from this file will list the dynamically added 94 device IDs, exactly like reading from the entry 95 "/sys/bus/usb/drivers/.../new_id" 96 97What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm 98Date: September 2011 99Contact: Andiry Xu <andiry.xu@amd.com> 100Description: 101 If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device 102 is plugged in to a xHCI host which support link PM, it will 103 perform a LPM test; if the test is passed and host supports 104 USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will 105 be enabled for the device and the USB device directory will 106 contain a file named power/usb2_hardware_lpm. The file holds 107 a string value (enable or disable) indicating whether or not 108 USB2 hardware LPM is enabled for the device. Developer can 109 write y/Y/1 or n/N/0 to the file to enable/disable the 110 feature. 111 112What: /sys/bus/usb/devices/.../removable 113Date: February 2012 114Contact: Matthew Garrett <mjg@redhat.com> 115Description: 116 Some information about whether a given USB device is 117 physically fixed to the platform can be inferred from a 118 combination of hub descriptor bits and platform-specific data 119 such as ACPI. This file will read either "removable" or 120 "fixed" if the information is available, and "unknown" 121 otherwise. 122 123What: /sys/bus/usb/devices/.../ltm_capable 124Date: July 2012 125Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com> 126Description: 127 USB 3.0 devices may optionally support Latency Tolerance 128 Messaging (LTM). They indicate their support by setting a bit 129 in the bmAttributes field of their SuperSpeed BOS descriptors. 130 If that bit is set for the device, ltm_capable will read "yes". 131 If the device doesn't support LTM, the file will read "no". 132 The file will be present for all speeds of USB devices, and will 133 always read "no" for USB 1.1 and USB 2.0 devices. 134 135What: /sys/bus/usb/devices/.../(hub interface)/portX 136Date: August 2012 137Contact: Lan Tianyu <tianyu.lan@intel.com> 138Description: 139 The /sys/bus/usb/devices/.../(hub interface)/portX 140 is usb port device's sysfs directory. 141 142What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type 143Date: January 2013 144Contact: Lan Tianyu <tianyu.lan@intel.com> 145Description: 146 Some platforms provide usb port connect types through ACPI. 147 This attribute is to expose these information to user space. 148 The file will read "hotplug", "wired" and "not used" if the 149 information is available, and "unknown" otherwise. 150 151What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout 152Date: May 2013 153Contact: Mathias Nyman <mathias.nyman@linux.intel.com> 154Description: 155 USB 2.0 devices may support hardware link power management (LPM) 156 L1 sleep state. The usb2_lpm_l1_timeout attribute allows 157 tuning the timeout for L1 inactivity timer (LPM timer), e.g. 158 needed inactivity time before host requests the device to go to L1 sleep. 159 Useful for power management tuning. 160 Supported values are 0 - 65535 microseconds. 161 162What: /sys/bus/usb/devices/.../power/usb2_lpm_besl 163Date: May 2013 164Contact: Mathias Nyman <mathias.nyman@linux.intel.com> 165Description: 166 USB 2.0 devices that support hardware link power management (LPM) 167 L1 sleep state now use a best effort service latency value (BESL) to 168 indicate the best effort to resumption of service to the device after the 169 initiation of the resume event. 170 If the device does not have a preferred besl value then the host can select 171 one instead. This usb2_lpm_besl attribute allows to tune the host selected besl 172 value in order to tune power saving and service latency. 173 174 Supported values are 0 - 15. 175 More information on how besl values map to microseconds can be found in 176 USB 2.0 ECN Errata for Link Power Management, section 4.10) 177