| What: /sys/bus/usb/device/.../authorized |
| Date: July 2008 |
| KernelVersion: 2.6.26 |
| Contact: David Vrabel <david.vrabel@csr.com> |
| Description: |
| Authorized devices are available for use by device |
| drivers, non-authorized one are not. By default, wired |
| USB devices are authorized. |
| |
| Certified Wireless USB devices are not authorized |
| initially and should be (by writing 1) after the |
| device has been authenticated. |
| |
| What: /sys/bus/usb/device/.../wusb_cdid |
| Date: July 2008 |
| KernelVersion: 2.6.27 |
| Contact: David Vrabel <david.vrabel@csr.com> |
| Description: |
| For Certified Wireless USB devices only. |
| |
| A devices's CDID, as 16 space-separated hex octets. |
| |
| What: /sys/bus/usb/device/.../wusb_ck |
| Date: July 2008 |
| KernelVersion: 2.6.27 |
| Contact: David Vrabel <david.vrabel@csr.com> |
| Description: |
| For Certified Wireless USB devices only. |
| |
| Write the device's connection key (CK) to start the |
| authentication of the device. The CK is 16 |
| space-separated hex octets. |
| |
| What: /sys/bus/usb/device/.../wusb_disconnect |
| Date: July 2008 |
| KernelVersion: 2.6.27 |
| Contact: David Vrabel <david.vrabel@csr.com> |
| Description: |
| For Certified Wireless USB devices only. |
| |
| Write a 1 to force the device to disconnect |
| (equivalent to unplugging a wired USB device). |
| |
| What: /sys/bus/usb/drivers/.../new_id |
| Date: October 2011 |
| Contact: linux-usb@vger.kernel.org |
| Description: |
| Writing a device ID to this file will attempt to |
| dynamically add a new device ID to a USB device driver. |
| This may allow the driver to support more hardware than |
| was included in the driver's static device ID support |
| table at compile time. The format for the device ID is: |
| idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct |
| The vendor ID and device ID fields are required, the |
| rest is optional. The Ref* tuple can be used to tell the |
| driver to use the same driver_data for the new device as |
| it is used for the reference device. |
| Upon successfully adding an ID, the driver will probe |
| for the device and attempt to bind to it. For example: |
| # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id |
| |
| Here add a new device (0458:7045) using driver_data from |
| an already supported device (0458:704c): |
| # echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id |
| |
| Reading from this file will list all dynamically added |
| device IDs in the same format, with one entry per |
| line. For example: |
| # cat /sys/bus/usb/drivers/foo/new_id |
| 8086 10f5 |
| dead beef 06 |
| f00d cafe |
| |
| The list will be truncated at PAGE_SIZE bytes due to |
| sysfs restrictions. |
| |
| What: /sys/bus/usb-serial/drivers/.../new_id |
| Date: October 2011 |
| Contact: linux-usb@vger.kernel.org |
| Description: |
| For serial USB drivers, this attribute appears under the |
| extra bus folder "usb-serial" in sysfs; apart from that |
| difference, all descriptions from the entry |
| "/sys/bus/usb/drivers/.../new_id" apply. |
| |
| What: /sys/bus/usb/drivers/.../remove_id |
| Date: November 2009 |
| Contact: CHENG Renquan <rqcheng@smu.edu.sg> |
| Description: |
| Writing a device ID to this file will remove an ID |
| that was dynamically added via the new_id sysfs entry. |
| The format for the device ID is: |
| idVendor idProduct. After successfully |
| removing an ID, the driver will no longer support the |
| device. This is useful to ensure auto probing won't |
| match the driver to the device. For example: |
| # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id |
| |
| Reading from this file will list the dynamically added |
| device IDs, exactly like reading from the entry |
| "/sys/bus/usb/drivers/.../new_id" |
| |
| What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm |
| Date: September 2011 |
| Contact: Andiry Xu <andiry.xu@amd.com> |
| Description: |
| If CONFIG_PM is set and a USB 2.0 lpm-capable device is plugged |
| in to a xHCI host which support link PM, it will perform a LPM |
| test; if the test is passed and host supports USB2 hardware LPM |
| (xHCI 1.0 feature), USB2 hardware LPM will be enabled for the |
| device and the USB device directory will contain a file named |
| power/usb2_hardware_lpm. The file holds a string value (enable |
| or disable) indicating whether or not USB2 hardware LPM is |
| enabled for the device. Developer can write y/Y/1 or n/N/0 to |
| the file to enable/disable the feature. |
| |
| What: /sys/bus/usb/devices/.../power/usb3_hardware_lpm |
| Date: June 2015 |
| Contact: Kevin Strasser <kevin.strasser@linux.intel.com> |
| Description: |
| If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged |
| in to a xHCI host which supports link PM, it will check if U1 |
| and U2 exit latencies have been set in the BOS descriptor; if |
| the check is is passed and the host supports USB3 hardware LPM, |
| USB3 hardware LPM will be enabled for the device and the USB |
| device directory will contain a file named |
| power/usb3_hardware_lpm. The file holds a string value (enable |
| or disable) indicating whether or not USB3 hardware LPM is |
| enabled for the device. |
| |
| What: /sys/bus/usb/devices/.../removable |
| Date: February 2012 |
| Contact: Matthew Garrett <mjg@redhat.com> |
| Description: |
| Some information about whether a given USB device is |
| physically fixed to the platform can be inferred from a |
| combination of hub descriptor bits and platform-specific data |
| such as ACPI. This file will read either "removable" or |
| "fixed" if the information is available, and "unknown" |
| otherwise. |
| |
| What: /sys/bus/usb/devices/.../ltm_capable |
| Date: July 2012 |
| Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com> |
| Description: |
| USB 3.0 devices may optionally support Latency Tolerance |
| Messaging (LTM). They indicate their support by setting a bit |
| in the bmAttributes field of their SuperSpeed BOS descriptors. |
| If that bit is set for the device, ltm_capable will read "yes". |
| If the device doesn't support LTM, the file will read "no". |
| The file will be present for all speeds of USB devices, and will |
| always read "no" for USB 1.1 and USB 2.0 devices. |
| |
| What: /sys/bus/usb/devices/.../(hub interface)/portX |
| Date: August 2012 |
| Contact: Lan Tianyu <tianyu.lan@intel.com> |
| Description: |
| The /sys/bus/usb/devices/.../(hub interface)/portX |
| is usb port device's sysfs directory. |
| |
| What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type |
| Date: January 2013 |
| Contact: Lan Tianyu <tianyu.lan@intel.com> |
| Description: |
| Some platforms provide usb port connect types through ACPI. |
| This attribute is to expose these information to user space. |
| The file will read "hotplug", "wired" and "not used" if the |
| information is available, and "unknown" otherwise. |
| |
| What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout |
| Date: May 2013 |
| Contact: Mathias Nyman <mathias.nyman@linux.intel.com> |
| Description: |
| USB 2.0 devices may support hardware link power management (LPM) |
| L1 sleep state. The usb2_lpm_l1_timeout attribute allows |
| tuning the timeout for L1 inactivity timer (LPM timer), e.g. |
| needed inactivity time before host requests the device to go to L1 sleep. |
| Useful for power management tuning. |
| Supported values are 0 - 65535 microseconds. |
| |
| What: /sys/bus/usb/devices/.../power/usb2_lpm_besl |
| Date: May 2013 |
| Contact: Mathias Nyman <mathias.nyman@linux.intel.com> |
| Description: |
| USB 2.0 devices that support hardware link power management (LPM) |
| L1 sleep state now use a best effort service latency value (BESL) to |
| indicate the best effort to resumption of service to the device after the |
| initiation of the resume event. |
| If the device does not have a preferred besl value then the host can select |
| one instead. This usb2_lpm_besl attribute allows to tune the host selected besl |
| value in order to tune power saving and service latency. |
| |
| Supported values are 0 - 15. |
| More information on how besl values map to microseconds can be found in |
| USB 2.0 ECN Errata for Link Power Management, section 4.10) |