1What:		/sys/bus/usb/devices/.../power/autosuspend
  2Date:		March 2007
  3KernelVersion:	2.6.21
  4Contact:	Alan Stern <stern@rowland.harvard.edu>
  5Description:
  6		Each USB device directory will contain a file named
  7		power/autosuspend.  This file holds the time (in seconds)
  8		the device must be idle before it will be autosuspended.
  9		0 means the device will be autosuspended as soon as
 10		possible.  Negative values will prevent the device from
 11		being autosuspended at all, and writing a negative value
 12		will resume the device if it is already suspended.
 13
 14		The autosuspend delay for newly-created devices is set to
 15		the value of the usbcore.autosuspend module parameter.
 16
 17What:		/sys/bus/usb/devices/.../power/persist
 18Date:		May 2007
 19KernelVersion:	2.6.23
 20Contact:	Alan Stern <stern@rowland.harvard.edu>
 21Description:
 22		If CONFIG_USB_PERSIST is set, then each USB device directory
 23		will contain a file named power/persist.  The file holds a
 24		boolean value (0 or 1) indicating whether or not the
 25		"USB-Persist" facility is enabled for the device.  Since the
 26		facility is inherently dangerous, it is disabled by default
 27		for all devices except hubs.  For more information, see
 28		Documentation/usb/persist.txt.
 29
 30What:		/sys/bus/usb/device/.../power/connected_duration
 31Date:		January 2008
 32KernelVersion:	2.6.25
 33Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
 34Description:
 35		If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
 36		is present.  When read, it returns the total time (in msec)
 37		that the USB device has been connected to the machine.  This
 38		file is read-only.
 39Users:
 40		PowerTOP <power@bughost.org>
 41		http://www.lesswatts.org/projects/powertop/
 42
 43What:		/sys/bus/usb/device/.../power/active_duration
 44Date:		January 2008
 45KernelVersion:	2.6.25
 46Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
 47Description:
 48		If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
 49		is present.  When read, it returns the total time (in msec)
 50		that the USB device has been active, i.e. not in a suspended
 51		state.  This file is read-only.
 52
 53		Tools can use this file and the connected_duration file to
 54		compute the percentage of time that a device has been active.
 55		For example,
 56		echo $((100 * `cat active_duration` / `cat connected_duration`))
 57		will give an integer percentage.  Note that this does not
 58		account for counter wrap.
 59Users:
 60		PowerTOP <power@bughost.org>
 61		http://www.lesswatts.org/projects/powertop/
 62
 63What:		/sys/bus/usb/device/<busnum>-<devnum>...:<config num>-<interface num>/supports_autosuspend
 64Date:		January 2008
 65KernelVersion:	2.6.27
 66Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
 67Description:
 68		When read, this file returns 1 if the interface driver
 69		for this interface supports autosuspend.  It also
 70		returns 1 if no driver has claimed this interface, as an
 71		unclaimed interface will not stop the device from being
 72		autosuspended if all other interface drivers are idle.
 73		The file returns 0 if autosuspend support has not been
 74		added to the driver.
 75Users:
 76		USB PM tool
 77		git://git.moblin.org/users/sarah/usb-pm-tool/
 
 
 
 
 
 
 78
 79What:		/sys/bus/usb/device/.../authorized
 80Date:		July 2008
 81KernelVersion:	2.6.26
 82Contact:	David Vrabel <david.vrabel@csr.com>
 83Description:
 84		Authorized devices are available for use by device
 85		drivers, non-authorized one are not.  By default, wired
 86		USB devices are authorized.
 87
 88		Certified Wireless USB devices are not authorized
 89		initially and should be (by writing 1) after the
 90		device has been authenticated.
 91
 92What:		/sys/bus/usb/device/.../wusb_cdid
 93Date:		July 2008
 94KernelVersion:	2.6.27
 95Contact:	David Vrabel <david.vrabel@csr.com>
 96Description:
 97		For Certified Wireless USB devices only.
 98
 99		A devices's CDID, as 16 space-separated hex octets.
