code:
What:		/sys/class/thermal/thermal_zoneX/type
Description:
		Strings which represent the thermal zone type.
		This is given by thermal zone driver as part of registration.
		E.g: "acpitz" indicates it's an ACPI thermal device.
		In order to keep it consistent with hwmon sys attribute; this
		shouldbe a short, lowercase string, not containing spaces nor
		dashes.

		RO, Required

What:		/sys/class/thermal/thermal_zoneX/temp
Description:
		Current temperature as reported by thermal zone (sensor).

		Unit: millidegree Celsius

		RO, Required

What:		/sys/class/thermal/thermal_zoneX/mode
Description:
		One of the predefined values in [enabled, disabled].
		This file gives information about the algorithm that is
		currently managing the thermal zone. It can be either default
		kernel based algorithm or user space application.

		enabled
				enable Kernel Thermal management.
		disabled
				Preventing kernel thermal zone driver actions upon
				trip points so that user application can take full
				charge of the thermal management.

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/policy
Description:
		One of the various thermal governors used for a particular zone.

		RW, Required

What:		/sys/class/thermal/thermal_zoneX/available_policies
Description:
		Available thermal governors which can be used for a
		particular zone.

		RO, Required

What:		/sys/class/thermal/thermal_zoneX/trip_point_Y_temp
Description:
		The temperature above which trip point will be fired.

		Unit: millidegree Celsius

		RO, Optional

What:		/sys/class/thermal/thermal_zoneX/trip_point_Y_type
Description:
		Strings which indicate the type of the trip point.

		E.g. it can be one of critical, hot, passive, `active[0-*]`
		for ACPI thermal zone.

		RO, Optional

What:		/sys/class/thermal/thermal_zoneX/trip_point_Y_hyst
Description:
		The hysteresis value for a trip point, represented as an
		integer.

		Unit: Celsius

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/cdevY
Description:
	Sysfs link to the thermal cooling device node where the sys I/F
	for cooling device throttling control represents.

	RO, Optional

What:		/sys/class/thermal/thermal_zoneX/cdevY_trip_point
Description:
		The trip point in this thermal zone which `cdev[0-*]` is
		associated with; -1 means the cooling device is not
		associated with any trip point.

		RO, Optional

What:		/sys/class/thermal/thermal_zoneX/cdevY_weight
Description:
		The influence of `cdev[0-*]` in this thermal zone. This value
		is relative to the rest of cooling devices in the thermal
		zone. For example, if a cooling device has a weight double
		than that of other, it's twice as effective in cooling the
		thermal zone.

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/emul_temp
Description:
		Interface to set the emulated temperature method in thermal zone
		(sensor). After setting this temperature, the thermal zone may
		pass this temperature to platform emulation function if
		registered or cache it locally. This is useful in debugging
		different temperature threshold and its associated cooling
		action. This is write only node and writing 0 on this node
		should disable emulation.

		Unit: millidegree Celsius

		WO, Optional

		WARNING:
		    Be careful while enabling this option on production systems,
		    because userland can easily disable the thermal policy by simply
		    flooding this sysfs node with low temperature values.

What:		/sys/class/thermal/thermal_zoneX/k_d
Description:
		The derivative term of the power allocator governor's PID
		controller. For more information see
		Documentation/driver-api/thermal/power_allocator.rst

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/k_i
Description:
		The integral term of the power allocator governor's PID
		controller. This term allows the PID controller to compensate
		for long term drift. For more information see
		Documentation/driver-api/thermal/power_allocator.rst

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/k_po
Description:
		The proportional term of the power allocator governor's PID
		controller during temperature overshoot. Temperature overshoot
		is when the current temperature is above the "desired
		temperature" trip point. For more information see
		Documentation/driver-api/thermal/power_allocator.rst

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/k_pu
Description:
		The proportional term of the power allocator governor's PID
		controller during temperature undershoot. Temperature undershoot
		is when the current temperature is below the "desired
		temperature" trip point. For more information see
		Documentation/driver-api/thermal/power_allocator.rst

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/integral_cutoff
Description:
		Temperature offset from the desired temperature trip point
		above which the integral term of the power allocator
		governor's PID controller starts accumulating errors. For
		example, if integral_cutoff is 0, then the integral term only
		accumulates error when temperature is above the desired
		temperature trip point. For more information see
		Documentation/driver-api/thermal/power_allocator.rst

		Unit: millidegree Celsius

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/slope
Description:
		The slope constant used in a linear extrapolation model
		to determine a hotspot temperature based off the sensor's
		raw readings. It is up to the device driver to determine
		the usage of these values.

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/offset
Description:
		The offset constant used in a linear extrapolation model
		to determine a hotspot temperature based off the sensor's
		raw readings. It is up to the device driver to determine
		the usage of these values.

		RW, Optional

What:		/sys/class/thermal/thermal_zoneX/sustainable_power
Description:
		An estimate of the sustained power that can be dissipated by
		the thermal zone. Used by the power allocator governor. For
		more information see
		Documentation/driver-api/thermal/power_allocator.rst

		Unit: milliwatts

		RW, Optional

What:		/sys/class/thermal/cooling_deviceX/type
Description:
		String which represents the type of device, e.g:

		- for generic ACPI: should be "Fan", "Processor" or "LCD"
		- for memory controller device on intel_menlow platform:
		  should be "Memory controller".

		RO, Required

What:		/sys/class/thermal/cooling_deviceX/max_state
Description:
		The maximum permissible cooling state of this cooling device.

		RO, Required

What:		/sys/class/thermal/cooling_deviceX/cur_state
Description:
		The current cooling state of this cooling device.
		The value can any integer numbers between 0 and max_state:

		- cur_state == 0 means no cooling
		- cur_state == max_state means the maximum cooling.

		RW, Required

What:		/sys/class/thermal/cooling_deviceX/stats/reset
Description:
		Writing any value resets the cooling device's statistics.

		WO, Required

What:		/sys/class/thermal/cooling_deviceX/stats/time_in_state_ms:
Description:
		The amount of time spent by the cooling device in various
		cooling states. The output will have "<state> <time>" pair
		in each line, which will mean this cooling device spent <time>
		msec of time at <state>.

		Output will have one line for each of the supported states.

		RO, Required

What:		/sys/class/thermal/cooling_deviceX/stats/total_trans
Description:
		A single positive value showing the total number of times
		the state of a cooling device is changed.

		RO, Required

What:		/sys/class/thermal/cooling_deviceX/stats/trans_table
Description:
		This gives fine grained information about all the cooling state
		transitions. The cat output here is a two dimensional matrix,
		where an entry <i,j> (row i, column j) represents the number
		of transitions from State_i to State_j. If the transition
		table is bigger than PAGE_SIZE, reading this will return
		an -EFBIG error.

		RO, Required


code:
USB Type-C port devices (eg. /sys/class/typec/port0/)

What:		/sys/class/typec/<port>/data_role
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The supported USB data roles. This attribute can be used for
		requesting data role swapping on the port. Swapping is supported
		as synchronous operation, so write(2) to the attribute will not
		return until the operation has finished. The attribute is
		notified about role changes so that poll(2) on the attribute
		wakes up. Change on the role will also generate uevent
		KOBJ_CHANGE on the port. The current role is show in brackets,
		for example "[host] device" when DRP port is in host mode.

		Valid values: host, device

What:		/sys/class/typec/<port>/power_role
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The supported power roles. This attribute can be used to request
		power role swap on the port. Swapping is supported as
		synchronous operation, so write(2) to the attribute will not
		return until the operation has finished. The attribute is
		notified about role changes so that poll(2) on the attribute
		wakes up. Change on the role will also generate uevent
		KOBJ_CHANGE. The current role is show in brackets, for example
		"[source] sink" when in source mode.

		Valid values: source, sink

What:           /sys/class/typec/<port>/port_type
Date:           May 2017
Contact:	Badhri Jagan Sridharan <Badhri@google.com>
Description:
		Indicates the type of the port. This attribute can be used for
		requesting a change in the port type. Port type change is
		supported as a synchronous operation, so write(2) to the
		attribute will not return until the operation has finished.

		Valid values:

		======  ==============================================
		source  (The port will behave as source only DFP port)
		sink    (The port will behave as sink only UFP port)
		dual    (The port will behave as dual-role-data and
			dual-role-power port)
		======  ==============================================

What:		/sys/class/typec/<port>/vconn_source
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Shows is the port VCONN Source. This attribute can be used to
		request VCONN swap to change the VCONN Source during connection
		when both the port and the partner support USB Power Delivery.
		Swapping is supported as synchronous operation, so write(2) to
		the attribute will not return until the operation has finished.
		The attribute is notified about VCONN source changes so that
		poll(2) on the attribute wakes up. Change on VCONN source also
		generates uevent KOBJ_CHANGE.

		Valid values:

		- "no" when the port is not the VCONN Source
		- "yes" when the port is the VCONN Source

What:		/sys/class/typec/<port>/power_operation_mode
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Shows the current power operational mode the port is in. The
		power operation mode means current level for VBUS. In case USB
		Power Delivery communication is used for negotiating the levels,
		power operation mode should show "usb_power_delivery".

		Valid values:

		- default
		- 1.5A
		- 3.0A
		- usb_power_delivery

What:		/sys/class/typec/<port>/preferred_role
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The user space can notify the driver about the preferred role.
		It should be handled as enabling of Try.SRC or Try.SNK, as
		defined in USB Type-C specification, in the port drivers. By
		default the preferred role should come from the platform.

		Valid values: source, sink, none (to remove preference)

What:		/sys/class/typec/<port>/supported_accessory_modes
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Space separated list of accessory modes, defined in the USB
		Type-C specification, the port supports.

