code:
What:		/sys/bus/usb/devices/<INTERFACE>/authorized
Date:		August 2015
Description:
		This allows to authorize (1) or deauthorize (0)
		individual interfaces instead a whole device
		in contrast to the device authorization.
		If a deauthorized interface will be authorized
		so the driver probing must be triggered manually
		by writing INTERFACE to /sys/bus/usb/drivers_probe
		This allows to avoid side-effects with drivers
		that need multiple interfaces.

		A deauthorized interface cannot be probed or claimed.

What:		/sys/bus/usb/devices/usbX/interface_authorized_default
Date:		August 2015
Description:
		This is used as value that determines if interfaces
		would be authorized by default.
		The value can be 1 or 0. It's by default 1.

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_u1
		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u2
Date:		November 2015
Contact:	Kevin Strasser <kevin.strasser@linux.intel.com>
		Lu Baolu <baolu.lu@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 passed and the host supports USB3 hardware LPM,
		USB3 hardware LPM will be enabled for the device and the USB
		device directory will contain two files named
		power/usb3_hardware_lpm_u1 and power/usb3_hardware_lpm_u2. These
		files hold a string value (enable or disable) indicating whether
		or not USB3 hardware LPM U1 or U2 is enabled for the device.

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>/port<X>
Date:		August 2012
Contact:	Lan Tianyu <tianyu.lan@intel.com>
Description:
		The /sys/bus/usb/devices/.../<hub_interface>/port<X>
		is usb port device's sysfs directory.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/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", "hardwired" and "not used" if the
		information is available, and "unknown" otherwise.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/location
Date:		October 2018
Contact:	Bjørn Mork <bjorn@mork.no>
Description:
		Some platforms provide usb port physical location through
		firmware. This is used by the kernel to pair up logical ports
		mapping to the same physical connector. The attribute exposes the
		raw location value as a hex integer.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/quirks
Date:		May 2018
Contact:	Nicolas Boichat <drinkcat@chromium.org>
Description:
		In some cases, we care about time-to-active for devices
		connected on a specific port (e.g. non-standard USB port like
		pogo pins), where the device to be connected is known in
		advance, and behaves well according to the specification.
		This attribute is a bit-field that controls the behavior of
		a specific port:

		 - Bit 0 of this field selects the "old" enumeration scheme,
		   as it is considerably faster (it only causes one USB reset
		   instead of 2).

		   The old enumeration scheme can also be selected globally
		   using /sys/module/usbcore/parameters/old_scheme_first, but
		   it is often not desirable as the new scheme was introduced to
		   increase compatibility with more devices.
		 - Bit 1 reduces TRSTRCY to the 10 ms that are required by the
		   USB 2.0 specification, instead of the 50 ms that are normally
		   used to help make enumeration work better on some high speed
		   devices.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/over_current_count
Date:		February 2018
Contact:	Richard Leitner <richard.leitner@skidata.com>
Description:
		Most hubs are able to detect over-current situations on their
		ports and report them to the kernel. This attribute is to expose
		the number of over-current situation occurred on a specific port
		to user space. This file will contain an unsigned 32 bit value
		which wraps to 0 after its maximum is reached. This file supports
		poll() for monitoring changes to this value in user space.

		Any time this value changes the corresponding hub device will send a
		udev event with the following attributes::

		  OVER_CURRENT_PORT=/sys/bus/usb/devices/.../<hub_interface>/port<X>
		  OVER_CURRENT_COUNT=[current value of this sysfs attribute]

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/usb3_lpm_permit
Date:		November 2015
Contact:	Lu Baolu <baolu.lu@linux.intel.com>
Description:
		Some USB3.0 devices are not friendly to USB3 LPM.  usb3_lpm_permit
		attribute allows enabling/disabling usb3 lpm of a port. It takes
		effect both before and after a usb device is enumerated. Supported
		values are "0" if both u1 and u2 are NOT permitted, "u1" if only u1
		is permitted, "u2" if only u2 is permitted, "u1_u2" if both u1 and
		u2 are permitted.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/connector
Date:		December 2021
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Link to the USB Type-C connector when available. This link is
		only created when USB Type-C Connector Class is enabled, and
		only if the system firmware is capable of describing the
		connection between a port and its connector.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/disable
Date:		June 2022
Contact:	Michael Grzeschik <m.grzeschik@pengutronix.de>
Description:
		This file controls the state of a USB port, including
		Vbus power output (but only on hubs that support
		power switching -- most hubs don't support it). If
		a port is disabled, the port is unusable: Devices
		attached to the port will not be detected, initialized,
		or enumerated.

What:		/sys/bus/usb/devices/.../<hub_interface>/port<X>/early_stop
Date:		Sep 2022
Contact:	Ray Chi <raychi@google.com>
Description:
		Some USB hosts have some watchdog mechanisms so that the device
		may enter ramdump if it takes a long time during port initialization.
		This attribute allows each port just has two attempts so that the
		port initialization will be failed quickly. In addition, if a port
		which is marked with early_stop has failed to initialize, it will ignore
		all future connections until this attribute is clear.

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)

What:		/sys/bus/usb/devices/.../rx_lanes
Date:		March 2018
Contact:	Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
		Number of rx lanes the device is using.
		USB 3.2 adds Dual-lane support, 2 rx and 2 tx lanes over Type-C.
		Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
		direction. Devices before USB 3.2 are single lane (rx_lanes = 1)

What:		/sys/bus/usb/devices/.../tx_lanes
Date:		March 2018
Contact:	Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
		Number of tx lanes the device is using.
		USB 3.2 adds Dual-lane support, 2 rx and 2 tx -lanes over Type-C.
		Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
		direction. Devices before USB 3.2 are single lane (tx_lanes = 1)

What:		/sys/bus/usb/devices/usbX/bAlternateSetting
Description:
		The current interface alternate setting number, in decimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bcdDevice
Description:
		The device's release number, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bConfigurationValue
Description:
		While a USB device typically have just one configuration
		setting, some devices support multiple configurations.

		This value shows the current configuration, in decimal.

		Changing its value will change the device's configuration
		to another setting.

		The number of configurations supported by a device is at:

			/sys/bus/usb/devices/usbX/bNumConfigurations

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bDeviceClass
Description:
		Class code of the device, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bDeviceProtocol
Description:
		Protocol code of the device, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bDeviceSubClass
Description:
		Subclass code of the device, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bInterfaceClass
Description:
		Class code of the interface, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bInterfaceNumber
Description:
		Interface number, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bInterfaceProtocol
Description:
		Protocol code of the interface, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bInterfaceSubClass
Description:
		Subclass code of the interface, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bmAttributes
Description:
		Attributes of the current configuration, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bMaxPacketSize0
Description:
		Maximum endpoint 0 packet size, in decimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bMaxPower
Description:
		Maximum power consumption of the active configuration of
		the device, in miliamperes.

What:		/sys/bus/usb/devices/usbX/bNumConfigurations
Description:
		Number of the possible configurations of the device, in
		decimal. The current configuration is controlled via:

			/sys/bus/usb/devices/usbX/bConfigurationValue

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bNumEndpoints
Description:
		Number of endpoints used on this interface, in hexadecimal.

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/bNumInterfaces
Description:
		Number of interfaces on this device, in decimal.

What:		/sys/bus/usb/devices/usbX/busnum
Description:
		Number of the bus.

What:		/sys/bus/usb/devices/usbX/configuration
Description:
		Contents of the string descriptor associated with the
		current configuration. It may include the firmware version
		of a device and/or its serial number.

What:		/sys/bus/usb/devices/usbX/descriptors
Description:
		Contains the interface descriptors, in binary.

What:		/sys/bus/usb/devices/usbX/idProduct
Description:
		Product ID, in hexadecimal.

What:		/sys/bus/usb/devices/usbX/idVendor
Description:
		Vendor ID, in hexadecimal.

What:		/sys/bus/usb/devices/usbX/devspec
Description:
		Displays the Device Tree Open Firmware node of the interface.

What:		/sys/bus/usb/devices/usbX/avoid_reset_quirk
Description:
		Most devices have this set to zero.

		If the value is 1, enable a USB quirk that prevents this
		device to use reset.

		(read/write)

What:		/sys/bus/usb/devices/usbX/devnum
Description:
		USB interface device number, in decimal.

What:		/sys/bus/usb/devices/usbX/devpath
Description:
		String containing the USB interface device path.

What:		/sys/bus/usb/devices/usbX/manufacturer
Description:
		Vendor specific string containing the name of the
		manufacturer of the device.

What:		/sys/bus/usb/devices/usbX/maxchild
Description:
		Number of ports of an USB hub

What:		/sys/bus/usb/devices/usbX/persist
Description:
		Keeps the device even if it gets disconnected.

What:		/sys/bus/usb/devices/usbX/product
Description:
		Vendor specific string containing the name of the
		device's product.

What:		/sys/bus/usb/devices/usbX/speed
Description:
		Shows the device's max speed, according to the USB version,
		in Mbps.
		Can be:

			=======		====================
			Unknown		speed unknown
			1.5		Low speed
			15		Full speed
			480		High Speed
			5000		Super Speed
			10000		Super Speed+
			20000		Super Speed+ Gen 2x2
			=======		====================

What:		/sys/bus/usb/devices/usbX/supports_autosuspend
Description:
		Returns 1 if the device doesn't support autosuspend.
		Otherwise, returns 0.