100
101What:		/sys/bus/usb/device/.../wusb_ck
102Date:		July 2008
103KernelVersion:	2.6.27
104Contact:	David Vrabel <david.vrabel@csr.com>
105Description:
106		For Certified Wireless USB devices only.
107
108		Write the device's connection key (CK) to start the
109		authentication of the device.  The CK is 16
110		space-separated hex octets.
111
112What:		/sys/bus/usb/device/.../wusb_disconnect
113Date:		July 2008
114KernelVersion:	2.6.27
115Contact:	David Vrabel <david.vrabel@csr.com>
116Description:
117		For Certified Wireless USB devices only.
118
119		Write a 1 to force the device to disconnect
120		(equivalent to unplugging a wired USB device).
121
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
122What:		/sys/bus/usb/drivers/.../remove_id
123Date:		November 2009
124Contact:	CHENG Renquan <rqcheng@smu.edu.sg>
125Description:
126		Writing a device ID to this file will remove an ID
127		that was dynamically added via the new_id sysfs entry.
128		The format for the device ID is:
129		idVendor idProduct.	After successfully
130		removing an ID, the driver will no longer support the
131		device.  This is useful to ensure auto probing won't
132		match the driver to the device.  For example:
133		# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
134
135What:		/sys/bus/usb/device/.../avoid_reset_quirk
136Date:		December 2009
137Contact:	Oliver Neukum <oliver@neukum.org>
138Description:
139		Writing 1 to this file tells the kernel that this
140		device will morph into another mode when it is reset.
141		Drivers will not use reset for error handling for
142		such devices.
143Users:
144		usb_modeswitch
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

  1What:		/sys/bus/usb/devices/INTERFACE/authorized
  2Date:		August 2015
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  3Description:
  4		This allows to authorize (1) or deauthorize (0)
  5		individual interfaces instead a whole device
  6		in contrast to the device authorization.
  7		If a deauthorized interface will be authorized
  8		so the driver probing must be triggered manually
  9		by writing INTERFACE to /sys/bus/usb/drivers_probe
 10		This allows to avoid side-effects with drivers
 11		that need multiple interfaces.
 12		A deauthorized interface cannot be probed or claimed.
 13
 14What:		/sys/bus/usb/devices/usbX/interface_authorized_default
 15Date:		August 2015
 16Description:
 17		This is used as value that determines if interfaces
 18		would be authorized by default.
 19		The value can be 1 or 0. It's by default 1.
 20
 21What:		/sys/bus/usb/device/.../authorized
 22Date:		July 2008
 23KernelVersion:	2.6.26
 24Contact:	David Vrabel <david.vrabel@csr.com>
 25Description:
 26		Authorized devices are available for use by device
 27		drivers, non-authorized one are not.  By default, wired
 28		USB devices are authorized.
 29
 30		Certified Wireless USB devices are not authorized
 31		initially and should be (by writing 1) after the
 32		device has been authenticated.
 33
 34What:		/sys/bus/usb/device/.../wusb_cdid
 35Date:		July 2008
 36KernelVersion:	2.6.27
 37Contact:	David Vrabel <david.vrabel@csr.com>
 38Description:
 39		For Certified Wireless USB devices only.
 40
 41		A devices's CDID, as 16 space-separated hex octets.
 42
 43What:		/sys/bus/usb/device/.../wusb_ck
 44Date:		July 2008
 45KernelVersion:	2.6.27
 46Contact:	David Vrabel <david.vrabel@csr.com>
 47Description:
 48		For Certified Wireless USB devices only.
 49
 50		Write the device's connection key (CK) to start the
 51		authentication of the device.  The CK is 16
 52		space-separated hex octets.
 53
 54What:		/sys/bus/usb/device/.../wusb_disconnect
 55Date:		July 2008
 56KernelVersion:	2.6.27
 57Contact:	David Vrabel <david.vrabel@csr.com>
 58Description:
 59		For Certified Wireless USB devices only.
 60
 61		Write a 1 to force the device to disconnect
 62		(equivalent to unplugging a wired USB device).
 63
 64What:		/sys/bus/usb/drivers/.../new_id
 65Date:		October 2011
 66Contact:	linux-usb@vger.kernel.org
 67Description:
 68		Writing a device ID to this file will attempt to
 69		dynamically add a new device ID to a USB device driver.
 70		This may allow the driver to support more hardware than
 71		was included in the driver's static device ID support
 72		table at compile time. The format for the device ID is:
 73		idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct
 74		The vendor ID and device ID fields are required, the
 75		rest is optional. The Ref* tuple can be used to tell the
 76		driver to use the same driver_data for the new device as
 77		it is used for the reference device.
 78		Upon successfully adding an ID, the driver will probe
 79		for the device and attempt to bind to it.  For example:
 80		# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
 81
 82		Here add a new device (0458:7045) using driver_data from
 83		an already supported device (0458:704c):
 84		# echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id
 85
 86		Reading from this file will list all dynamically added
 87		device IDs in the same format, with one entry per
 88		line. For example:
 89		# cat /sys/bus/usb/drivers/foo/new_id
 90		8086 10f5
 91		dead beef 06
 92		f00d cafe
 93
 94		The list will be truncated at PAGE_SIZE bytes due to
 95		sysfs restrictions.
 96
 97What:		/sys/bus/usb-serial/drivers/.../new_id
 98Date:		October 2011
 99Contact:	linux-usb@vger.kernel.org