What:		/sys/class/typec/<port>/usb_power_delivery_revision
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Revision number of the supported USB Power Delivery
		specification, or 0.0 when USB Power Delivery is not supported.

		Example values:
		- "2.0": USB Power Delivery Release 2.0
		- "3.0": USB Power Delivery Release 3.0
		- "3.1": USB Power Delivery Release 3.1

What:		/sys/class/typec/<port>-{partner|cable}/usb_power_delivery_revision
Date:		January 2021
Contact:	Benson Leung <bleung@chromium.org>
Description:
		Revision number of the supported USB Power Delivery
		specification of the port partner or cable, or 0.0 when USB
		Power Delivery is not supported.

		Example values:
		- "2.0": USB Power Delivery Release 2.0
		- "3.0": USB Power Delivery Release 3.0
		- "3.1": USB Power Delivery Release 3.1

What:		/sys/class/typec/<port>/usb_typec_revision
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Revision number of the supported USB Type-C specification.

What:		/sys/class/typec/<port>/orientation
Date:		February 2020
Contact:	Badhri Jagan Sridharan <badhri@google.com>
Description:
		Indicates the active orientation of the Type-C connector.
		Valid values:
		- "normal": CC1 orientation
		- "reverse": CC2 orientation
		- "unknown": Orientation cannot be determined.

What:		/sys/class/typec/<port>/select_usb_power_delivery
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Lists the USB Power Delivery Capabilities that the port can
		advertise to the partner. The currently used capabilities are in
		brackets. Selection happens by writing to the file.

USB Type-C partner devices (eg. /sys/class/typec/port0-partner/)

What:		/sys/class/typec/<port>-partner/accessory_mode
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Shows the Accessory Mode name when the partner is an Accessory.
		The Accessory Modes are defined in USB Type-C Specification.

What:		/sys/class/typec/<port>-partner/supports_usb_power_delivery
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Shows if the partner supports USB Power Delivery communication:
		Valid values: yes, no

What:		/sys/class/typec/<port>-partner/number_of_alternate_modes
Date:		November 2020
Contact:	Prashant Malani <pmalani@chromium.org>
Description:
		Shows the number of alternate modes which are advertised by the partner
		during Power Delivery discovery. This file remains hidden until a value
		greater than or equal to 0 is set by Type C port driver.

What:		/sys/class/typec/<port>-partner/type
Date:		December 2020
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:	USB Power Delivery Specification defines a set of product types
		for the partner devices. This file will show the product type of
		the partner if it is known. Dual-role capable partners will have
		both UFP and DFP product types defined, but only one that
		matches the current role will be active at the time. If the
		product type of the partner is not visible to the device driver,
		this file will not exist.

		When the partner product type is detected, or changed with role
		swap, uvevent is also raised that contains PRODUCT_TYPE=<product
		type> (for example PRODUCT_TYPE=hub).

		Valid values:

		UFP / device role
		======================  ==========================
		undefined		-
		hub			PDUSB Hub
		peripheral		PDUSB Peripheral
		psd			Power Bank
		ama			Alternate Mode Adapter
		======================  ==========================

		DFP / host role
		======================  ==========================
		undefined		-
		hub			PDUSB Hub
		host			PDUSB Host
		power_brick		Power Brick
		amc			Alternate Mode Controller
		======================  ==========================

What:		/sys/class/typec/<port>-partner/identity/
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This directory appears only if the port device driver is capable
		of showing the result of Discover Identity USB power delivery
		command. That will not always be possible even when USB power
		delivery is supported, for example when USB power delivery
		communication for the port is mostly handled in firmware. If the
		directory exists, it will have an attribute file for every VDO
		in Discover Identity command result.

USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)

Note: Electronically Marked Cables will have a device also for one cable plug
(eg. /sys/class/typec/port0-plug0). If the cable is active and has also SOP
Double Prime controller (USB Power Deliver specification ch. 2.4) it will have
second device also for the other plug. Both plugs may have alternate modes as
described in USB Type-C and USB Power Delivery specifications.

What:		/sys/class/typec/<port>-cable/type
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:	USB Power Delivery Specification defines a set of product types
		for the cables. This file will show the product type of the
		cable if it is known. If the product type of the cable is not
		visible to the device driver, this file will not exist.

		When the cable product type is detected, uvevent is also raised
		with PRODUCT_TYPE showing the product type of the cable.

		Valid values:

		======================  ==========================
		undefined		-
		active			Active Cable
		passive			Passive Cable
		======================  ==========================

What:		/sys/class/typec/<port>-cable/plug_type
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Shows type of the plug on the cable:

		- type-a - Standard A
		- type-b - Standard B
		- type-c
		- captive

What:		/sys/class/typec/<port>-<plug>/number_of_alternate_modes
Date:		November 2020
Contact:	Prashant Malani <pmalani@chromium.org>
Description:
		Shows the number of alternate modes which are advertised by the plug
		associated with a particular cable during Power Delivery discovery.
		This file remains hidden until a value greater than or equal to 0
		is set by Type C port driver.

USB Type-C partner/cable Power Delivery Identity objects

NOTE: The following attributes will be applicable to both
partner (e.g /sys/class/typec/port0-partner/) and
cable (e.g /sys/class/typec/port0-cable/) devices. Consequently, the example file
paths below are prefixed with "/sys/class/typec/<port>-{partner|cable}/" to
reflect this.

What:		/sys/class/typec/<port>-{partner|cable}/identity/
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This directory appears only if the port device driver is capable
		of showing the result of Discover Identity USB power delivery
		command. That will not always be possible even when USB power
		delivery is supported, for example when USB power delivery
		communication for the port is mostly handled in firmware. If the
		directory exists, it will have an attribute file for every VDO
		in Discover Identity command result.

What:		/sys/class/typec/<port>-{partner|cable}/identity/id_header
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		ID Header VDO part of Discover Identity command result. The
		value will show 0 until Discover Identity command result becomes
		available. The value can be polled.

What:		/sys/class/typec/<port>-{partner|cable}/identity/cert_stat
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Cert Stat VDO part of Discover Identity command result. The
		value will show 0 until Discover Identity command result becomes
		available. The value can be polled.

What:		/sys/class/typec/<port>-{partner|cable}/identity/product
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Product VDO part of Discover Identity command result. The value
		will show 0 until Discover Identity command result becomes
		available. The value can be polled.

What:		/sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo1
Date:		October 2020
Contact:	Prashant Malani <pmalani@chromium.org>
Description:
		1st Product Type VDO of Discover Identity command result.
		The value will show 0 until Discover Identity command result becomes
		available and a valid Product Type VDO is returned.

What:		/sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo2
Date:		October 2020
Contact:	Prashant Malani <pmalani@chromium.org>
Description:
		2nd Product Type VDO of Discover Identity command result.
		The value will show 0 until Discover Identity command result becomes
		available and a valid Product Type VDO is returned.

What:		/sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo3
Date:		October 2020
Contact:	Prashant Malani <pmalani@chromium.org>
Description:
		3rd Product Type VDO of Discover Identity command result.
		The value will show 0 until Discover Identity command result becomes
		available and a valid Product Type VDO is returned.

USB Type-C port alternate mode devices.

What:		/sys/class/typec/<port>/<alt mode>/supported_roles
Date:		April 2017
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Space separated list of the supported roles.

		Valid values: source, sink

repo_name: angery/linux


code:
What:		/sys/class/usb_power_delivery
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Directory for USB Power Delivery devices.

What:		/sys/class/usb_power_delivery/.../revision
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		File showing the USB Power Delivery Specification Revision used
		in communication.

What:		/sys/class/usb_power_delivery/.../version
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This is an optional attribute file showing the version of the
		specific revision of the USB Power Delivery Specification. In
		most cases the specification version is not known and the file
		is not available.

What:		/sys/class/usb_power_delivery/.../source-capabilities
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The source capabilities message "Source_Capabilities" contains a
		set of Power Data Objects (PDO), each representing a type of
		power supply. The order of the PDO objects is defined in the USB
		Power Delivery Specification. Each PDO - power supply - will
		have its own device, and the PDO device name will start with the
		object position number as the first character followed by the
		power supply type name (":" as delimiter).

			/sys/class/usb_power_delivery/.../source_capabilities/<position>:<type>

What:		/sys/class/usb_power_delivery/.../sink-capabilities
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The sink capability message "Sink_Capabilities" contains a set
		of Power Data Objects (PDO) just like with source capabilities,
		but instead of describing the power capabilities, these objects
		describe the power requirements.

		The order of the objects in the sink capability message is the
		same as with the source capabilities message.

Fixed Supplies

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Devices containing the attributes (the bit fields) defined for
		Fixed Supplies.

		The device "1:fixed_supply" is special. USB Power Delivery
		Specification dictates that the first PDO (at object position
		1), and the only mandatory PDO, is always the vSafe5V Fixed
		Supply Object. vSafe5V Object has additional fields defined for
		it that the other Fixed Supply Objects do not have and that are
		related to the USB capabilities rather than power capabilities.

What:		/sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_power
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file contains boolean value that tells does the device
		support both source and sink power roles.

What:		/sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_suspend_supported
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file shows the value of the USB Suspend Supported bit in
		vSafe5V Fixed Supply Object. If the bit is set then the device
		will follow the USB 2.0 and USB 3.2 rules for suspend and
		resume.

What:		/sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unconstrained_power
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file shows the value of the Unconstrained Power bit in
		vSafe5V Fixed Supply Object. The bit is set when an external
		source of power, powerful enough to power the entire system on
		its own, is available for the device.