What:		/sys/bus/usb/devices/usbX/urbnum
Description:
		Number of URBs submitted for the whole device.

What:		/sys/bus/usb/devices/usbX/version
Description:
		String containing the USB device version, as encoded
		at the BCD descriptor.

What:		/sys/bus/usb/devices/usbX/power/autosuspend
Description:
		Time in milliseconds for the device to autosuspend. If the
		value is negative, then autosuspend is prevented.

		(read/write)

What:		/sys/bus/usb/devices/usbX/power/active_duration
Description:
		The total time the device has not been suspended.

What:		/sys/bus/usb/devices/usbX/power/connected_duration
Description:
		The total time (in msec) that the device has been connected.

What:		/sys/bus/usb/devices/usbX/power/level
Description:

What:		/sys/bus/usb/devices/usbX/ep_<N>/bEndpointAddress
Description:
		The address of the endpoint described by this descriptor,
		in hexadecimal. The endpoint direction on this bitmapped field
		is also shown at:

			/sys/bus/usb/devices/usbX/ep_<N>/direction

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/ep_<N>/bInterval
Description:
		The interval of the endpoint as described on its descriptor,
		in hexadecimal. The actual interval depends on the version
		of the USB. Also shown in time units at
		/sys/bus/usb/devices/usbX/ep_<N>/interval.

What:		/sys/bus/usb/devices/usbX/ep_<N>/bLength
Description:
		Number of bytes of the endpoint descriptor, in hexadecimal.

What:		/sys/bus/usb/devices/usbX/ep_<N>/bmAttributes
Description:
		Attributes which apply to the endpoint as described on its
		descriptor, in hexadecimal. The endpoint type on this
		bitmapped field is also shown at:

			/sys/bus/usb/devices/usbX/ep_<N>/type

		See USB specs for its meaning.

What:		/sys/bus/usb/devices/usbX/ep_<N>/direction
Description:
		Direction of the endpoint. Can be:

		    - both (on control endpoints)
		    - in
		    - out

What:		/sys/bus/usb/devices/usbX/ep_<N>/interval
Description:
		Interval for polling endpoint for data transfers, in
		milisseconds or microseconds.

What:		/sys/bus/usb/devices/usbX/ep_<N>/type
Description:
		Descriptor type. Can be:

		    - Control
		    - Isoc
		    - Bulk
		    - Interrupt
		    - unknown

What:		/sys/bus/usb/devices/usbX/ep_<N>/wMaxPacketSize
Description:
		Maximum packet size this endpoint is capable of
		sending or receiving, in hexadecimal.

path: Documentation/ABI/testing/sysfs-bus-usb


code:
What:		/sys/bus/usb/.../powered
Date:		August 2008
KernelVersion:	2.6.26
Contact:	Harrison Metzger <harrisonmetz@gmail.com>
Description:	Controls whether the device's display will powered.
		A value of 0 is off and a non-zero value is on.

What:		/sys/bus/usb/.../mode_msb
What:		/sys/bus/usb/.../mode_lsb
Date:		August 2008
KernelVersion:	2.6.26
Contact:	Harrison Metzger <harrisonmetz@gmail.com>
Description:	Controls the devices display mode.
		For a 6 character display the values are

			MSB 0x06; LSB 0x3F, and

		for an 8 character display the values are

			MSB 0x08; LSB 0xFF.

What:		/sys/bus/usb/.../textmode
Date:		August 2008
KernelVersion:	2.6.26
Contact:	Harrison Metzger <harrisonmetz@gmail.com>
Description:	Controls the way the device interprets its text buffer.
		raw:	each character controls its segment manually
		hex:	each character is between 0-15
		ascii:	each character is between '0'-'9' and 'A'-'F'.

What:		/sys/bus/usb/.../text
Date:		August 2008
KernelVersion:	2.6.26
Contact:	Harrison Metzger <harrisonmetz@gmail.com>
Description:	The text (or data) for the device to display

What:		/sys/bus/usb/.../decimals
Date:		August 2008
KernelVersion:	2.6.26
Contact:	Harrison Metzger <harrisonmetz@gmail.com>
Description:	Controls the decimal places on the device.
		To set the nth decimal place, give this field
		the value of ``10 ** n``. Assume this field has
		the value k and has 1 or more decimal places set,
		to set the mth place (where m is not already set),
		change this fields value to ``k + 10 ** m``.

repo_name: angery/linux


code:
Link Layer Validation Device is a standard device for testing of Super
Speed Link Layer tests. These nodes are available in sysfs only when lvs
driver is bound with root hub device.

What:		/sys/bus/usb/devices/.../get_dev_desc
Date:		March 2014
Contact:	Pratyush Anand <pratyush.anand@gmail.com>
Description:
		Write to this node to issue "Get Device Descriptor"
		for Link Layer Validation device. It is needed for TD.7.06.

What:		/sys/bus/usb/devices/.../u1_timeout
Date:		March 2014
Contact:	Pratyush Anand <pratyush.anand@gmail.com>
Description:
		Set "U1 timeout" for the downstream port where Link Layer
		Validation device is connected. Timeout value must be between 0
		and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.

What:		/sys/bus/usb/devices/.../u2_timeout
Date:		March 2014
Contact:	Pratyush Anand <pratyush.anand@gmail.com>
Description:
		Set "U2 timeout" for the downstream port where Link Layer
		Validation device is connected. Timeout value must be between 0
		and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.

What:		/sys/bus/usb/devices/.../hot_reset
Date:		March 2014
Contact:	Pratyush Anand <pratyush.anand@gmail.com>
Description:
		Write to this node to issue "Reset" for Link Layer Validation
		device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.

What:		/sys/bus/usb/devices/.../u3_entry
Date:		March 2014
Contact:	Pratyush Anand <pratyush.anand@gmail.com>
Description:
		Write to this node to issue "U3 entry" for Link Layer
		Validation device. It is needed for TD.7.35 and TD.7.36.

What:		/sys/bus/usb/devices/.../u3_exit
Date:		March 2014
Contact:	Pratyush Anand <pratyush.anand@gmail.com>
Description:
		Write to this node to issue "U3 exit" for Link Layer
		Validation device. It is needed for TD.7.36.

What:		/sys/bus/usb/devices/.../enable_compliance
Date:		July 2017
Description:
		Write to this node to set the port to compliance mode to test
		with Link Layer Validation device. It is needed for TD.7.34.

What:		/sys/bus/usb/devices/.../warm_reset
Date:		July 2017
Description:
		Write to this node to issue "Warm Reset" for Link Layer Validation
		device. It may be needed to properly reset an xHCI 1.1 host port if
		compliance mode needed to be explicitly enabled.


code:
What:		/sys/bus/vdpa/driver_autoprobe
Date:		March 2020
Contact:	virtualization@lists.linux-foundation.org
Description:
		This file determines whether new devices are immediately bound
		to a driver after the creation. It initially contains 1, which
		means the kernel automatically binds devices to a compatible
		driver immediately after they are created.

		Writing "0" to this file disable this feature, any other string
		enable it.

What:		/sys/bus/vdpa/driver_probe
Date:		March 2020
Contact:	virtualization@lists.linux-foundation.org
Description:
		Writing a device name to this file will cause the kernel binds
		devices to a compatible driver.

		This can be useful when /sys/bus/vdpa/driver_autoprobe is
		disabled.

What:		/sys/bus/vdpa/drivers/.../bind
Date:		March 2020
Contact:	virtualization@lists.linux-foundation.org
Description:
		Writing a device name to this file will cause the driver to
		attempt to bind to the device. This is useful for overriding
		default bindings.

What:		/sys/bus/vdpa/drivers/.../unbind
Date:		March 2020
Contact:	virtualization@lists.linux-foundation.org
Description:
		Writing a device name to this file will cause the driver to
		attempt to unbind from the device. This may be useful when
		overriding default bindings.

What:		/sys/bus/vdpa/devices/.../driver_override
Date:		November 2021
Contact:	virtualization@lists.linux-foundation.org
Description:
		This file allows the driver for a device to be specified.
		When specified, only a driver with a name matching the value
		written to driver_override will have an opportunity to bind to
		the device. The override is specified by writing a string to the
		driver_override file (echo vhost-vdpa > driver_override) and may
		be cleared with an empty string (echo > driver_override).
		This returns the device to standard matching rules binding.
		Writing to driver_override does not automatically unbind the
		device from its current driver or make any attempt to
		automatically load the specified driver. If no driver with a
		matching name is currently loaded in the kernel, the device will
		not bind to any driver. This also allows devices to opt-out of
		driver binding using a driver_override name such as "none".
		Only a single driver may be specified in the override, there is
		no support for parsing delimiters.


code:
What:           /sys/.../<device>/mdev_supported_types/
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
                This directory contains list of directories of currently
		supported mediated device types and their details for
		<device>. Supported type attributes are defined by the
		vendor driver who registers with Mediated device framework.
		Each supported type is a directory whose name is created
		by adding the device driver string as a prefix to the
		string provided by the vendor driver.

What:           /sys/.../<device>/mdev_supported_types/<type-id>/
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
                This directory gives details of supported type, like name,
		description, available_instances, device_api etc.
		'device_api' and 'available_instances' are mandatory
		attributes to be provided by vendor driver. 'name',
		'description' and other vendor driver specific attributes
		are optional.