100Description:
101		For serial USB drivers, this attribute appears under the
102		extra bus folder "usb-serial" in sysfs; apart from that
103		difference, all descriptions from the entry
104		"/sys/bus/usb/drivers/.../new_id" apply.
105
106What:		/sys/bus/usb/drivers/.../remove_id
107Date:		November 2009
108Contact:	CHENG Renquan <rqcheng@smu.edu.sg>
109Description:
110		Writing a device ID to this file will remove an ID
111		that was dynamically added via the new_id sysfs entry.
112		The format for the device ID is:
113		idVendor idProduct.	After successfully
114		removing an ID, the driver will no longer support the
115		device.  This is useful to ensure auto probing won't
116		match the driver to the device.  For example:
117		# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
118
119		Reading from this file will list the dynamically added
120		device IDs, exactly like reading from the entry
121		"/sys/bus/usb/drivers/.../new_id"
122
123What:		/sys/bus/usb/devices/.../power/usb2_hardware_lpm
124Date:		September 2011
125Contact:	Andiry Xu <andiry.xu@amd.com>
126Description:
127		If CONFIG_PM is set and a USB 2.0 lpm-capable device is plugged
128		in to a xHCI host which support link PM, it will perform a LPM
129		test; if the test is passed and host supports USB2 hardware LPM
130		(xHCI 1.0 feature), USB2 hardware LPM will be enabled for the
131		device and the USB device directory will contain a file named
132		power/usb2_hardware_lpm.  The file holds a string value (enable
133		or disable) indicating whether or not USB2 hardware LPM is
134		enabled for the device. Developer can write y/Y/1 or n/N/0 to
135		the file to enable/disable the feature.
136
137What:		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u1
138		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u2
139Date:		November 2015
140Contact:	Kevin Strasser <kevin.strasser@linux.intel.com>
141		Lu Baolu <baolu.lu@linux.intel.com>
142Description:
143		If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
144		in to a xHCI host which supports link PM, it will check if U1
145		and U2 exit latencies have been set in the BOS descriptor; if
146		the check is passed and the host supports USB3 hardware LPM,
147		USB3 hardware LPM will be enabled for the device and the USB
148		device directory will contain two files named
149		power/usb3_hardware_lpm_u1 and power/usb3_hardware_lpm_u2. These
150		files hold a string value (enable or disable) indicating whether
151		or not USB3 hardware LPM U1 or U2 is enabled for the device.
152
153What:		/sys/bus/usb/devices/.../removable
154Date:		February 2012
155Contact:	Matthew Garrett <mjg@redhat.com>
156Description:
157		Some information about whether a given USB device is
158		physically fixed to the platform can be inferred from a
159		combination of hub descriptor bits and platform-specific data
160		such as ACPI. This file will read either "removable" or
161		"fixed" if the information is available, and "unknown"
162		otherwise.
163
164What:		/sys/bus/usb/devices/.../ltm_capable
165Date:		July 2012
166Contact:	Sarah Sharp <sarah.a.sharp@linux.intel.com>
167Description:
168		USB 3.0 devices may optionally support Latency Tolerance
169		Messaging (LTM).  They indicate their support by setting a bit
170		in the bmAttributes field of their SuperSpeed BOS descriptors.
171		If that bit is set for the device, ltm_capable will read "yes".
172		If the device doesn't support LTM, the file will read "no".
173		The file will be present for all speeds of USB devices, and will
174		always read "no" for USB 1.1 and USB 2.0 devices.
175
176What:		/sys/bus/usb/devices/.../(hub interface)/portX
177Date:		August 2012
178Contact:	Lan Tianyu <tianyu.lan@intel.com>
179Description:
180		The /sys/bus/usb/devices/.../(hub interface)/portX
181		is usb port device's sysfs directory.
182
183What:		/sys/bus/usb/devices/.../(hub interface)/portX/connect_type
184Date:		January 2013
185Contact:	Lan Tianyu <tianyu.lan@intel.com>
186Description:
187		Some platforms provide usb port connect types through ACPI.
188		This attribute is to expose these information to user space.
189		The file will read "hotplug", "hardwired" and "not used" if the
190		information is available, and "unknown" otherwise.
191
192What:		/sys/bus/usb/devices/.../(hub interface)/portX/location
193Date:		October 2018
194Contact:	Bjørn Mork <bjorn@mork.no>
195Description:
196		Some platforms provide usb port physical location through
197		firmware. This is used by the kernel to pair up logical ports
198		mapping to the same physical connector. The attribute exposes the
199		raw location value as a hex integer.
200
201
202What:		/sys/bus/usb/devices/.../(hub interface)/portX/quirks
203Date:		May 2018
204Contact:	Nicolas Boichat <drinkcat@chromium.org>
205Description:
206		In some cases, we care about time-to-active for devices
207		connected on a specific port (e.g. non-standard USB port like
208		pogo pins), where the device to be connected is known in
209		advance, and behaves well according to the specification.
210		This attribute is a bit-field that controls the behavior of
211		a specific port:
212		 - Bit 0 of this field selects the "old" enumeration scheme,
213		   as it is considerably faster (it only causes one USB reset
214		   instead of 2).
215		   The old enumeration scheme can also be selected globally
216		   using /sys/module/usbcore/parameters/old_scheme_first, but
217		   it is often not desirable as the new scheme was introduced to
218		   increase compatibility with more devices.
219		 - Bit 1 reduces TRSTRCY to the 10 ms that are required by the
220		   USB 2.0 specification, instead of the 50 ms that are normally
221		   used to help make enumeration work better on some high speed
222		   devices.
223
224What:		/sys/bus/usb/devices/.../(hub interface)/portX/over_current_count
225Date:		February 2018
226Contact:	Richard Leitner <richard.leitner@skidata.com>
227Description:
228		Most hubs are able to detect over-current situations on their
229		ports and report them to the kernel. This attribute is to expose
230		the number of over-current situation occurred on a specific port
231		to user space. This file will contain an unsigned 32 bit value
232		which wraps to 0 after its maximum is reached. This file supports
233		poll() for monitoring changes to this value in user space.
234
235		Any time this value changes the corresponding hub device will send a
236		udev event with the following attributes:
237
238		OVER_CURRENT_PORT=/sys/bus/usb/devices/.../(hub interface)/portX
239		OVER_CURRENT_COUNT=[current value of this sysfs attribute]
240
241What:		/sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit
242Date:		November 2015
243Contact:	Lu Baolu <baolu.lu@linux.intel.com>
244Description:
245		Some USB3.0 devices are not friendly to USB3 LPM.  usb3_lpm_permit
246		attribute allows enabling/disabling usb3 lpm of a port. It takes
247		effect both before and after a usb device is enumerated. Supported
248		values are "0" if both u1 and u2 are NOT permitted, "u1" if only u1
249		is permitted, "u2" if only u2 is permitted, "u1_u2" if both u1 and
250		u2 are permitted.
251
252What:		/sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
253Date:		May 2013
254Contact:	Mathias Nyman <mathias.nyman@linux.intel.com>
255Description:
256		USB 2.0 devices may support hardware link power management (LPM)
257		L1 sleep state. The usb2_lpm_l1_timeout attribute allows
258		tuning the timeout for L1 inactivity timer (LPM timer), e.g.
259		needed inactivity time before host requests the device to go to L1 sleep.
260		Useful for power management tuning.
261		Supported values are 0 - 65535 microseconds.
262
263What:		/sys/bus/usb/devices/.../power/usb2_lpm_besl
264Date:		May 2013
265Contact:	Mathias Nyman <mathias.nyman@linux.intel.com>
266Description:
267		USB 2.0 devices that support hardware link power management (LPM)
268		L1 sleep state now use a best effort service latency value (BESL) to
269		indicate the best effort to resumption of service to the device after the
270		initiation of the resume event.
271		If the device does not have a preferred besl value then the host can select
272		one instead. This usb2_lpm_besl attribute allows to tune the host selected besl
273		value in order to tune power saving and service latency.
274
275		Supported values are 0 - 15.
276		More information on how besl values map to microseconds can be found in
277		USB 2.0 ECN Errata for Link Power Management, section 4.10)
278
279What:		/sys/bus/usb/devices/.../rx_lanes
280Date:		March 2018
281Contact:	Mathias Nyman <mathias.nyman@linux.intel.com>
282Description:
283		Number of rx lanes the device is using.
284		USB 3.2 adds Dual-lane support, 2 rx and 2 tx lanes over Type-C.
285		Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
286		direction. Devices before USB 3.2 are single lane (rx_lanes = 1)
287
288What:		/sys/bus/usb/devices/.../tx_lanes
289Date:		March 2018
290Contact:	Mathias Nyman <mathias.nyman@linux.intel.com>
291Description:
292		Number of tx lanes the device is using.
293		USB 3.2 adds Dual-lane support, 2 rx and 2 tx -lanes over Type-C.
294		Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
295		direction. Devices before USB 3.2 are single lane (tx_lanes = 1)