What:		/sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_communication_capable
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file shows the value of the USB Communication Capable bit in
		vSafe5V Fixed Supply Object.

What:		/sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_data
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file shows the value of the Dual-Role Data bit in vSafe5V
		Fixed Supply Object. Dual role data means ability act as both
		USB host and USB device.

What:		/sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unchunked_extended_messages_supported
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file shows the value of the Unchunked Extended Messages
		Supported bit in vSafe5V Fixed Supply Object.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply/voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The voltage the supply supports in millivolts.

What:		/sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Maximum current of the fixed source supply in milliamperes.

What:		/sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/operational_current
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Operational current of the sink in milliamperes.

What:		/sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/fast_role_swap_current
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		This file contains the value of the "Fast Role Swap USB Type-C
		Current" field that tells the current level the sink requires
		after a Fast Role Swap.
		0 - Fast Swap not supported"
		1 - Default USB Power"
		2 - 1.5A@5V"
		3 - 3.0A@5V"

Variable Supplies

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Variable Power Supply PDO.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/maximum_voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Maximum Voltage in millivolts.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/minimum_voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Minimum Voltage in millivolts.

What:		/sys/class/usb_power_delivery/.../source-capabilities/<position>:variable_supply/maximum_current
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The maximum current in milliamperes that the source can supply
		at the given Voltage range.

What:		/sys/class/usb_power_delivery/.../sink-capabilities/<position>:variable_supply/operational_current
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The operational current in milliamperes that the sink requires
		at the given Voltage range.

Battery Supplies

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:battery
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Battery PDO.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:battery/maximum_voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Maximum Voltage in millivolts.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:battery/minimum_voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Minimum Voltage in millivolts.

What:		/sys/class/usb_power_delivery/.../source-capabilities/<position>:battery/maximum_power
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Maximum allowable Power in milliwatts.

What:		/sys/class/usb_power_delivery/.../sink-capabilities/<position>:battery/operational_power
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The operational power that the sink requires at the given
		voltage range.

Standard Power Range (SPR) Programmable Power Supplies

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Programmable Power Supply (PPS) Augmented PDO (APDO).

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Maximum Voltage in millivolts.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/minimum_voltage
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Minimum Voltage in millivolts.

What:		/sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_current
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Maximum Current in milliamperes.

What:		/sys/class/usb_power_delivery/.../source-capabilities/<position>:programmable_supply/pps_power_limited
Date:		May 2022
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The PPS Power Limited bit indicates whether or not the source
		supply will exceed the rated output power if requested.


code:
What:		/sys/class/usb_role/
Date:		Jan 2018
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		Place in sysfs for USB Role Switches. USB Role Switch is a
		device that can select the data role (host or device) for USB
		port.

What:		/sys/class/usb_role/<switch>/role
Date:		Jan 2018
Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
		The current role of the switch. This attribute can be used for
		requesting role swapping with non-USB Type-C ports. With USB
		Type-C ports, the ABI defined for USB Type-C connector class
		must be used.

		Valid values:
		- none
		- host
		- device


code:
What:           /sys/class/uwb_rc
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                Interfaces for WiMedia Ultra Wideband Common Radio
                Platform (UWB) radio controllers.

                Familiarity with the ECMA-368 'High Rate Ultra
                Wideband MAC and PHY Specification' is assumed.

What:           /sys/class/uwb_rc/beacon_timeout_ms
Date:           July 2008
KernelVersion:  2.6.27
Description:
                If no beacons are received from a device for at least
                this time, the device will be considered to have gone
                and it will be removed.  The default is 3 superframes
                (~197 ms) as required by the specification.

What:           /sys/class/uwb_rc/uwb<N>/
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                An individual UWB radio controller.

What:           /sys/class/uwb_rc/uwb<N>/beacon
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                Write:

                <channel>

                to force a specific channel to be used when beaconing,
                or, if <channel> is -1, to prohibit beaconing.  If
                <channel> is 0, then the default channel selection
                algorithm will be used.  Valid channels depends on the
                radio controller's supported band groups.

                Reading returns the currently active channel, or -1 if
                the radio controller is not beaconing.

What:           /sys/class/uwb_rc/uwb<N>/ASIE
Date:           August 2014
KernelVersion:  3.18
Contact:        linux-usb@vger.kernel.org
Description:

                The application-specific information element (ASIE)
                included in this device's beacon, in space separated
                hex octets.

                Reading returns the current ASIE.  Writing replaces
                the current ASIE with the one written.

What:           /sys/class/uwb_rc/uwb<N>/scan
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                Write:

                <channel> <type> [<bpst offset>]

                to start (or stop) scanning on a channel.  <type> is one of:

		   ==   =======================================
                    0   scan
                    1   scan outside BP
                    2   scan while inactive
                    3   scanning disabled
                    4   scan (with start time of <bpst offset>)
		   ==   =======================================

What:           /sys/class/uwb_rc/uwb<N>/mac_address
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                The EUI-48, in colon-separated hex octets, for this
                radio controller.  A write will change the radio
                controller's EUI-48 but only do so while the device is
                not beaconing or scanning.

What:           /sys/class/uwb_rc/uwb<N>/wusbhc
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                A symlink to the device (if any) of the WUSB Host
                Controller PAL using this radio controller.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                A neighbour UWB device that has either been detected
                as part of a scan or is a member of the radio
                controllers beacon group.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/BPST
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                The time (using the radio controllers internal 1 ms
                interval superframe timer) of the last beacon from
                this device was received.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/DevAddr
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                The current DevAddr of this device in colon separated
                hex octets.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/EUI_48
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:

                The EUI-48 of this device in colon separated hex
                octets.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/IEs
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                The latest IEs included in this device's beacon, in
                space separated hex octets with one IE per line.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/LQE
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                Link Quality Estimate - the Signal to Noise Ratio
                (SNR) of all packets received from this device in dB.
                This gives an estimate on a suitable PHY rate. Refer
                to [ECMA-368] section 13.3 for more details.

What:           /sys/class/uwb_rc/uwb<N>/<EUI-48>/RSSI
Date:           July 2008
KernelVersion:  2.6.27
Contact:        linux-usb@vger.kernel.org
Description:
                Received Signal Strength Indication - the strength of
                the received signal in dB.  LQE is a more useful
                measure of the radio link quality.


code:
What:           /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_chid
Date:           July 2008
KernelVersion:  2.6.27
Contact:        David Vrabel <david.vrabel@csr.com>
Description:
                Write the CHID (16 space-separated hex octets) for this host controller.
                This starts the host controller, allowing it to accept connection from
                WUSB devices.

                Set an all zero CHID to stop the host controller.

What:           /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_trust_timeout
Date:           July 2008
KernelVersion:  2.6.27
Contact:        David Vrabel <david.vrabel@csr.com>
Description:
                Devices that haven't sent a WUSB packet to the host
                within 'wusb_trust_timeout' ms are considered to have
                disconnected and are removed.  The default value of
                4000 ms is the value required by the WUSB
                specification.

                Since this relates to security (specifically, the
                lifetime of PTKs and GTKs) it should not be changed
                from the default.

What:           /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_phy_rate
Date:           August 2009
KernelVersion:  2.6.32
Contact:        David Vrabel <david.vrabel@csr.com>
Description:
                The maximum PHY rate to use for all connected devices.
                This is only of limited use for testing and
                development as the hardware's automatic rate
                adaptation is better then this simple control.

                Refer to [ECMA-368] section 10.3.1.1 for the value to
                use.

What:           /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_dnts
Date:           June 2013
KernelVersion:  3.11
Contact:        Thomas Pugliese <thomas.pugliese@gmail.com>
Description:
                The device notification time slot (DNTS) count and inverval in
                milliseconds that the WUSB host should use.  This controls how
                often the devices will have the opportunity to send
                notifications to the host.

What:           /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_retry_count
Date:           June 2013
KernelVersion:  3.11
Contact:        Thomas Pugliese <thomas.pugliese@gmail.com>
Description:
                The number of retries that the WUSB host should attempt
                before reporting an error for a bus transaction.  The range of
                valid values is [0..15], where 0 indicates infinite retries.


code:
What:		/sys/class/vduse/
Date:		Oct 2021
KernelVersion:	5.15
Contact:	Yongji Xie <xieyongji@bytedance.com>
Description:
		The vduse/ class sub-directory belongs to the VDUSE
		framework and provides a sysfs interface for configuring
		VDUSE devices.

What:		/sys/class/vduse/control/
Date:		Oct 2021
KernelVersion:	5.15
Contact:	Yongji Xie <xieyongji@bytedance.com>
Description:
		This directory entry is created for the control device
		of VDUSE framework.

What:		/sys/class/vduse/<device-name>/
Date:		Oct 2021
KernelVersion:	5.15
Contact:	Yongji Xie <xieyongji@bytedance.com>
Description:
		This directory entry is created when a VDUSE device is
		created via the control device.

What:		/sys/class/vduse/<device-name>/msg_timeout
Date:		Oct 2021
KernelVersion:	5.15
Contact:	Yongji Xie <xieyongji@bytedance.com>
Description:
		(RW) The timeout (in seconds) for waiting for the control
		message's response from userspace. Default value is 30s.
		Writing a '0' to the file means to disable the timeout.


code:
What:		/sys/class/wakeup/
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		The /sys/class/wakeup/ directory contains pointers to all
		wakeup sources in the kernel at that moment in time.

What:		/sys/class/wakeup/.../name
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the name of the wakeup source.

What:		/sys/class/wakeup/.../active_count
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the number of times the wakeup source was
		activated.

What:		/sys/class/wakeup/.../event_count
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the number of signaled wakeup events
		associated with the wakeup source.