What:           /sys/.../mdev_supported_types/<type-id>/create
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		Writing UUID to this file will create mediated device of
		type <type-id> for parent device <device>. This is a
		write-only file.
		For example::

		  # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" >	\
		       /sys/devices/foo/mdev_supported_types/foo-1/create

What:           /sys/.../mdev_supported_types/<type-id>/devices/
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		This directory contains symbolic links pointing to mdev
		devices sysfs entries which are created of this <type-id>.

What:           /sys/.../mdev_supported_types/<type-id>/available_instances
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		Reading this attribute will show the number of mediated
		devices of type <type-id> that can be created. This is a
		readonly file.
Users:
		Userspace applications interested in creating mediated
		device of that type. Userspace application should check
		the number of available instances could be created before
		creating mediated device of this type.

What:           /sys/.../mdev_supported_types/<type-id>/device_api
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		Reading this attribute will show VFIO device API supported
		by this type. For example, "vfio-pci" for a PCI device,
		"vfio-platform" for platform device.

What:           /sys/.../mdev_supported_types/<type-id>/name
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		Reading this attribute will show human readable name of the
		mediated device that will get created of type <type-id>.
		This is optional attribute. For example: "Grid M60-0Q"
Users:
		Userspace applications interested in knowing the name of
		a particular <type-id> that can help in understanding the
		type of mediated device.

What:           /sys/.../mdev_supported_types/<type-id>/description
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		Reading this attribute will show description of the type of
		mediated device that will get created of type <type-id>.
		This is optional attribute. For example:
		"2 heads, 512M FB, 2560x1600 maximum resolution"
Users:
		Userspace applications interested in knowing the details of
		a particular <type-id> that can help in understanding the
		features provided by that type of mediated device.

What:           /sys/.../<device>/<UUID>/
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		This directory represents device directory of mediated
		device. It contains all the attributes related to mediated
		device.

What:           /sys/.../<device>/<UUID>/mdev_type
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		This is symbolic link pointing to supported type, <type-id>
		directory of which this mediated device is created.

What:           /sys/.../<device>/<UUID>/remove
Date:           October 2016
Contact:        Kirti Wankhede <kwankhede@nvidia.com>
Description:
		Writing '1' to this file destroys the mediated device. The
		vendor driver can fail the remove() callback if that device
		is active and the vendor driver doesn't support hot unplug.
		Example::

		  # echo 1 > /sys/bus/mdev/devices/<UUID>/remove


code:
What:		/sys/bus/vmbus/devices/.../driver_override
Date:		August 2019
Contact:	Stephen Hemminger <sthemmin@microsoft.com>
Description:
		This file allows the driver for a device to be specified which
		will override standard static and dynamic ID matching.  When
		specified, only a driver with a name matching the value written
		to driver_override will have an opportunity to bind to the
		device.  The override is specified by writing a string to the
		driver_override file (echo uio_hv_generic > driver_override) and
		may be cleared with an empty string (echo > driver_override).
		This returns the device to standard matching rules binding.
		Writing to driver_override does not automatically unbind the
		device from its current driver or make any attempt to
		automatically load the specified driver.  If no driver with a
		matching name is currently loaded in the kernel, the device
		will not bind to any driver.  This also allows devices to
		opt-out of driver binding using a driver_override name such as
		"none".  Only a single driver may be specified in the override,
		there is no support for parsing delimiters.


code:
What:		/sys/class/c2port/
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/ directory will contain files and
		directories that will provide a unified interface to
		the C2 port interface.

What:		/sys/class/c2port/c2portX
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/ directory is related to X-th
		C2 port into the system. Each directory will contain files to
		manage and control its C2 port.

What:		/sys/class/c2port/c2portX/access
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/access file enable the access
		to the C2 port from the system. No commands can be sent
		till this entry is set to 0.

What:		/sys/class/c2port/c2portX/dev_id
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/dev_id file show the device ID
		of the connected micro.

What:		/sys/class/c2port/c2portX/flash_access
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/flash_access file enable the
		access to the on-board flash of the connected micro.
		No commands can be sent till this entry is set to 0.

What:		/sys/class/c2port/c2portX/flash_block_size
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/flash_block_size file show
		the on-board flash block size of the connected micro.

What:		/sys/class/c2port/c2portX/flash_blocks_num
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/flash_blocks_num file show
		the on-board flash blocks number of the connected micro.

What:		/sys/class/c2port/c2portX/flash_data
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/flash_data file export
		the content of the on-board flash of the connected micro.

What:		/sys/class/c2port/c2portX/flash_erase
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/flash_erase file execute
		the "erase" command on the on-board flash of the connected
		micro.

What:		/sys/class/c2port/c2portX/reset
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/reset file execute a "reset"
		command on the connected micro.

What:		/sys/class/c2port/c2portX/rev_id
Date:		October 2008
Contact:	Rodolfo Giometti <giometti@linux.it>
Description:
		The /sys/class/c2port/c2portX/rev_id file show the revision ID
		of the connected micro.


code:
What:		/sys/block/<device>/iosched/target_latency
Date:		March 2012
contact:	Tao Ma <boyu.mt@taobao.com>
Description:
		The /sys/block/<device>/iosched/target_latency only exists
		when the user sets cfq to /sys/block/<device>/scheduler.
		It contains an estimated latency time for the cfq. cfq will
		use it to calculate the time slice used for every task.


code:
What:		/sys/class/
Date:		Febuary 2006
Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
		The /sys/class directory will consist of a group of
		subdirectories describing individual classes of devices
		in the kernel.  The individual directories will consist
		of either subdirectories, or symlinks to other
		directories.

		All programs that use this directory tree must be able
		to handle both subdirectories or symlinks in order to
		work properly.

Users:
	udev <linux-hotplug-devel@lists.sourceforge.net>

path: Documentation/ABI/testing/sysfs-class


code:
What:		/sys/class/backlight/<backlight>/scale
Date:		July 2019
KernelVersion:	5.4
Contact:	Daniel Thompson <daniel.thompson@linaro.org>
Description:
		Description of the scale of the brightness curve.

		The human eye senses brightness approximately logarithmically,
		hence linear changes in brightness are perceived as being
		non-linear. To achieve a linear perception of brightness changes
		controls like sliders need to apply a logarithmic mapping for
		backlights with a linear brightness curve.

		Possible values of the attribute are:

		unknown
		  The scale of the brightness curve is unknown.

		linear
		  The brightness changes linearly with each step. Brightness
		  controls should apply a logarithmic mapping for a linear
		  perception.

		non-linear
		  The brightness changes non-linearly with each step. Brightness
		  controls should use a linear mapping for a linear perception.

What:		/sys/class/backlight/<backlight>/ambient_light_level
Date:		Apr, 2010
KernelVersion:	v2.6.35
Contact:	Michael Hennerich <michael.hennerich@analog.com>
Description:
		(RO) Get conversion value of the light sensor.

		The value is automatically updated every 80 ms when the
		light sensor is enabled.

		The value range is device-driver specific:

		For ADP8870:

		  It returns integer between 0 (dark) and 8000 (max ambient
		  brightness).

		For ADP8860:

		  It returns a 13-bits integer.

What:		/sys/class/backlight/<backlight>/ambient_light_zone
Date:		Apr, 2010
KernelVersion:	v2.6.35
Contact:	Michael Hennerich <michael.hennerich@analog.com>,
		device-drivers-devel@blackfin.uclinux.org

Description:
		(RW) Read or write the specific brightness level at which the
		backlight operates.

		The value meaning is device-driver specific:

		For ADP8860:

		  ==	==========================
		   0	Off: Backlight set to 0 mA
		   1	Level 1: daylight
		   2	Level 2: bright
		   3	Level 3: dark
		  ==	==========================

		For ADP8870:

		  ==	==========================
		   0	Off: Backlight set to 0 mA
		   1	Level 1: daylight
		   2	Level 2: bright
		   3	Level 3: office
		   4	Level 4: indoor
		   5	Level 5: dark
		  ==	==========================

		Writing 0 returns to normal/automatic ambient light level
		operation.

		It can be enabled by writing the value stored in
		/sys/class/backlight/<backlight>/max_brightness to
		/sys/class/backlight/<backlight>/brightness.

What:		/sys/class/backlight/<backlight>/<ambient light zone>_max
Date:		Sep, 2009
KernelVersion:	v2.6.32
Contact:	device-drivers-devel@blackfin.uclinux.org
Description:
		Control the maximum brightness for <ambient light zone>
		on this <backlight>. Values are between 0 and 127. This file
		will also show the brightness level stored for this
		<ambient light zone>.

		The <ambient light zone> is device-driver specific:

		For ADP5520 and ADP5501, <ambient light zone> can be:

		===========  ================================================
		Ambient      sysfs entry
		light zone
		===========  ================================================
		daylight     /sys/class/backlight/<backlight>/daylight_max
		office       /sys/class/backlight/<backlight>/office_max
		dark         /sys/class/backlight/<backlight>/dark_max
		===========  ================================================

		For ADP8860, <ambient light zone> can be:

		===========  ================================================
		Ambient      sysfs entry
		light zone
		===========  ================================================
		l1_daylight  /sys/class/backlight/<backlight>/l1_daylight_max
		l2_office    /sys/class/backlight/<backlight>/l2_office_max
		l3_dark      /sys/class/backlight/<backlight>/l3_dark_max
		===========  ================================================

		For ADP8870, <ambient light zone> can be:

		===========  ================================================
		Ambient      sysfs entry
		light zone
		===========  ================================================
		l1_daylight  /sys/class/backlight/<backlight>/l1_daylight_max
		l2_bright    /sys/class/backlight/<backlight>/l2_bright_max
		l3_office    /sys/class/backlight/<backlight>/l3_office_max
		l4_indoor    /sys/class/backlight/<backlight>/l4_indoor_max
		l5_dark      /sys/class/backlight/<backlight>/l5_dark_max
		===========  ================================================

		See also: /sys/class/backlight/<backlight>/ambient_light_zone.

What:		/sys/class/backlight/<backlight>/<ambient light zone>_dim
Date:		Sep, 2009
KernelVersion:	v2.6.32
Contact:	device-drivers-devel@blackfin.uclinux.org
Description:
		Control the dim brightness for <ambient light zone>
		on this <backlight>. Values are between 0 and 127, typically
		set to 0. Full off when the backlight is disabled.
		This file will also show the dim brightness level stored for
		this <ambient light zone>.

		The <ambient light zone> is device-driver specific:

		For ADP5520 and ADP5501, <ambient light zone> can be:

		===========  ================================================
		Ambient      sysfs entry
		light zone
		===========  ================================================
		daylight     /sys/class/backlight/<backlight>/daylight_dim
		office       /sys/class/backlight/<backlight>/office_dim
		dark         /sys/class/backlight/<backlight>/dark_dim
		===========  ================================================

		For ADP8860, <ambient light zone> can be:

		===========  ================================================
		Ambient      sysfs entry
		light zone
		===========  ================================================
		l1_daylight  /sys/class/backlight/<backlight>/l1_daylight_dim
		l2_office    /sys/class/backlight/<backlight>/l2_office_dim
		l3_dark      /sys/class/backlight/<backlight>/l3_dark_dim
		===========  ================================================

		For ADP8870, <ambient light zone> can be:

		===========  ================================================
		Ambient      sysfs entry
		light zone
		===========  ================================================
		l1_daylight  /sys/class/backlight/<backlight>/l1_daylight_dim
		l2_bright    /sys/class/backlight/<backlight>/l2_bright_dim
		l3_office    /sys/class/backlight/<backlight>/l3_office_dim
		l4_indoor    /sys/class/backlight/<backlight>/l4_indoor_dim
		l5_dark      /sys/class/backlight/<backlight>/l5_dark_dim
		===========  ================================================

		See also: /sys/class/backlight/<backlight>/ambient_light_zone.


code:
What:		/sys/class/backlight/<backlight>/als_channel
Date:		May 2012
KernelVersion:	3.5
Contact:	Johan Hovold <jhovold@gmail.com>
Description:
		Get the ALS output channel used as input in
		ALS-current-control mode (0, 1), where:

		==  ==========================
		0   out_current0 (backlight 0)
		1   out_current1 (backlight 1)
		==  ==========================

What:		/sys/class/backlight/<backlight>/als_en
Date:		May 2012
KernelVersion:	3.5
Contact:	Johan Hovold <jhovold@gmail.com>
Description:
		Enable ALS-current-control mode (0, 1).

What:		/sys/class/backlight/<backlight>/id
Date:		April 2012
KernelVersion:	3.5
Contact:	Johan Hovold <jhovold@gmail.com>
Description:
		Get the id of this backlight (0, 1).

What:		/sys/class/backlight/<backlight>/linear
Date:		April 2012
KernelVersion:	3.5
Contact:	Johan Hovold <jhovold@gmail.com>
Description:
		Set the brightness-mapping mode (0, 1), where:

		==  ================
		0   exponential mode
		1   linear mode
		==  ================

What:		/sys/class/backlight/<backlight>/pwm
Date:		April 2012
KernelVersion:	3.5
Contact:	Johan Hovold <jhovold@gmail.com>
Description:
		Set the PWM-input control mask (5 bits), where:

		=====   ===========================
		bit 5   PWM-input enabled in Zone 4
		bit 4   PWM-input enabled in Zone 3
		bit 3   PWM-input enabled in Zone 2
		bit 2   PWM-input enabled in Zone 1
		bit 1   PWM-input enabled in Zone 0
		bit 0   PWM-input enabled
		=====   ===========================


code:
sysfs interface for Texas Instruments lm3639 backlight + flash led driver chip
------------------------------------------------------------------------------

What:		/sys/class/backlight/<backlight>/bled_mode
Date:		Oct, 2012
KernelVersion:	v3.10
Contact:	dri-devel@lists.freedesktop.org
Description:
		(WO) Write to the backlight mapping mode. The backlight current
		can be mapped for either exponential (value "0") or linear
		mapping modes (default).


code:
What:		/sys/class/bdi/<bdi>/
Date:		January 2008
Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:

Provide a place in sysfs for the backing_dev_info object.  This allows
setting and retrieving various BDI specific variables.

The <bdi> identifier can be either of the following:

MAJOR:MINOR

	Device number for block devices, or value of st_dev on
	non-block filesystems which provide their own BDI, such as NFS
	and FUSE.

MAJOR:MINOR-fuseblk

	Value of st_dev on fuseblk filesystems.

default

	The default backing dev, used for non-block device backed
	filesystems which do not provide their own BDI.

What:		/sys/class/bdi/<bdi>/read_ahead_kb
Date:		January 2008
Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:
	Size of the read-ahead window in kilobytes

	(read-write)
What:		/sys/class/bdi/<bdi>/min_ratio
Date:		January 2008
Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:
	Under normal circumstances each device is given a part of the
	total write-back cache that relates to its current average
	writeout speed in relation to the other devices.

	The 'min_ratio' parameter allows assigning a minimum
	percentage of the write-back cache to a particular device.
	For example, this is useful for providing a minimum QoS.

	(read-write)

What:		/sys/class/bdi/<bdi>/min_ratio_fine
Date:		November 2022
Contact:	Stefan Roesch <shr@devkernel.io>
Description:
	Under normal circumstances each device is given a part of the
	total write-back cache that relates to its current average
	writeout speed in relation to the other devices.

	The 'min_ratio_fine' parameter allows assigning a minimum reserve
	of the write-back cache to a particular device. The value is
	expressed as part of 1 million. For example, this is useful for
	providing a minimum QoS.

	(read-write)

What:		/sys/class/bdi/<bdi>/max_ratio
Date:		January 2008
Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:
	Allows limiting a particular device to use not more than the
	given percentage of the write-back cache.  This is useful in
	situations where we want to avoid one device taking all or
	most of the write-back cache.  For example in case of an NFS
	mount that is prone to get stuck, or a FUSE mount which cannot
	be trusted to play fair.

	(read-write)

What:		/sys/class/bdi/<bdi>/max_ratio_fine
Date:		November 2022
Contact:	Stefan Roesch <shr@devkernel.io>
Description:
	Allows limiting a particular device to use not more than the
	given value of the write-back cache.  The value is given as part
	of 1 million. This is useful in situations where we want to avoid
	one device taking all or most of the write-back cache.  For example
	in case of an NFS mount that is prone to get stuck, or a FUSE mount
	which cannot be trusted to play fair.

	(read-write)

What:		/sys/class/bdi/<bdi>/min_bytes
Date:		October 2022
Contact:	Stefan Roesch <shr@devkernel.io>
Description:
	Under normal circumstances each device is given a part of the
	total write-back cache that relates to its current average
	writeout speed in relation to the other devices.

	The 'min_bytes' parameter allows assigning a minimum
	percentage of the write-back cache to a particular device
	expressed in bytes.
	For example, this is useful for providing a minimum QoS.

	(read-write)

What:		/sys/class/bdi/<bdi>/max_bytes
Date:		October 2022
Contact:	Stefan Roesch <shr@devkernel.io>
Description:
	Allows limiting a particular device to use not more than the
	given 'max_bytes' of the write-back cache.  This is useful in
	situations where we want to avoid one device taking all or
	most of the write-back cache.  For example in case of an NFS
	mount that is prone to get stuck, a FUSE mount which cannot be
	trusted to play fair, or a nbd device.

	(read-write)

What:		/sys/class/bdi/<bdi>/strict_limit
Date:		October 2022
Contact:	Stefan Roesch <shr@devkernel.io>
Description:
	Forces per-BDI checks for the share of given device in the write-back
	cache even before the global background dirty limit is reached. This
	is useful in situations where the global limit is much higher than
	affordable for given relatively slow (or untrusted) device. Turning
	strictlimit on has no visible effect if max_ratio is equal to 100%.

	(read-write)
What:		/sys/class/bdi/<bdi>/stable_pages_required
Date:		January 2008
Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:
	If set, the backing device requires that all pages comprising a write
	request must not be changed until writeout is complete.

	(read-only)


code:
What:		/sys/class/bsr/bsr*/bsr_size
Date:		Jul, 2008
KernelVersion:	2.6.27
Contact:	Arnd Bergmann <arnd@arndb.de>,
		Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
		(RO) Size of the barrier-synchronization register (BSR)
		register in bytes.

What:		/sys/class/bsr/bsr*/bsr_length
Date:		Jul, 2008
KernelVersion:	2.6.27
Contact:	Arnd Bergmann <arnd@arndb.de>,
		Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
		(RO) The length of memory region that can be mapped in bytes.