What:		/sys/class/wakeup/.../wakeup_count
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the number of times the wakeup source might
		abort suspend.

What:		/sys/class/wakeup/.../expire_count
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the number of times the wakeup source's
		timeout has expired.

What:		/sys/class/wakeup/.../active_time_ms
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the amount of time the wakeup source has
		been continuously active, in milliseconds.  If the wakeup
		source is not active, this file contains '0'.

What:		/sys/class/wakeup/.../total_time_ms
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the total amount of time this wakeup source
		has been active, in milliseconds.

What:		/sys/class/wakeup/.../max_time_ms
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the maximum amount of time this wakeup
		source has been continuously active, in milliseconds.

What:		/sys/class/wakeup/.../last_change_ms
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		This file contains the monotonic clock time when the wakeup
		source was touched last time, in milliseconds.

What:		/sys/class/wakeup/.../prevent_suspend_time_ms
Date:		June 2019
Contact:	Tri Vo <trong@android.com>
Description:
		The file contains the total amount of time this wakeup source
		has been preventing autosleep, in milliseconds.


code:
What:		/sys/class/watchdog/watchdogn/bootstatus
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It contains status of the watchdog
		device at boot. It is equivalent to WDIOC_GETBOOTSTATUS of
		ioctl interface.

What:		/sys/class/watchdog/watchdogn/identity
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It contains identity string of
		watchdog device.

What:		/sys/class/watchdog/watchdogn/nowayout
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read/write file. While reading, it gives '1'
		if the device has the nowayout feature set, otherwise
		it gives '0'. Writing a '1' to the file enables the
		nowayout feature. Once set, the nowayout feature
		cannot be disabled, so writing a '0' either has no
		effect (if the feature was already disabled) or
		results in a permission error.

What:		/sys/class/watchdog/watchdogn/state
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It gives active/inactive status of
		watchdog device.

What:		/sys/class/watchdog/watchdogn/status
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It contains watchdog device's
		internal status bits. It is equivalent to WDIOC_GETSTATUS
		of ioctl interface.

What:		/sys/class/watchdog/watchdogn/timeleft
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It contains value of time left for
		reset generation. It is equivalent to WDIOC_GETTIMELEFT of
		ioctl interface.

What:		/sys/class/watchdog/watchdogn/timeout
Date:		August 2015
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It is read to know about current
		value of timeout programmed.

What:		/sys/class/watchdog/watchdogn/pretimeout
Date:		December 2016
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It specifies the time in seconds before
		timeout when the pretimeout interrupt is delivered.  Pretimeout
		is an optional feature.

What:		/sys/class/watchdog/watchdogn/pretimeout_avaialable_governors
Date:		February 2017
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read only file. It shows the pretimeout governors
		available for this watchdog.

What:		/sys/class/watchdog/watchdogn/pretimeout_governor
Date:		February 2017
Contact:	Wim Van Sebroeck <wim@iguana.be>
Description:
		It is a read/write file. When read, the currently assigned
		pretimeout governor is returned.  When written, it sets
		the pretimeout governor.

What:		/sys/class/watchdog/watchdog1/access_cs0
Date:		August 2019
Contact:	Ivan Mikhaylov <i.mikhaylov@yadro.com>,
		Alexander Amelkin <a.amelkin@yadro.com>
Description:
		It is a read/write file. This attribute exists only if the
		system has booted from the alternate flash chip due to
		expiration of a watchdog timer of AST2400/AST2500 when
		alternate boot function was enabled with 'aspeed,alt-boot'
		devicetree option for that watchdog or with an appropriate
		h/w strapping (for WDT2 only).

		At alternate flash the 'access_cs0' sysfs node provides:

			ast2400:
				a way to get access to the primary SPI flash
				chip at CS0 after booting from the alternate
				chip at CS1.
			ast2500:
				a way to restore the normal address mapping
				from (CS0->CS1, CS1->CS0) to (CS0->CS0,
				CS1->CS1).

		Clearing the boot code selection and timeout counter also
		resets to the initial state the chip select line mapping. When
		the SoC is in normal mapping state (i.e. booted from CS0),
		clearing those bits does nothing for both versions of the SoC.
		For alternate boot mode (booted from CS1 due to wdt2
		expiration) the behavior differs as described above.

		This option can be used with wdt2 (watchdog1) only.

		When read, the current status of the boot code selection is
		shown. When written with any non-zero value, it clears
		the boot code selection and the timeout counter, which results
		in chipselect reset for AST2400/AST2500.


code:
What:		/sys/class/zram-control/
Date:		August 2015
KernelVersion:	4.2
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		The zram-control/ class sub-directory belongs to zram
		device class

What:		/sys/class/zram-control/hot_add
Date:		August 2015
KernelVersion:	4.2
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		RO attribute. Read operation will cause zram to add a new
		device and return its device id back to user (so one can
		use /dev/zram<id>), or error code.

What:		/sys/class/zram-control/hot_remove
Date:		August 2015
KernelVersion:	4.2
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		WO attribute. Remove a specific /dev/zramX device, where X
		is a device_id provided by user.


code:
What:		/sys/dev
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Dan Williams <dan.j.williams@intel.com>
Description:	The /sys/dev tree provides a method to look up the sysfs
		path for a device using the information returned from
		stat(2).  There are two directories, 'block' and 'char',
		beneath /sys/dev containing symbolic links with names of
		the form "<major>:<minor>".  These links point to the
		corresponding sysfs path for the given device.

		Example::

		  $ readlink /sys/dev/block/8:32
		  ../../block/sdc

		Entries in /sys/dev/char and /sys/dev/block will be
		dynamically created and destroyed as devices enter and
		leave the system.

Users:		mdadm <linux-raid@vger.kernel.org>

path: Documentation/ABI/testing/sysfs-dev


code:
What:		/sys/devices
Date:		February 2006
Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
		The /sys/devices tree contains a snapshot of the
		internal state of the kernel device tree.  Devices will
		be added and removed dynamically as the machine runs,
		and between different kernel versions, the layout of the
		devices within this tree will change.

		Please do not rely on the format of this tree because of
		this.  If a program wishes to find different things in
		the tree, please use the /sys/class structure and rely
		on the symlinks there to point to the proper location
		within the /sys/devices tree of the individual devices.
		Or rely on the uevent messages to notify programs of
		devices being added and removed from this tree to find
		the location of those devices.

		Note that sometimes not all devices along the directory
		chain will have emitted uevent messages, so userspace
		programs must be able to handle such occurrences.

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

path: Documentation/ABI/testing/sysfs-devices


code:
What:		/sys/devices/.../consumer:<consumer>
Date:		May 2020
Contact:	Saravana Kannan <saravanak@google.com>
Description:
		The /sys/devices/.../consumer:<consumer> are symlinks to device
		links where this device is the supplier. <consumer> denotes the
		name of the consumer in that device link and is of the form
		bus:device name. There can be zero or more of these symlinks
		for a given device.


code:
What:		/sys/devices/.../coredump
Date:		December 2017
Contact:	Arend van Spriel <aspriel@gmail.com>
Description:
		The /sys/devices/.../coredump attribute is only present when the
		device is bound to a driver, which provides the .coredump()
		callback. The attribute is write only. Anything written to this
		file will trigger the .coredump() callback.

		Available when CONFIG_DEV_COREDUMP is enabled.


code:
What:		/sys/devices/system/edac/mc/mc*/reset_counters
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This write-only control file will zero all the statistical
		counters for UE and CE errors on the given memory controller.
		Zeroing the counters will also reset the timer indicating how
		long since the last counter were reset. This is useful for
		computing errors/time.  Since the counters are always reset
		at driver initialization time, no module/kernel parameter
		is available.

What:		/sys/devices/system/edac/mc/mc*/seconds_since_reset
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays how many seconds have elapsed
		since the last counter reset. This can be used with the error
		counters to measure error rates.

What:		/sys/devices/system/edac/mc/mc*/mc_name
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the type of memory controller
		that is being utilized.

What:		/sys/devices/system/edac/mc/mc*/size_mb
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays, in count of megabytes, of memory
		that this memory controller manages.

What:		/sys/devices/system/edac/mc/mc*/ue_count
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the total count of uncorrectable
		errors that have occurred on this memory controller. If
		panic_on_ue is set, this counter will not have a chance to
		increment, since EDAC will panic the system

What:		/sys/devices/system/edac/mc/mc*/ue_noinfo_count
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the number of UEs that have
		occurred on this memory controller with no information as to
		which DIMM slot is having errors.

What:		/sys/devices/system/edac/mc/mc*/ce_count
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the total count of correctable
		errors that have occurred on this memory controller. This
		count is very important to examine. CEs provide early
		indications that a DIMM is beginning to fail. This count
		field should be monitored for non-zero values and report
		such information to the system administrator.

What:		/sys/devices/system/edac/mc/mc*/ce_noinfo_count
Date:		January 2006
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the number of CEs that
		have occurred on this memory controller wherewith no
		information as to which DIMM slot is having errors. Memory is
		handicapped, but operational, yet no information is available
		to indicate which slot the failing memory is in. This count
		field should be also be monitored for non-zero values.

What:		/sys/devices/system/edac/mc/mc*/sdram_scrub_rate
Date:		February 2007
Contact:	linux-edac@vger.kernel.org
Description:	Read/Write attribute file that controls memory scrubbing.
		The scrubbing rate used by the memory controller is set by
		writing a minimum bandwidth in bytes/sec to the attribute file.
		The rate will be translated to an internal value that gives at
		least the specified rate.
		Reading the file will return the actual scrubbing rate employed.
		If configuration fails or memory scrubbing is not implemented,
		the value of the attribute file will be -1.

What:		/sys/devices/system/edac/mc/mc*/max_location
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This attribute file displays the information about the last
		available memory slot in this memory controller. It is used by
		userspace tools in order to display the memory filling layout.

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This attribute file will display the size of dimm or rank.
		For dimm*/size, this is the size, in MB of the DIMM memory
		stick. For rank*/size, this is the size, in MB for one rank
		of the DIMM memory stick. On single rank memories (1R), this
		is also the total size of the dimm. On dual rank (2R) memories,
		this is half the size of the total DIMM memories.

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This attribute file will display what type of DRAM device is
		being utilized on this DIMM (x1, x2, x4, x8, ...).

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This attribute file will display what type of Error detection
		and correction is being utilized. For example: S4ECD4ED would
		mean a Chipkill with x4 DRAM.

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This control file allows this DIMM to have a label assigned
		to it. With this label in the module, when errors occur
		the output can provide the DIMM label in the system log.
		This becomes vital for panic events to isolate the
		cause of the UE event.
		DIMM Labels must be assigned after booting, with information
		that correctly identifies the physical slot with its
		silk screen label. This information is currently very
		motherboard specific and determination of this information
		must occur in userland at this time.

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This attribute file will display the location (csrow/channel,
		branch/channel/slot or channel/slot) of the dimm or rank.

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date:		April 2012
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
		linux-edac@vger.kernel.org
Description:	This attribute file will display what type of memory is
		currently on this csrow. Normally, either buffered or
		unbuffered memory (for example, Unbuffered-DDR3).

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_ce_count
Date:		October 2016
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the total count of correctable
		errors that have occurred on this DIMM. This count is very important
		to examine. CEs provide early indications that a DIMM is beginning
		to fail. This count field should be monitored for non-zero values
		and report such information to the system administrator.

What:		/sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_ue_count
Date:		October 2016
Contact:	linux-edac@vger.kernel.org
Description:	This attribute file displays the total count of uncorrectable
		errors that have occurred on this DIMM. If panic_on_ue is set, this
		counter will not have a chance to increment, since EDAC will panic the
		system


code:
What:		/sys/devices/.../firmware_node/
Date:		September 2012
Contact:	<>
Description:
		The /sys/devices/.../firmware_node directory contains attributes
		allowing the user space to check and modify some firmware
		related properties of given device.

What:		/sys/devices/.../firmware_node/description
Date:		September 2012
Contact:	Lance Ortiz <lance.ortiz@hp.com>
Description:
		The /sys/devices/.../firmware/description attribute contains a string
		that describes the device as provided by the _STR method in the ACPI
		namespace.  This attribute is read-only.  If the device does not have
		an _STR method associated with it in the ACPI namespace, this
		attribute is not present.


code:
What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
Date:		October 2022
KernelVersion:	6.1
Contact:	Yicong Yang <yangyicong@hisilicon.com>
Description:	This directory contains files for tuning the PCIe link
		parameters(events). Each file is named after the event
		of the PCIe link.

		See Documentation/trace/hisi-ptt.rst for more information.

What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
Date:		October 2022
KernelVersion:	6.1
Contact:	Yicong Yang <yangyicong@hisilicon.com>
Description:	(RW) Controls the weight of Tx completion TLPs, which influence
		the proportion of outbound completion TLPs on the PCIe link.
		The available tune data is [0, 1, 2]. Writing a negative value
		will return an error, and out of range values will be converted
		to 2. The value indicates a probable level of the event.

What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
Date:		October 2022
KernelVersion:	6.1
Contact:	Yicong Yang <yangyicong@hisilicon.com>
Description:	(RW) Controls the weight of Tx non-posted TLPs, which influence
		the proportion of outbound non-posted TLPs on the PCIe link.
		The available tune data is [0, 1, 2]. Writing a negative value
		will return an error, and out of range values will be converted
		to 2. The value indicates a probable level of the event.

What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
Date:		October 2022
KernelVersion:	6.1
Contact:	Yicong Yang <yangyicong@hisilicon.com>
Description:	(RW) Controls the weight of Tx posted TLPs, which influence the
		proportion of outbound posted TLPs on the PCIe link.
		The available tune data is [0, 1, 2]. Writing a negative value
		will return an error, and out of range values will be converted
		to 2. The value indicates a probable level of the event.

What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
Date:		October 2022
KernelVersion:	6.1
Contact:	Yicong Yang <yangyicong@hisilicon.com>
Description:	(RW) Control the allocated buffer watermark for inbound packets.
		The packets will be stored in the buffer first and then transmitted
		either when the watermark reached or when timed out.
		The available tune data is [0, 1, 2]. Writing a negative value
		will return an error, and out of range values will be converted
		to 2. The value indicates a probable level of the event.

What:		/sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
Date:		October 2022
KernelVersion:	6.1
Contact:	Yicong Yang <yangyicong@hisilicon.com>
Description:	(RW) Control the allocated buffer watermark of outbound packets.
		The packets will be stored in the buffer first and then transmitted
		either when the watermark reached or when timed out.
		The available tune data is [0, 1, 2]. Writing a negative value
		will return an error, and out of range values will be converted
		to 2. The value indicates a probable level of the event.


code:
What:		/sys/devices/.../lpss_ltr/
Date:		March 2013
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		The /sys/devices/.../lpss_ltr/ directory is only present for
		devices included into the Intel Lynxpoint Low Power Subsystem
		(LPSS).  If present, it contains attributes containing the LTR
		mode and the values of LTR registers of the device.

What:		/sys/devices/.../lpss_ltr/ltr_mode
Date:		March 2013
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
		integer number (0 or 1) indicating whether or not the devices'
		LTR functionality is working in the software mode (1).

		This attribute is read-only.  If the device's runtime PM status
		is not "active", attempts to read from this attribute cause
		-EAGAIN to be returned.

What:		/sys/devices/.../lpss_ltr/auto_ltr
Date:		March 2013
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
		current value of the device's AUTO_LTR register (raw)
		represented as an 8-digit hexadecimal number.

		This attribute is read-only.  If the device's runtime PM status
		is not "active", attempts to read from this attribute cause
		-EAGAIN to be returned.

What:		/sys/devices/.../lpss_ltr/sw_ltr
Date:		March 2013
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
		current value of the device's SW_LTR register (raw) represented
		as an 8-digit hexadecimal number.

		This attribute is read-only.  If the device's runtime PM status
		is not "active", attempts to read from this attribute cause
		-EAGAIN to be returned.


code:
What:           /sys/devices/uncore_iio_x/dieX
Date:           February 2020
Contact:        Alexander Antonov <alexander.antonov@linux.intel.com>
Description:
                Each IIO stack (PCIe root port) has its own IIO PMON block, so
                each dieX file (where X is die number) holds "Segment:Root Bus"
                for PCIe root port, which can be monitored by that IIO PMON
                block.
                For example, on 4-die Xeon platform with up to 6 IIO stacks per
                die and, therefore, 6 IIO PMON blocks per die, the mapping of
                IIO PMON block 0 exposes as the following::

		    $ ls /sys/devices/uncore_iio_0/die*
		    -r--r--r-- /sys/devices/uncore_iio_0/die0
		    -r--r--r-- /sys/devices/uncore_iio_0/die1
		    -r--r--r-- /sys/devices/uncore_iio_0/die2
		    -r--r--r-- /sys/devices/uncore_iio_0/die3

		    $ tail /sys/devices/uncore_iio_0/die*
		    ==> /sys/devices/uncore_iio_0/die0 <==
		    0000:00
		    ==> /sys/devices/uncore_iio_0/die1 <==
		    0000:40
		    ==> /sys/devices/uncore_iio_0/die2 <==
		    0000:80
		    ==> /sys/devices/uncore_iio_0/die3 <==
		    0000:c0

                Which means::

		    IIO PMU 0 on die 0 belongs to PCI RP on bus 0x00, domain 0x0000
		    IIO PMU 0 on die 1 belongs to PCI RP on bus 0x40, domain 0x0000
		    IIO PMU 0 on die 2 belongs to PCI RP on bus 0x80, domain 0x0000
		    IIO PMU 0 on die 3 belongs to PCI RP on bus 0xc0, domain 0x0000

What:           /sys/devices/uncore_upi_x/dieX
Date:           March 2022
Contact:        Alexander Antonov <alexander.antonov@linux.intel.com>
Description:
                Each /sys/devices/uncore_upi_X/dieY file holds "upi_Z,die_W"
                value that means UPI link number X on die Y is connected to UPI
                link Z on die W and this link between sockets can be monitored
                by UPI PMON block.
                For example, 4-die Sapphire Rapids platform has the following
                UPI 0 topology::

		    # tail /sys/devices/uncore_upi_0/die*
		    ==> /sys/devices/uncore_upi_0/die0 <==
		    upi_1,die_1
		    ==> /sys/devices/uncore_upi_0/die1 <==
		    upi_0,die_3
		    ==> /sys/devices/uncore_upi_0/die2 <==
		    upi_1,die_3
		    ==> /sys/devices/uncore_upi_0/die3 <==
		    upi_0,die_1

                Which means::

		    UPI link 0 on die 0 is connected to UPI link 1 on die 1
		    UPI link 0 on die 1 is connected to UPI link 0 on die 3
		    UPI link 0 on die 2 is connected to UPI link 1 on die 3
		    UPI link 0 on die 3 is connected to UPI link 0 on die 1


code:
What:		/sys/devices/system/memory
Date:		June 2008
Contact:	Badari Pulavarty <pbadari@us.ibm.com>
Description:
		The /sys/devices/system/memory contains a snapshot of the
		internal state of the kernel memory blocks. Files could be
		added or removed dynamically to represent hot-add/remove
		operations.