What:		/sys/class/bsr/bsr*/bsr_stride
Date:		Jul, 2008
KernelVersion:	2.6.27
Contact:	Arnd Bergmann <arnd@arndb.de>,
		Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
		(RO) The stride or the interval at which the allocated BSR bytes
		repeat within the mapping.


code:
What:		/sys/class/chromeos/<ec-device-name>/flashinfo
Date:		August 2015
KernelVersion:	4.2
Description:
		Show the EC flash information.

What:		/sys/class/chromeos/<ec-device-name>/kb_wake_angle
Date:		March 2018
KernelVersion:	4.17
Description:
		Control the keyboard wake lid angle. Values are between
		0 and 360. This file will also show the keyboard wake lid
		angle by querying the hardware.

What:		/sys/class/chromeos/<ec-device-name>/reboot
Date:		August 2015
KernelVersion:	4.2
Description:
		Tell the EC to reboot in various ways. Options are:

		- "cancel": Cancel a pending reboot.
		- "ro": Jump to RO without rebooting.
		- "rw": Jump to RW without rebooting.
		- "cold": Cold reboot.
		- "disable-jump": Disable jump until next reboot.
		- "hibernate": Hibernate the EC.
		- "at-shutdown": Reboot after an AP shutdown.

What:		/sys/class/chromeos/<ec-device-name>/version
Date:		August 2015
KernelVersion:	4.2
Description:
		Show the information about the EC software and hardware.


code:
What:		/sys/class/chromeos/<ec-device-name>/lightbar/brightness
Date:		August 2015
KernelVersion:	4.2
Description:
		Writing to this file adjusts the overall brightness of
		the lightbar, separate from any color intensity. The
		valid range is 0 (off) to 255 (maximum brightness).

What:		/sys/class/chromeos/<ec-device-name>/lightbar/interval_msec
Date:		August 2015
KernelVersion:	4.2
Description:
		The lightbar is controlled by an embedded controller (EC),
		which also manages the keyboard, battery charging, fans,
		and other system hardware. To prevent unprivileged users
		from interfering with the other EC functions, the rate at
		which the lightbar control files can be read or written is
		limited.

		Reading this file will return the number of milliseconds
		that must elapse between accessing any of the lightbar
		functions through this interface. Going faster will simply
		block until the necessary interval has lapsed. The interval
		applies uniformly to all accesses of any kind by any user.

What:		/sys/class/chromeos/<ec-device-name>/lightbar/led_rgb
Date:		August 2015
KernelVersion:	4.2
Description:
		This allows you to control each LED segment. If the
		lightbar is already running one of the automatic
		sequences, you probably won’t see anything change because
		your color setting will be almost immediately replaced.
		To get useful results, you should stop the lightbar
		sequence first.

		The values written to this file are sets of four integers,
		indicating LED, RED, GREEN, BLUE. The LED number is 0 to 3
		to select a single segment, or 4 to set all four segments
		to the same value at once. The RED, GREEN, and BLUE
		numbers should be in the range 0 (off) to 255 (maximum).
		You can update more than one segment at a time by writing
		more than one set of four integers.

What:		/sys/class/chromeos/<ec-device-name>/lightbar/program
Date:		August 2015
KernelVersion:	4.2
Description:
		This allows you to upload and run custom lightbar sequences.

What:		/sys/class/chromeos/<ec-device-name>/lightbar/sequence
Date:		August 2015
KernelVersion:	4.2
Description:
		The Pixel lightbar has a number of built-in sequences
		that it displays under various conditions, such as at
		power on, shut down, or while running. Reading from this
		file displays the current sequence that the lightbar is
		displaying. Writing to this file allows you to change the
		sequence.

What:		/sys/class/chromeos/<ec-device-name>/lightbar/userspace_control
Date:		August 2015
KernelVersion:	4.2
Description:
		This allows you to take the control of the lightbar. This
		prevents the kernel from going through its normal
		sequences.

What:		/sys/class/chromeos/<ec-device-name>/lightbar/version
Date:		August 2015
KernelVersion:	4.2
Description:
		Show the information about the lightbar version.


code:
What:		/sys/class/chromeos/<ec-device-name>/vbc/vboot_context
Date:		October 2015
KernelVersion:	4.4
Description:
		Read/write the verified boot context data included on a
		small nvram space on some EC implementations.


code:
Please note that attributes that are shared between devices are stored in
the directory pointed to by the symlink device/.
For example, the real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
/sys/class/cxl/afu0.0s/device/irqs_max, i.e. /sys/class/cxl/afu0.0/irqs_max.

Slave contexts (eg. /sys/class/cxl/afu0.0s):

What:           /sys/class/cxl/<afu>/afu_err_buf
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                AFU Error Buffer contents. The contents of this file are
		application specific and depends on the AFU being used.
		Applications interacting with the AFU can use this attribute
		to know about the current error condition and take appropriate
		action like logging the event etc.

What:           /sys/class/cxl/<afu>/irqs_max
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read/write
                Decimal value of maximum number of interrupts that can be
                requested by userspace.  The default on probe is the maximum
                that hardware can support (eg. 2037). Write values will limit
                userspace applications to that many userspace interrupts. Must
                be >= irqs_min.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/irqs_min
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Decimal value of the minimum number of interrupts that
                userspace must request on a CXL_START_WORK ioctl. Userspace may
                omit the num_interrupts field in the START_WORK IOCTL to get
                this minimum automatically.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/mmio_size
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Decimal value of the size of the MMIO space that may be mmaped
                by userspace.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/modes_supported
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                List of the modes this AFU supports. One per line.
                Valid entries are: "dedicated_process" and "afu_directed"
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/mode
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read/write
                The current mode the AFU is using. Will be one of the modes
                given in modes_supported. Writing will change the mode
                provided that no user contexts are attached.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/prefault_mode
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read/write
                Set the mode for prefaulting in segments into the segment table
                when performing the START_WORK ioctl. Only applicable when
                running under hashed page table mmu.
                Possible values:

                =======================  ======================================
		none			 No prefaulting (default)
		work_element_descriptor  Treat the work element
					 descriptor as an effective address and
					 prefault what it points to.
                all			 all segments process calling
					 START_WORK maps.
                =======================  ======================================

Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/reset
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    write only
                Writing 1 here will reset the AFU provided there are not
                contexts active on the AFU.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/api_version
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Decimal value of the current version of the kernel/user API.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/api_version_compatible
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Decimal value of the lowest version of the userspace API
                this kernel supports.
Users:		https://github.com/ibm-capi/libcxl

AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0):

An AFU may optionally export one or more PCIe like configuration records, known
as AFU configuration records, which will show up here (if present).

What:           /sys/class/cxl/<afu>/cr<config num>/vendor
Date:           February 2015
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
		Hexadecimal value of the vendor ID found in this AFU
		configuration record.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/cr<config num>/device
Date:           February 2015
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
		Hexadecimal value of the device ID found in this AFU
		configuration record.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/cr<config num>/class
Date:           February 2015
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
		Hexadecimal value of the class code found in this AFU
		configuration record.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>/cr<config num>/config
Date:           February 2015
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
		This binary file provides raw access to the AFU configuration
		record. The format is expected to match the either the standard
		or extended configuration space defined by the PCIe
		specification.
Users:		https://github.com/ibm-capi/libcxl

Master contexts (eg. /sys/class/cxl/afu0.0m)

What:           /sys/class/cxl/<afu>m/mmio_size
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Decimal value of the size of the MMIO space that may be mmaped
                by userspace. This includes all slave contexts space also.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>m/pp_mmio_len
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Decimal value of the Per Process MMIO space length.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<afu>m/pp_mmio_off
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                (not in a guest)
                Decimal value of the Per Process MMIO space offset.
Users:		https://github.com/ibm-capi/libcxl

Card info (eg. /sys/class/cxl/card0)

What:           /sys/class/cxl/<card>/caia_version
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Identifies the CAIA Version the card implements.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/psl_revision
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Identifies the revision level of the PSL.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/base_image
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                (not in a guest)
                Identifies the revision level of the base image for devices
                that support loadable PSLs. For FPGAs this field identifies
                the image contained in the on-adapter flash which is loaded
                during the initial program load.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/image_loaded
Date:           September 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                (not in a guest)
                Will return "user" or "factory" depending on the image loaded
                onto the card.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/load_image_on_perst
Date:           December 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read/write
                (not in a guest)
                Valid entries are "none", "user", and "factory".
                "none" means PERST will not cause image to be loaded to the
                card.  A power cycle is required to load the image.
                "none" could be useful for debugging because the trace arrays
                are preserved.

                "user" and "factory" means PERST will cause either the user or
                user or factory image to be loaded.
                Default is to reload on PERST whichever image the card has
                loaded.
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/reset
Date:           October 2014
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    write only
                Writing 1 will issue a PERST to card provided there are no
                contexts active on any one of the card AFUs. This may cause
                the card to reload the FPGA depending on load_image_on_perst.
                Writing -1 will do a force PERST irrespective of any active
                contexts on the card AFUs.
Users:		https://github.com/ibm-capi/libcxl

What:		/sys/class/cxl/<card>/perst_reloads_same_image
Date:		July 2015
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	read/write
                (not in a guest)
		Trust that when an image is reloaded via PERST, it will not
		have changed.

		==  =================================================
		0   don't trust, the image may be different (default)
		1   trust that the image will not change.
		==  =================================================
Users:		https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/psl_timebase_synced
Date:           March 2016
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Returns 1 if the psl timebase register is synchronized
                with the core timebase register, 0 otherwise.
Users:          https://github.com/ibm-capi/libcxl

What:           /sys/class/cxl/<card>/tunneled_ops_supported
Date:           May 2018
Contact:        linuxppc-dev@lists.ozlabs.org
Description:    read only
                Returns 1 if tunneled operations are supported in capi mode,
                0 otherwise.
Users:          https://github.com/ibm-capi/libcxl


code:
What:		/sys/class/devfreq/.../
Date:		September 2011
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		Provide a place in sysfs for the devfreq objects.
		This allows accessing various devfreq specific variables.
		The name of devfreq object denoted as ... is same as the
		name of device using devfreq.

What:		/sys/class/devfreq/.../name
Date:		November 2019
Contact:	Chanwoo Choi <cw00.choi@samsung.com>
Description:
		The /sys/class/devfreq/.../name shows the name of device
		of the corresponding devfreq object.

What:		/sys/class/devfreq/.../governor
Date:		September 2011
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/devfreq/.../governor show or set the name of the
		governor used by the corresponding devfreq object.

What:		/sys/class/devfreq/.../cur_freq
Date:		September 2011
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/devfreq/.../cur_freq shows the current
		frequency of the corresponding devfreq object. Same as
		target_freq when get_cur_freq() is not implemented by
		devfreq driver.

What:		/sys/class/devfreq/.../target_freq
Date:		September 2012
Contact:	Rajagopal Venkat <rajagopal.venkat@linaro.org>
Description:
		The /sys/class/devfreq/.../target_freq shows the next governor
		predicted target frequency of the corresponding devfreq object.

What:		/sys/class/devfreq/.../trans_stat
Date:		October 2012
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		This ABI shows or clears the statistics of devfreq behavior
		on a specific device. It shows the time spent in each state
		and the number of transitions between states.
		In order to activate this ABI, the devfreq target device
		driver should provide the list of available frequencies
		with its profile. If need to reset the statistics of devfreq
		behavior on a specific device, enter 0(zero) to 'trans_stat'
		as following::

			echo 0 > /sys/class/devfreq/.../trans_stat

What:		/sys/class/devfreq/.../available_frequencies
Date:		October 2012
Contact:	Nishanth Menon <nm@ti.com>
Description:
		The /sys/class/devfreq/.../available_frequencies shows
		the available frequencies of the corresponding devfreq object.
		This is a snapshot of available frequencies and not limited
		by the min/max frequency restrictions.

What:		/sys/class/devfreq/.../available_governors
Date:		October 2012
Contact:	Nishanth Menon <nm@ti.com>
Description:
		The /sys/class/devfreq/.../available_governors shows
		currently available governors in the system.

What:		/sys/class/devfreq/.../min_freq
Date:		January 2013
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/devfreq/.../min_freq shows and stores
		the minimum frequency requested by users. It is 0 if
		the user does not care. min_freq overrides the
		frequency requested by governors.

What:		/sys/class/devfreq/.../max_freq
Date:		January 2013
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/devfreq/.../max_freq shows and stores
		the maximum frequency requested by users. It is 0 if
		the user does not care. max_freq overrides the
		frequency requested by governors and min_freq.
		The max_freq overrides min_freq because max_freq may be
		used to throttle devices to avoid overheating.

What:		/sys/class/devfreq/.../polling_interval
Date:		September 2011
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/devfreq/.../polling_interval shows and sets
		the requested polling interval of the corresponding devfreq
		object. The values are represented in ms. If the value is
		less than 1 jiffy, it is considered to be 0, which means
		no polling. This value is meaningless if the governor is
		not polling.

		A list of governors that support the node:
		- simple_ondmenad
		- tegra_actmon

What:		/sys/class/devfreq/.../userspace/set_freq
Date:		September 2011
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/devfreq/.../userspace/set_freq shows and
		sets the requested frequency for the devfreq object if
		userspace governor is in effect.

		A list of governors that support the node:
		- userspace

What:		/sys/class/devfreq/.../timer
Date:		July 2020
Contact:	Chanwoo Choi <cw00.choi@samsung.com>
Description:
		This ABI shows and stores the kind of work timer by users.
		This work timer is used by devfreq workqueue in order to
		monitor the device status such as utilization. The user
		can change the work timer on runtime according to their demand
		as following::

			echo deferrable > /sys/class/devfreq/.../timer
			echo delayed > /sys/class/devfreq/.../timer

		A list of governors that support the node:
		- simple_ondemand


code:
What:		/sys/class/devfreq-event/event<x>/
Date:		January 2017
Contact:	Chanwoo Choi <cw00.choi@samsung.com>
Description:
		Provide a place in sysfs for the devfreq-event objects.
		This allows accessing various devfreq-event specific variables.
		The name of devfreq-event object denoted as 'event<x>' which
		includes the unique number of 'x' for each devfreq-event object.

What:		/sys/class/devfreq-event/event<x>/name
Date:		January 2017
Contact:	Chanwoo Choi <cw00.choi@samsung.com>
Description:
		The /sys/class/devfreq-event/event<x>/name attribute contains
		the name of the devfreq-event object. This attribute is
		read-only.

What:		/sys/class/devfreq-event/event<x>/enable_count
Date:		January 2017
Contact:	Chanwoo Choi <cw00.choi@samsung.com>
Description:
		The /sys/class/devfreq-event/event<x>/enable_count attribute
		contains the reference count to enable the devfreq-event
		object. If the device is enabled, the value of attribute is
		greater than zero.


code:
What:		/sys/class/devlink/.../
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		Provide a place in sysfs for the device link objects in the
		kernel at any given time.  The name of a device link directory,
		denoted as ... above, is of the form <supplier>--<consumer>
		where <supplier> is the supplier bus:device name and <consumer>
		is the consumer bus:device name.

What:		/sys/class/devlink/.../auto_remove_on
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		This file indicates if the device link will ever be
		automatically removed by the driver core when the consumer and
		supplier devices themselves are still present.

		This will be one of the following strings:

		- 'consumer unbind'
		- 'supplier unbind'
		- 'never'

		'consumer unbind' means the device link will be removed when
		the consumer's driver is unbound from the consumer device.

		'supplier unbind' means the device link will be removed when
		the supplier's driver is unbound from the supplier device.

		'never' means the device link will not be automatically removed
		when as long as the supplier and consumer devices themselves
		are still present.

What:		/sys/class/devlink/.../consumer
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		This file is a symlink to the consumer device's sysfs directory.

What:		/sys/class/devlink/.../runtime_pm
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		This file indicates if the device link has any impact on the
		runtime power management behavior of the consumer and supplier
		devices. For example: Making sure the supplier doesn't enter
		runtime suspend while the consumer is active.

		This will be one of the following strings:

		===   ========================================
		'0'   Does not affect runtime power management
		'1'   Affects runtime power management
		===   ========================================

What:		/sys/class/devlink/.../status
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		This file indicates the status of the device link. The status
		of a device link is affected by whether the supplier and
		consumer devices have been bound to their corresponding
		drivers. The status of a device link also affects the binding
		and unbinding of the supplier and consumer devices with their
		drivers and also affects whether the software state of the
		supplier device is synced with the hardware state of the
		supplier device after boot up.
		See also: sysfs-devices-state_synced.

		This will be one of the following strings:

		- 'not tracked'
		- 'dormant'
		- 'available'
		- 'consumer probing'
		- 'active'
		- 'supplier unbinding'
		- 'unknown'

		'not tracked' means this device link does not track the status
		and has no impact on the binding, unbinding and syncing the
		hardware and software device state.

		'dormant' means the supplier and the consumer devices have not
		bound to their driver.

		'available' means the supplier has bound to its driver and is
		available to supply resources to the consumer device.

		'consumer probing' means the consumer device is currently
		trying to bind to its driver.

		'active' means the supplier and consumer devices have both
		bound successfully to their drivers.

		'supplier unbinding' means the supplier devices is currently in
		the process of unbinding from its driver.

		'unknown' means the state of the device link is not any of the
		above. If this is ever the value, there's a bug in the kernel.

What:		/sys/class/devlink/.../supplier
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		This file is a symlink to the supplier device's sysfs directory.

What:		/sys/class/devlink/.../sync_state_only
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		This file indicates if the device link is limited to only
		affecting the syncing of the hardware and software state of the
		supplier device.

		This will be one of the following strings:

		===  ================================
		'0'
		'1'  Affects runtime power management
		===  ================================

		'0' means the device link can affect other device behaviors
		like binding/unbinding, suspend/resume, runtime power
		management, etc.

		'1' means the device link will only affect the syncing of
		hardware and software state of the supplier device after boot
		up and doesn't not affect other behaviors of the devices.


code:
What:		/sys/class/extcon/.../
Date:		February 2012
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		Provide a place in sysfs for the extcon objects.
		This allows accessing extcon specific variables.
		The name of extcon object denoted as ... is the name given
		with extcon_dev_register.

		One extcon device denotes a single external connector
		port. An external connector may have multiple cables
		attached simultaneously. Many of docks, cradles, and
		accessory cables have such capability. For example,
		the 30-pin port of Nuri board (/arch/arm/mach-exynos)
		may have both HDMI and Charger attached, or analog audio,
		video, and USB cables attached simultaneously.

		If there are cables mutually exclusive with each other,
		such binary relations may be expressed with extcon_dev's
		mutually_exclusive array.