Users:		hotplug memory add/remove tools
		http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils

What:		/sys/devices/system/memory/memoryX/removable
Date:		June 2008
Contact:	Badari Pulavarty <pbadari@us.ibm.com>
Description:
		The file /sys/devices/system/memory/memoryX/removable is a
		legacy interface used to indicated whether a memory block is
		likely to be offlineable or not.  Newer kernel versions return
		"1" if and only if the kernel supports memory offlining.
Users:		hotplug memory remove tools
		http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
		lsmem/chmem part of util-linux

What:		/sys/devices/system/memory/memoryX/phys_device
Date:		September 2008
Contact:	Badari Pulavarty <pbadari@us.ibm.com>
Description:
		The file /sys/devices/system/memory/memoryX/phys_device
		is read-only;  it is a legacy interface only ever used on s390x
		to expose the covered storage increment.
Users:		Legacy s390-tools lsmem/chmem

What:		/sys/devices/system/memory/memoryX/phys_index
Date:		September 2008
Contact:	Badari Pulavarty <pbadari@us.ibm.com>
Description:
		The file /sys/devices/system/memory/memoryX/phys_index
		is read-only and contains the section ID in hexadecimal
		which is equivalent to decimal X contained in the
		memory section directory name.

What:		/sys/devices/system/memory/memoryX/state
Date:		September 2008
Contact:	Badari Pulavarty <pbadari@us.ibm.com>
Description:
		The file /sys/devices/system/memory/memoryX/state
		is read-write.  When read, it returns the online/offline
		state of the memory block.  When written, root can toggle
		the online/offline state of a memory block using the following
		commands::

		  # echo online > /sys/devices/system/memory/memoryX/state
		  # echo offline > /sys/devices/system/memory/memoryX/state

		On newer kernel versions, advanced states can be specified
		when onlining to select a target zone: "online_movable"
		selects the movable zone.  "online_kernel" selects the
		applicable kernel zone (DMA, DMA32, or Normal).  However,
		after successfully setting one of the advanced states,
		reading the file will return "online"; the zone information
		can be obtained via "valid_zones" instead.

		While onlining is unlikely to fail, there are no guarantees
		that offlining will succeed.  Offlining is more likely to
		succeed if "valid_zones" indicates "Movable".
Users:		hotplug memory remove tools
		http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils

What:           /sys/devices/system/memory/memoryX/valid_zones
Date:           July 2014
Contact:	Zhang Zhen <zhenzhang.zhang@huawei.com>
Description:
		The file /sys/devices/system/memory/memoryX/valid_zones	is
		read-only.

		For online memory blocks, it returns in which zone memory
		provided by a memory block is managed.  If multiple zones
		apply (not applicable for hotplugged memory), "None" is returned
		and the memory block cannot be offlined.

		For offline memory blocks, it returns by which zone memory
		provided by a memory block can be managed when onlining.
		The first returned zone ("default") will be used when setting
		the state of an offline memory block to "online".  Only one of
		the kernel zones (DMA, DMA32, Normal) is applicable for a single
		memory block.

What:		/sys/devices/system/memoryX/nodeY
Date:		October 2009
Contact:	Linux Memory Management list <linux-mm@kvack.org>
Description:
		When CONFIG_NUMA is enabled, a symbolic link that
		points to the corresponding NUMA node directory.

		For example, the following symbolic link is created for
		memory section 9 on node0:

		/sys/devices/system/memory/memory9/node0 -> ../../node/node0

What:		/sys/devices/system/node/nodeX/memoryY
Date:		September 2008
Contact:	Gary Hade <garyhade@us.ibm.com>
Description:
		When CONFIG_NUMA is enabled
		/sys/devices/system/node/nodeX/memoryY is a symbolic link that
		points to the corresponding /sys/devices/system/memory/memoryY
		memory section directory.  For example, the following symbolic
		link is created for memory section 9 on node0.

		/sys/devices/system/node/node0/memory9 -> ../../memory/memory9


code:
What:		/sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_offset
Date:		January 2011
Contact:	Chuanxiao Dong <chuanxiao.dong@intel.com>
Description:
		Enhanced area is a new feature defined in eMMC4.4 standard.
		eMMC4.4 or later card can support such feature. This kind of
		area can help to improve the card performance. If the feature
		is enabled, this attribute will indicate the start address of
		enhanced data area. If not, this attribute will be -EINVAL.
		Unit Byte. Format decimal.

What:		/sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_size
Date:		January 2011
Contact:	Chuanxiao Dong <chuanxiao.dong@intel.com>
Description:
		Enhanced area is a new feature defined in eMMC4.4 standard.
		eMMC4.4 or later card can support such feature. This kind of
		area can help to improve the card performance. If the feature
		is enabled, this attribute will indicate the size of enhanced
		data area. If not, this attribute will be -EINVAL.
		Unit KByte. Format decimal.


code:
What:		/sys/devices/.../online
Date:		April 2013
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		The /sys/devices/.../online attribute is only present for
		devices whose bus types provide .online() and .offline()
		callbacks.  The number read from it (0 or 1) reflects the value
		of the device's 'offline' field.  If that number is 1 and '0'
		(or 'n', or 'N') is written to this file, the device bus type's
		.offline() callback is executed for the device and (if
		successful) its 'offline' field is updated accordingly.  In
		turn, if that number is 0 and '1' (or 'y', or 'Y') is written to
		this file, the device bus type's .online() callback is executed
		for the device and (if successful) its 'offline' field is
		updated as appropriate.

		After a successful execution of the bus type's .offline()
		callback the device cannot be used for any purpose until either
		it is removed (i.e. device_del() is called for it), or its bus
		type's .online() is exeucted successfully.


code:
What:		/sys/devices/.../physical_location
Date:		March 2022
Contact:	Won Chung <wonchung@google.com>
Description:
		This directory contains information on physical location of
		the device connection point with respect to the system's
		housing.

What:		/sys/devices/.../physical_location/panel
Date:		March 2022
Contact:	Won Chung <wonchung@google.com>
Description:
		Describes which panel surface of the system’s housing the
		device connection point resides on.

What:		/sys/devices/.../physical_location/vertical_position
Date:		March 2022
Contact:	Won Chung <wonchung@google.com>
Description:
		Describes vertical position of the device connection point on
		the panel surface.

What:		/sys/devices/.../physical_location/horizontal_position
Date:		March 2022
Contact:	Won Chung <wonchung@google.com>
Description:
		Describes horizontal position of the device connection point on
		the panel surface.

What:		/sys/devices/.../physical_location/dock
Date:		March 2022
Contact:	Won Chung <wonchung@google.com>
Description:
		"Yes" if the device connection point resides in a docking
		station or a port replicator. "No" otherwise.

What:		/sys/devices/.../physical_location/lid
Date:		March 2022
Contact:	Won Chung <wonchung@google.com>
Description:
		"Yes" if the device connection point resides on the lid of
		laptop system. "No" otherwise.


code:
		ACPI Time and Alarm (TAD) device attributes.

What:		/sys/bus/platform/devices/ACPI000E:00/caps
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		(RO) Hexadecimal bitmask of the TAD attributes are reported by
		the platform firmware (see ACPI 6.2, section 9.18.2):

		======= ======================================================
		BIT(0): AC wakeup implemented if set
		BIT(1): DC wakeup implemented if set
		BIT(2): Get/set real time features implemented if set
		BIT(3): Real time accuracy in milliseconds if set
		BIT(4): Correct status reported for wakeups from S4/S5 if set
		BIT(5): The AC timer wakes up from S4 if set
		BIT(6): The AC timer wakes up from S5 if set
		BIT(7): The DC timer wakes up from S4 if set
		BIT(8): The DC timer wakes up from S5 if set
		======= ======================================================

		The other bits are reserved.

What:		/sys/bus/platform/devices/ACPI000E:00/ac_alarm
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		(RW) The AC alarm timer value.

		Reads return the current AC alarm timer value in seconds or
		"disabled", if the AC alarm is not set to wake up the system.

		Write a new AC alarm timer value in seconds or "disabled" to it
		to set the AC alarm timer or to disable it, respectively.

		If the AC alarm timer is set through this attribute and it
		expires, it will immediately wake up the system from the S3
		sleep state (and from S4/S5 too if supported) until its status
		is explicitly cleared via the ac_status attribute.

What:		/sys/bus/platform/devices/ACPI000E:00/ac_policy
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		(RW) The AC alarm expired timer wake policy (see ACPI 6.2,
		Section 9.18 for details).

		Reads return the current expired timer wake delay for the AC
		alarm timer or "never", if the policy is to discard AC timer
		wakeups if the system is on DC power.

		Write a new expired timer wake delay for the AC alarm timer in
		seconds or "never" to it to set the expired timer wake delay for
		the AC alarm timer or to set its expired wake policy to discard
		wakeups if the system is on DC power, respectively.

What:		/sys/bus/platform/devices/ACPI000E:00/ac_status
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		(RW) The AC alarm status.

		Reads return a hexadecimal bitmask representing the AC alarm
		timer status with the following meaning of bits (see ACPI 6.2,
		Section 9.18.5):

		======= ======================================================
		Bit(0): The timer has expired if set.
		Bit(1): The timer has woken up the system from a sleep state
		        (S3 or S4/S5 if supported) if set.
		======= ======================================================

		The other bits are reserved.

		Reads also cause the AC alarm timer status to be reset.

		Another way to reset the status of the AC alarm timer is to
		write (the number) 0 to this file.

		If the status return value indicates that the timer has expired,
		it will immediately wake up the system from the S3 sleep state
		(and from S4/S5 too if supported) until its status is explicitly
		cleared through this attribute.

What:		/sys/bus/platform/devices/ACPI000E:00/dc_alarm
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		(RW,optional) The DC alarm timer value.

		This attribute is only present if the TAD supports a separate
		DC timer.

		It is analogous to the ac_alarm attribute.

What:		/sys/bus/platform/devices/ACPI000E:00/dc_policy
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
		(RW,optional) The DC alarm expired timer wake policy.

		This attribute is only present if the TAD supports a separate
		DC timer.

		It is analogous to the ac_policy attribute.

What:		/sys/bus/platform/devices/ACPI000E:00/dc_status
Date:		March 2018
Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Description:
		(RW,optional) The DC alarm status.

		This attribute is only present if the TAD supports a separate
		DC timer.

		It is analogous to the ac_status attribute.


code:
What:		/sys/devices/platform/_UDC_/gadget/suspended
Date:		April 2010
Contact:	Fabien Chouteau <fabien.chouteau@barco.com>
Description:
		Show the suspend state of an USB composite gadget.

		- 1 -> suspended
		- 0 -> resumed

		(_UDC_ is the name of the USB Device Controller driver)

What:           /sys/devices/platform/_UDC_/gadget/gadget-lunX/nofua
Date:           July 2010
Contact:        Andy Shevchenko <andy.shevchenko@gmail.com>
Description:
		Show or set the reaction on the FUA (Force Unit Access) bit in
		the SCSI WRITE(10,12) commands when a gadget in USB Mass
		Storage mode.

		Possible values are:

			- 1 -> ignore the FUA flag
			- 0 -> obey the FUA flag


code:
What:		/sys/devices/platform/docg3/f[0-3]_dps[01]_is_keylocked
Date:		November 2011
KernelVersion:	3.3
Contact:	Robert Jarzmik <robert.jarzmik@free.fr>
Description:
		Show whether the floor (0 to 4), protection area (0 or 1) is
		keylocked. Each docg3 chip (or floor) has 2 protection areas,
		which can cover any part of it, block aligned, called DPS.
		The protection has information embedded whether it blocks reads,
		writes or both.
		The result is:

		- 0 -> the DPS is not keylocked
		- 1 -> the DPS is keylocked

Users:		None identified so far.

What:		/sys/devices/platform/docg3/f[0-3]_dps[01]_protection_key
Date:		November 2011
KernelVersion:	3.3
Contact:	Robert Jarzmik <robert.jarzmik@free.fr>
Description:
		Enter the protection key for the floor (0 to 4), protection area
		(0 or 1). Each docg3 chip (or floor) has 2 protection areas,
		which can cover any part of it, block aligned, called DPS.
		The protection has information embedded whether it blocks reads,
		writes or both.
		The protection key is a string of 8 bytes (value 0-255).
		Entering the correct value toggle the lock, and can be observed
		through f[0-3]_dps[01]_is_keylocked.
		Possible values are:

			- 8 bytes

		Typical values are:

			- "00000000"
			- "12345678"

Users:		None identified so far.


code:
What:		/sys/devices/platform/dock.<N>/docked
Date:		Dec, 2006
KernelVersion:	2.6.19
Contact:	linux-acpi@vger.kernel.org
Description:
		(RO) Value 1 or 0 indicates whether the software believes the
		laptop is docked in a docking station.

What:		/sys/devices/platform/dock.<N>/undock
Date:		Dec, 2006
KernelVersion:	2.6.19
Contact:	linux-acpi@vger.kernel.org
Description:
		(WO) Writing to this file causes the software to initiate an
		undock request to the firmware.

What:		/sys/devices/platform/dock.<N>/uid
Date:		Feb, 2007
KernelVersion:	v2.6.21
Contact:	linux-acpi@vger.kernel.org
Description:
		(RO) Displays the docking station the laptop is docked to.

What:		/sys/devices/platform/dock.<N>/flags
Date:		May, 2007
KernelVersion:	v2.6.21
Contact:	linux-acpi@vger.kernel.org
Description:
		(RO) Show dock station flags, useful for checking if undock
		request has been made by the user (from the immediate_undock
		option).

What:		/sys/devices/platform/dock.<N>/type
Date:		Aug, 2008
KernelVersion:	v2.6.27
Contact:	linux-acpi@vger.kernel.org
Description:
		(RO) Display the dock station type- dock_station, ata_bay or
		battery_bay.


code:
What:		/sys/devices/platform/ipmi_bmc.*/firmware_revision
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) The major and minor revision of the firmware.

What:		/sys/devices/platform/ipmi_bmc.*/aux_firmware_revision
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Holds additional information about the firmware revision,
		such as boot block or internal data structure version numbers.
		The meanings of the numbers are specific to the vendor
		identified by Manufacturer ID.

What:		/sys/devices/platform/ipmi_bmc.*/revision
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Device revision. Useful for identifying if significant
		hardware changes have been made to the implementation of the
		management controller.

What:		/sys/devices/platform/ipmi_bmc.*/provides_device_sdrs
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Indicates whether device provides device sensor data
		records (1) or not (0).

What:		/sys/devices/platform/ipmi_bmc.*/device_id
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Device id is specified by the manufacturer identified by
		the Manufacturer ID field. This field allows controller specific
		software to identify the unique application command, OEM
		fields, and functionality that are provided by the controller

What:		/sys/devices/platform/ipmi_bmc.*/additional_device_support
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Lists the IPMI ‘logical device’ commands and functions
		that the controller supports that are in addition to the
		mandatory IPM and Application commands.

What:		/sys/devices/platform/ipmi_bmc.*/ipmi_version
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Displays the IPMI Command Specification Version.

What:		/sys/devices/platform/ipmi_bmc.*/manufacturer_id
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Identifies the manufacturer responsible for the
		specification of functionality of the vendor (OEM)-specific
		commands, codes, and interfaces used in the controller.

What:		/sys/devices/platform/ipmi_bmc.*/product_id
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Displays a number that identifies a particular system,
		module, add-in card, or board set. The number is specified
		according to the manufacturer given by Manufacturer ID.

For detailed definitions of the above attributes, refer to section 20.1 'Get
Device ID Command' of the IPMI specification v2.0.

What:		/sys/devices/platform/ipmi_bmc.*/guid
Date:		Mar, 2006
KernelVersion:	v2.6.17
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) A GUID (Globally Unique ID), also referred to as a UUID
		(Universally Unique Identifier), for the management controller,
		as described in section 20.8 'Get Device GUID Command' of the
		IPMI specification v2.0.

What:		/sys/devices/platform/ipmi_si.*/type
Date:		Sep, 2017
KernelVersion:	v4.15
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) The device interface for IPMI "kcs", "smic", "bt" or
		"invalid"

What:		/sys/devices/platform/ipmi_si.*/idles
What:		/sys/devices/platform/ipmi_si.*/watchdog_pretimeouts
What:		/sys/devices/platform/ipmi_si.*/complete_transactions
What:		/sys/devices/platform/ipmi_si.*/events
What:		/sys/devices/platform/ipmi_si.*/interrupts
What:		/sys/devices/platform/ipmi_si.*/hosed_count
What:		/sys/devices/platform/ipmi_si.*/long_timeouts
What:		/sys/devices/platform/ipmi_si.*/flag_fetches
What:		/sys/devices/platform/ipmi_si.*/attentions
What:		/sys/devices/platform/ipmi_si.*/incoming_messages
What:		/sys/devices/platform/ipmi_si.*/short_timeouts
Date:		Sep, 2017
KernelVersion:	v4.15
Contact:	openipmi-developer@lists.sourceforge.net
Description:

		======================	========================================
		idles			(RO) Number of times the interface was
					idle while being polled.

		watchdog_pretimeouts	(RO) Number of watchdog pretimeouts.

		complete_transactions	(RO) Number of completed messages.

		events			(RO) Number of IPMI events received from
					the hardware.

		interrupts		(RO) Number of interrupts the driver
					handled.

		hosed_count		(RO) Number of times the hardware didn't
					follow the state machine.

		long_timeouts		(RO) Number of times the driver
					requested a timer while nothing was in
					progress.

		flag_fetches		(RO) Number of times the driver
					requested flags from the hardware.

		attentions		(RO) Number of time the driver got an
					ATTN from the hardware.

		incoming_messages	(RO) Number of asynchronous messages
					received.

		short_timeouts		(RO) Number of times the driver
					requested a timer while an operation was
					in progress.
		======================	========================================

What:		/sys/devices/platform/ipmi_si.*/interrupts_enabled
Date:		Sep, 2017
KernelVersion:	v4.15
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Indicates whether interrupts are enabled or not. The driver
		disables interrupts when it gets into a situation where it
		cannot handle messages due to lack of memory. Once that
		situation clears up, it will re-enable interrupts.

What:		/sys/devices/platform/ipmi_si.*/params
Date:		Sep, 2017
KernelVersion:	v4.15
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		[to be documented]

What:		/sys/devices/platform/dmi-ipmi-ssif.*/type
Date:		Sep, 2017
KernelVersion:	v4.15
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		(RO) Shows the IMPI device interface type - "ssif" here.