What:		/sys/class/extcon/.../name
Date:		February 2012
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/extcon/.../name shows the name of the extcon
		object. If the extcon object has an optional callback
		"show_name" defined, the callback will provide the name with
		this sysfs node.

What:		/sys/class/extcon/.../state
Date:		February 2012
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/extcon/.../state shows and stores the cable
		attach/detach information of the corresponding extcon object.
		If the extcon object has an optional callback "show_state"
		defined, the showing function is overridden with the optional
		callback.

		If the default callback for showing function is used, the
		format is like this::

		    # cat state
		    USB_OTG=1
		    HDMI=0
		    TA=1
		    EAR_JACK=0
		    #

		In this example, the extcon device has USB_OTG and TA
		cables attached and HDMI and EAR_JACK cables detached.

		In order to update the state of an extcon device, enter a hex
		state number starting with 0x::

		    # echo 0xHEX > state

		This updates the whole state of the extcon device.
		Inputs of all the methods are required to meet the
		mutually_exclusive conditions if they exist.

		It is recommended to use this "global" state interface if
		you need to set the value atomically. The later state
		interface associated with each cable cannot update
		multiple cable states of an extcon device simultaneously.

What:		/sys/class/extcon/.../cable.X/name
Date:		February 2012
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/extcon/.../cable.X/name shows the name of cable
		"X" (integer between 0 and 31) of an extcon device.

What:		/sys/class/extcon/.../cable.X/state
Date:		February 2012
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		The /sys/class/extcon/.../cable.X/state shows and stores the
		state of cable "X" (integer between 0 and 31) of an extcon
		device. The state value is either 0 (detached) or 1
		(attached).

What:		/sys/class/extcon/.../mutually_exclusive/...
Date:		December 2011
Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
		Shows the relations of mutually exclusiveness. For example,
		if the mutually_exclusive array of extcon device is
		{0x3, 0x5, 0xC, 0x0}, then the output is::

		    # ls mutually_exclusive/
		    0x3
		    0x5
		    0xc
		    #

		Note that mutually_exclusive is a sub-directory of the extcon
		device and the file names under the mutually_exclusive
		directory show the mutually-exclusive sets, not the contents
		of the files.


code:
What:		/sys/class/fc/fc_udev_device/appid_store
Date:		Aug 2021
Contact:	Muneendra Kumar <muneendra.kumar@broadconm.com>
Description:
		This interface allows an admin to set an FC application
		identifier in the blkcg associated with a cgroup id. The
		identifier is typically a UUID that is associated with
		an application or logical entity such as a virtual
		machine or container group. The application or logical
		entity utilizes a block device via the cgroup id.
		FC adapter drivers may query the identifier and tag FC
		traffic based on the identifier. FC host and FC fabric
		entities can utilize the application id and FC traffic
		tag to identify traffic sources.

		The interface expects a string "<cgroupid>:<appid>" where:
		<cgroupid> is inode of the cgroup in hexadecimal
		<appid> is user provided string upto 128 characters
		in length.

		If an appid_store is done for a cgroup id that already
		has an appid set, the new value will override the
		previous value.

		If an admin wants to remove an FC application identifier
		from a cgroup, an appid_store should be done with the
		following string: "<cgroupid>:"


code:
What:		/sys/class/fc_host/hostX/statistics/fpin_cn_yyy
Date:		July 2020
Contact:	Shyam Sundar <ssundar@marvell.com>
Description:
		These files contain the number of congestion notification
		events recorded by the F_Port, reported using fabric
		performance impact notification (FPIN) event.

What:		/sys/class/fc_host/hostX/statistics/fpin_li_yyy
Date:		July 2020
Contact:	Shyam Sundar <ssundar@marvell.com>
Description:
		These files contain the number of link integrity error
		events recorded by the F_Port/Nx_Port, reported using fabric
		performance impact notification (FPIN) event.

What:		/sys/class/fc_host/hostX/statistics/fpin_dn_yyy
Date:		July 2020
Contact:	Shyam Sundar <ssundar@marvell.com>
Description:
		These files contain the number of delivery related errors
		recorded by the F_Port/Nx_Port, reported using fabric
		performance impact notification (FPIN) event.


code:
What:		/sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_cn_yyy
Date:		July 2020
Contact:	Shyam Sundar <ssundar@marvell.com>
Description:
		These files contain the number of congestion notification
		events recorded by the F_Port/Nx_Port, reported using fabric
		performance impact notification (FPIN) event.

What:		/sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_li_yyy
Date:		July 2020
Contact:	Shyam Sundar <ssundar@marvell.com>
Description:
		These files contain the number of link integrity error
		events recorded by the F_Port/Nx_Port, reported using fabric
		performance impact notification (FPIN) event.

What:		/sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_dn_yyy
Date:		July 2020
Contact:	Shyam Sundar <ssundar@marvell.com>
Description:
		These files contain the number of delivery related errors
		recorded by the F_Port/Nx_Port, reported using fabric
		performance impact notification (FPIN) event.


code:
What: 		/sys/class/firmware/.../data
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	The data sysfs file is used for firmware-fallback and for
		firmware uploads. Cat a firmware image to this sysfs file
		after you echo 1 to the loading sysfs file. When the firmware
		image write is complete, echo 0 to the loading sysfs file. This
		sequence will signal the completion of the firmware write and
		signal the lower-level driver that the firmware data is
		available.

What: 		/sys/class/firmware/.../cancel
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	Write-only. For firmware uploads, write a "1" to this file to
		request that the transfer of firmware data to the lower-level
		device be canceled. This request will be rejected (EBUSY) if
		the update cannot be canceled (e.g. a FLASH write is in
		progress) or (ENODEV) if there is no firmware update in progress.

What: 		/sys/class/firmware/.../error
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	Read-only. Returns a string describing a failed firmware
		upload. This string will be in the form of <STATUS>:<ERROR>,
		where <STATUS> will be one of the status strings described
		for the status sysfs file and <ERROR> will be one of the
		following: "hw-error", "timeout", "user-abort", "device-busy",
		"invalid-file-size", "read-write-error", "flash-wearout". The
		error sysfs file is only meaningful when the current firmware
		upload status is "idle". If this file is read while a firmware
		transfer is in progress, then the read will fail with EBUSY.

What: 		/sys/class/firmware/.../loading
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	The loading sysfs file is used for both firmware-fallback and
		for firmware uploads. Echo 1 onto the loading file to indicate
		you are writing a firmware file to the data sysfs node. Echo
		-1 onto this file to abort the data write or echo 0 onto this
		file to indicate that the write is complete. For firmware
		uploads, the zero value also triggers the transfer of the
		firmware data to the lower-level device driver.

What: 		/sys/class/firmware/.../remaining_size
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	Read-only. For firmware upload, this file contains the size
		of the firmware data that remains to be transferred to the
		lower-level device driver. The size value is initialized to
		the full size of the firmware image that was previously
		written to the data sysfs file. This value is periodically
		updated during the "transferring" phase of the firmware
		upload.
		Format: "%u".

What: 		/sys/class/firmware/.../status
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	Read-only. Returns a string describing the current status of
		a firmware upload. The string will be one of the following:
		idle, "receiving", "preparing", "transferring", "programming".

What: 		/sys/class/firmware/.../timeout
Date:		July 2022
KernelVersion:	5.19
Contact:	Russ Weight <russell.h.weight@intel.com>
Description:	This file supports the timeout mechanism for firmware
		fallback.  This file has no affect on firmware uploads. For
		more information on timeouts please see the documentation
		for firmware fallback.


code:
What:		/sys/class/firmware-attributes/*/attributes/*/
Date:		February 2021
KernelVersion:	5.11
Contact:	Divya Bharathi <Divya.Bharathi@Dell.com>,
		Prasanth KSR <prasanth.ksr@dell.com>
		Dell.Client.Kernel@dell.com