What:		/sys/devices/platform/dmi-ipmi-ssif.*/hosed
What:		/sys/devices/platform/dmi-ipmi-ssif.*/alerts
What:		/sys/devices/platform/dmi-ipmi-ssif.*/sent_messages
What:		/sys/devices/platform/dmi-ipmi-ssif.*/sent_messages_parts
What:		/sys/devices/platform/dmi-ipmi-ssif.*/received_messages
What:		/sys/devices/platform/dmi-ipmi-ssif.*/received_message_parts
What:		/sys/devices/platform/dmi-ipmi-ssif.*/events
What:		/sys/devices/platform/dmi-ipmi-ssif.*/watchdog_pretimeouts
What:		/sys/devices/platform/dmi-ipmi-ssif.*/flag_fetches
What:		/sys/devices/platform/dmi-ipmi-ssif.*/send_retries
What:		/sys/devices/platform/dmi-ipmi-ssif.*/receive_retries
What:		/sys/devices/platform/dmi-ipmi-ssif.*/send_errors
What:		/sys/devices/platform/dmi-ipmi-ssif.*/receive_errors
Date:		Sep, 2017
KernelVersion:	v4.15
Contact:	openipmi-developer@lists.sourceforge.net
Description:
		======================	========================================
		hosed			(RO) Number of times the hardware didn't
					follow the state machine.

		alerts			(RO) Number of alerts received.

		sent_messages		(RO) Number of total messages sent.

		sent_message_parts	(RO) Number of message parts sent.
					Messages may be broken into parts if
					they are long.

		received_messages	(RO) Number of message responses
					received.

		received_message_parts	(RO) Number of message fragments
					received.

		events			(RO) Number of received events.

		watchdog_pretimeouts	(RO) Number of watchdog pretimeouts.

		flag_fetches		(RO) Number of times a flag fetch was
					requested.

		send_retries		(RO) Number of time a message was
					retried.

		receive_retries		(RO) Number of times the receive of a
					message was retried.

		send_errors		(RO) Number of times the send of a
					message failed.

		receive_errors		(RO) Number of errors in receiving
					messages.
		======================	========================================


code:
What:		/sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_alpha
Date:		May 2012
Contact:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
		This file is only available on fb[0-9] devices corresponding
		to overlay planes.

		Stores the alpha blending value for the overlay. Values range
		from 0 (transparent) to 255 (opaque). The value is ignored if
		the mode is not set to Alpha Blending.

What:		/sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_mode
Date:		May 2012
Contact:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
		This file is only available on fb[0-9] devices corresponding
		to overlay planes.

		Selects the composition mode for the overlay. Possible values
		are:

		- 0 - Alpha Blending
		- 1 - ROP3

What:		/sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_position
Date:		May 2012
Contact:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
		This file is only available on fb[0-9] devices corresponding
		to overlay planes.

		Stores the x,y overlay position on the display in pixels. The
		position format is `[0-9]+,[0-9]+`.

What:		/sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_rop3
Date:		May 2012
Contact:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
		This file is only available on fb[0-9] devices corresponding
		to overlay planes.

		Stores the raster operation (ROP3) for the overlay. Values
		range from 0 to 255. The value is ignored if the mode is not
		set to ROP3.


code:
What:		/sys/devices/platform/soc@X/XXXXXXX.ipa/
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The /sys/devices/platform/soc@X/XXXXXXX.ipa/ directory
		contains read-only attributes exposing information about
		an IPA device.  The X values could vary, but are typically
		"soc@0/1e40000.ipa".

What:		.../XXXXXXX.ipa/version
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/version file contains the IPA hardware
		version, as a period-separated set of two or three integers
		(e.g., "3.5.1" or "4.2").

What:		.../XXXXXXX.ipa/feature/
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/feature/ directory contains a set of
		attributes describing features implemented by the IPA
		hardware.

What:		.../XXXXXXX.ipa/feature/rx_offload
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/feature/rx_offload file contains a
		string indicating the type of receive checksum offload
		that is supported by the hardware.  The possible values
		are "MAPv4" or "MAPv5".

What:		.../XXXXXXX.ipa/feature/tx_offload
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/feature/tx_offload file contains a
		string indicating the type of transmit checksum offload
		that is supported by the hardware.  The possible values
		are "MAPv4" or "MAPv5".

What:		.../XXXXXXX.ipa/endpoint_id/
Date:		July 2022
KernelVersion:	v5.19
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/endpoint_id/ directory contains
		attributes that define IDs associated with IPA
		endpoints.  The "rx" or "tx" in an endpoint name is
		from the perspective of the AP.  An endpoint ID is a
		small unsigned integer.

What:		.../XXXXXXX.ipa/endpoint_id/modem_rx
Date:		July 2022
KernelVersion:	v5.19
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/endpoint_id/modem_rx file contains
		the ID of the AP endpoint on which packets originating
		from the embedded modem are received.

What:		.../XXXXXXX.ipa/endpoint_id/modem_tx
Date:		July 2022
KernelVersion:	v5.19
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/endpoint_id/modem_tx file contains
		the ID of the AP endpoint on which packets destined
		for the embedded modem are sent.

What:		.../XXXXXXX.ipa/endpoint_id/monitor_rx
Date:		July 2022
KernelVersion:	v5.19
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/endpoint_id/monitor_rx file contains
		the ID of the AP endpoint on which IPA "monitor" data is
		received.  The monitor endpoint supplies replicas of
		packets that enter the IPA hardware for processing.
		Each replicated packet is preceded by a fixed-size "ODL"
		header (see .../XXXXXXX.ipa/feature/monitor, above).
		Large packets are truncated, to reduce the bandwidth
		required to provide the monitor function.

What:		.../XXXXXXX.ipa/modem/
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/modem/ directory contains attributes
		describing properties of the modem embedded in the SoC.

What:		.../XXXXXXX.ipa/modem/rx_endpoint_id
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/modem/rx_endpoint_id file duplicates
		the value found in .../XXXXXXX.ipa/endpoint_id/modem_rx.

What:		.../XXXXXXX.ipa/modem/tx_endpoint_id
Date:		June 2021
KernelVersion:	v5.14
Contact:	Alex Elder <elder@kernel.org>
Description:
		The .../XXXXXXX.ipa/modem/tx_endpoint_id file duplicates
		the value found in .../XXXXXXX.ipa/endpoint_id/modem_tx.


code:
	Intel Stratix10 Remote System Update (RSU) device attributes

What:		/sys/devices/platform/stratix10-rsu.0/current_image
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) the address in flash of currently running image.

What:		/sys/devices/platform/stratix10-rsu.0/fail_image
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) the address in flash of failed image.

What:		/sys/devices/platform/stratix10-rsu.0/state
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) the state of RSU system.
		The state field has two parts: major error code in
		upper 16 bits and minor error code in lower 16 bits.

		b[15:0]
			Currently used only when major error is 0xF006
			(CPU watchdog timeout), in which case the minor
			error code is the value reported by CPU to
			firmware through the RSU notify command before
			the watchdog timeout occurs.

		b[31:16]
			0xF001	bitstream error
			0xF002	hardware access failure
			0xF003	bitstream corruption
			0xF004	internal error
			0xF005	device error
			0xF006	CPU watchdog timeout
			0xF007	internal unknown error

What:		/sys/devices/platform/stratix10-rsu.0/version
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) the version number of RSU firmware. 19.3 or late
		version includes information about the firmware which
		reported the error.

		pre 19.3:
			b[31:0]
				0x0	version number

		19.3 or late:
			b[15:0]
				0x1	version number
			b[31:16]
				0x0	no error
				0x0DCF	Decision CMF error
				0x0ACF	Application CMF error

What:		/sys/devices/platform/stratix10-rsu.0/error_location
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) the error offset inside the image that failed.

What:		/sys/devices/platform/stratix10-rsu.0/error_details
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) error code.

What:		/sys/devices/platform/stratix10-rsu.0/retry_counter
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) the current image's retry counter, which is used by
		user to know how many times the images is still allowed
		to reload itself before giving up and starting RSU
		fail-over flow.

What:		/sys/devices/platform/stratix10-rsu.0/reboot_image
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(WO) the address in flash of image to be loaded on next
		reboot command.

What:		/sys/devices/platform/stratix10-rsu.0/notify
Date:		August 2019
KernelVersion:	5.4
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(WO) client to notify firmware with different actions.

		b[15:0]
			inform firmware the current software execution
			stage.

			==	===========================================
			0	the first stage bootloader didn't run or
				didn't reach the point of launching second
				stage bootloader.
			1	failed in second bootloader or didn't get
				to the point of launching the operating
				system.
			2	both first and second stage bootloader ran
				and the operating system launch was
				attempted.
			==	===========================================

		b[16]
			==	===========================================
			1	firmware to reset current image retry
				counter.
			0	no action.
			==	===========================================

		b[17]
			==	===========================================
			1	firmware to clear RSU log
			0	no action.
			==	===========================================

		b[18]
			this is negative logic

			==	===========================================
			1	no action
			0	firmware record the notify code defined
				in b[15:0].
			==	===========================================

What:		/sys/devices/platform/stratix10-rsu.0/dcmf0
Date:		June 2020
KernelVersion:	5.8
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) Decision firmware copy 0 version information.

What:		/sys/devices/platform/stratix10-rsu.0/dcmf1
Date:		June 2020
KernelVersion:	5.8
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) Decision firmware copy 1 version information.

What:		/sys/devices/platform/stratix10-rsu.0/dcmf2
Date:		June 2020
KernelVersion:	5.8
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) Decision firmware copy 2 version information.

What:		/sys/devices/platform/stratix10-rsu.0/dcmf3
Date:		June 2020
KernelVersion:	5.8
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) Decision firmware copy 3 version information.

What:		/sys/devices/platform/stratix10-rsu.0/max_retry
Date:		June 2020
KernelVersion:	5.8
Contact:	Richard Gong <richard.gong@linux.intel.com>
Description:
		(RO) max retry parameter is stored in the firmware
		decision IO section, as a byte located at offset 0x18c.