Description:
		A sysfs interface for systems management software to enable
		configuration capability on supported systems.  This directory
		exposes interfaces for interacting with configuration options.

		Unless otherwise specified in an attribute description all attributes are optional
		and will accept UTF-8 input.

		type:
		    A file that can be read to obtain the type of attribute.
		    This attribute is mandatory.

		The following are known types:

			- enumeration: a set of pre-defined valid values
			- integer: a range of numerical values
			- string

		All attribute types support the following values:

		current_value:
				A file that can be read to obtain the current
				value of the <attr>.

				This file can also be written to in order to update the value of a
				<attr>

				This attribute is mandatory.

		default_value:
				A file that can be read to obtain the default
				value of the <attr>

		display_name:
				A file that can be read to obtain a user friendly
				description of the at <attr>

		display_name_language_code:
						A file that can be read to obtain
						the IETF language tag corresponding to the
						"display_name" of the <attr>

		"enumeration"-type specific properties:

		possible_values:
					A file that can be read to obtain the possible
					values of the <attr>. Values are separated using
					semi-colon (``;``).

		"integer"-type specific properties:

		min_value:
				A file that can be read to obtain the lower
				bound value of the <attr>

		max_value:
				A file that can be read to obtain the upper
				bound value of the <attr>

		scalar_increment:
					A file that can be read to obtain the scalar value used for
					increments of current_value this attribute accepts.

		"string"-type specific properties:

		max_length:
				A file that can be read to obtain the maximum
				length value of the <attr>

		min_length:
				A file that can be read to obtain the minimum
				length value of the <attr>

		Dell specific class extensions
		------------------------------

		On Dell systems the following additional attributes are available:

		dell_modifier:
				A file that can be read to obtain attribute-level
				dependency rule. It says an attribute X will become read-only or
				suppressed, if/if-not attribute Y is configured.

				modifier rules can be in following format::

				    [ReadOnlyIf:<attribute>=<value>]
				    [ReadOnlyIfNot:<attribute>=<value>]
				    [SuppressIf:<attribute>=<value>]
				    [SuppressIfNot:<attribute>=<value>]

				For example::

				    AutoOnFri/dell_modifier has value,
					    [SuppressIfNot:AutoOn=SelectDays]

				This means AutoOnFri will be suppressed in BIOS setup if AutoOn
				attribute is not "SelectDays" and its value will not be effective
				through sysfs until this rule is met.

		Enumeration attributes also support the following:

		dell_value_modifier:
					A file that can be read to obtain value-level dependency.
					This file is similar to dell_modifier but here,	an
					attribute's current value will be forcefully changed based
					dependent attributes value.

					dell_value_modifier rules can be in following format::

					    <value>[ForceIf:<attribute>=<value>]
					    <value>[ForceIfNot:<attribute>=<value>]

					For example::

					    LegacyOrom/dell_value_modifier has value:
						    Disabled[ForceIf:SecureBoot=Enabled]

					This means LegacyOrom's current value will be forced to
					"Disabled" in BIOS setup if SecureBoot is Enabled and its
					value will not be effective through sysfs until this rule is
					met.

What:		/sys/class/firmware-attributes/*/authentication/
Date:		February 2021
KernelVersion:	5.11
Contact:	Divya Bharathi <Divya.Bharathi@Dell.com>,
		Prasanth KSR <prasanth.ksr@dell.com>
		Dell.Client.Kernel@dell.com
Description:
		Devices support various authentication mechanisms which can be exposed
		as a separate configuration object.

		For example a "BIOS Admin" password and "System" Password can be set,
		reset or cleared using these attributes.

		- An "Admin" password is used for preventing modification to the BIOS
		  settings.
		- A "System" password is required to boot a machine.

		Change in any of these two authentication methods will also generate an
		uevent KOBJ_CHANGE.

		is_enabled:
					A file that can be read to obtain a 0/1 flag to see if
					<attr> authentication is enabled.
					This attribute is mandatory.

		role:
					The type of authentication used.
					This attribute is mandatory.

					Known types:
						bios-admin:
							Representing BIOS administrator password
						power-on:
							Representing a password required to use
							the system
						system-mgmt:
							Representing System Management password.
							See Lenovo extensions section for details
						HDD:
							Representing HDD password
							See Lenovo extensions section for details
						NVMe:
							Representing NVMe password
							See Lenovo extensions section for details

		mechanism:
					The means of authentication.  This attribute is mandatory.
					Only supported type currently is "password".

		max_password_length:
					A file that can be read to obtain the
					maximum length of the Password

		min_password_length:
					A file that can be read to obtain the
					minimum length of the Password

		current_password:
					A write only value used for privileged access such as
					setting	attributes when a system or admin password is set
					or resetting to a new password

					This attribute is mandatory when mechanism == "password".

		new_password:
					A write only value that when used in tandem with
					current_password will reset a system or admin password.

		Note, password management is session specific. If Admin password is set,
		same password must be written into current_password file (required for
		password-validation) and must be cleared once the session is over.
		For example::

			echo "password" > current_password
			echo "disabled" > TouchScreen/current_value
			echo "" > current_password

		Drivers may emit a CHANGE uevent when a password is set or unset
		userspace may check it again.

		On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes
		require password validation.
		On Lenovo systems if you change the Admin password the new password is not active until
		the next boot.

		Lenovo specific class extensions
		--------------------------------

		On Lenovo systems the following additional settings are available:

		role: system-mgmt	This gives the same authority as the bios-admin password to control
					security related features. The authorities allocated can be set via
					the BIOS menu SMP Access Control Policy

		role: HDD & NVMe	This password is used to unlock access to the drive at boot. Note see
					'level' and 'index' extensions below.

		lenovo_encoding:
					The encoding method that is used. This can be either "ascii"
					or "scancode". Default is set to "ascii"

		lenovo_kbdlang:
					The keyboard language method that is used. This is generally a
					two char code (e.g. "us", "fr", "gr") and may vary per platform.
					Default is set to "us"

		level:
					Available for HDD and NVMe authentication to set 'user' or 'master'
					privilege level.
					If only the user password is configured then this should be used to
					unlock the drive at boot. If both master and user passwords are set
					then either can be used. If a master password is set a user password
					is required.
					This attribute defaults to 'user' level

		index:
					Used with HDD and NVME authentication to set the drive index
					that is being referenced (e.g hdd0, hdd1 etc)
					This attribute defaults to device 0.

		certificate, signature, save_signature:
					These attributes are used for certificate based authentication. This is
					used in conjunction with a signing server as an alternative to password
					based authentication.
					The user writes to the attribute(s) with a BASE64 encoded string obtained
					from the signing server.
					The attributes can be displayed to check the stored value.

					Some usage examples:

						Installing a certificate to enable feature::

							echo "supervisor password" > authentication/Admin/current_password
							echo "signed certificate" > authentication/Admin/certificate

						Updating the installed certificate::

							echo "signature" > authentication/Admin/signature
							echo "signed certificate" > authentication/Admin/certificate

						Removing the installed certificate::

							echo "signature" > authentication/Admin/signature
							echo "" > authentication/Admin/certificate

						Changing a BIOS setting::

							echo "signature" > authentication/Admin/signature
							echo "save signature" > authentication/Admin/save_signature
							echo Enable > attribute/PasswordBeep/current_value

					You cannot enable certificate authentication if a supervisor password
					has not been set.
					Clearing the certificate results in no bios-admin authentication method
					being configured allowing anyone to make changes.
					After any of these operations the system must reboot for the changes to
					take effect.

		certificate_thumbprint:
					Read only attribute used to display the MD5, SHA1 and SHA256 thumbprints
					for the certificate installed in the BIOS.

		certificate_to_password:
					Write only attribute used to switch from certificate based authentication
					back to password based.
					Usage::

						echo "signature" > authentication/Admin/signature
						echo "password" > authentication/Admin/certificate_to_password

What:		/sys/class/firmware-attributes/*/attributes/pending_reboot
Date:		February 2021
KernelVersion:	5.11
Contact:	Divya Bharathi <Divya.Bharathi@Dell.com>,
		Prasanth KSR <prasanth.ksr@dell.com>
		Dell.Client.Kernel@dell.com
Description:
		A read-only attribute reads 1 if a reboot is necessary to apply
		pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is
		generated when it changes to 1.

			==	=========================================
			0	All BIOS attributes setting are current
			1	A reboot is necessary to get pending BIOS
			        attribute changes applied
			==	=========================================

		Note, userspace applications need to follow below steps for efficient
		BIOS management,

		1.	Check if admin password is set. If yes, follow session method for
			password management as briefed under authentication section above.
		2.	Before setting any attribute, check if it has any modifiers
			or value_modifiers. If yes, incorporate them and then modify
			attribute.

		Drivers may emit a CHANGE uevent when this value changes and userspace
		may check it again.

What:		/sys/class/firmware-attributes/*/attributes/reset_bios
Date:		February 2021
KernelVersion:	5.11
Contact:	Divya Bharathi <Divya.Bharathi@Dell.com>,
		Prasanth KSR <prasanth.ksr@dell.com>
		Dell.Client.Kernel@dell.com
Description:
		This attribute can be used to reset the BIOS Configuration.
		Specifically, it tells which type of reset BIOS configuration is being
		requested on the host.

		Reading from it returns a list of supported options encoded as:

			- 'builtinsafe' (Built in safe configuration profile)
			- 'lastknowngood' (Last known good saved configuration profile)
			- 'factory' (Default factory settings configuration profile)
			- 'custom' (Custom saved configuration profile)

		The currently selected option is printed in square brackets as
		shown below::

		    # echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios
		    # cat /sys/class/firmware-attributes/*/device/attributes/reset_bios
		    builtinsafe lastknowngood [factory] custom

		Note that any changes to this attribute requires a reboot
		for changes to take effect.

What:		/sys/class/firmware-attributes/*/attributes/debug_cmd
Date:		July 2021
KernelVersion:	5.14
Contact:	Mark Pearson <markpearson@lenovo.com>
Description:
		This write only attribute can be used to send debug commands to the BIOS.
		This should only be used when recommended by the BIOS vendor. Vendors may
		use it to enable extra debug attributes or BIOS features for testing purposes.

		Note that any changes to this attribute requires a reboot for changes to take effect.


code:
What:		/sys/class/fpga_bridge/<bridge>/name
Date:		January 2016
KernelVersion:	4.5
Contact:	Alan Tull <atull@opensource.altera.com>
Description:	Name of low level FPGA bridge driver.

What:		/sys/class/fpga_bridge/<bridge>/state
Date:		January 2016
KernelVersion:	4.5
Contact:	Alan Tull <atull@opensource.altera.com>
Description:	Show bridge state as "enabled" or "disabled"