code:
**General Properties**

What:		/sys/class/power_supply/<supply_name>/manufacturer
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the name of the device manufacturer.

		Access: Read
		Valid values: Represented as string

What:		/sys/class/power_supply/<supply_name>/model_name
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the name of the device model.

		Access: Read
		Valid values: Represented as string

What:		/sys/class/power_supply/<supply_name>/serial_number
Date:		January 2008
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the serial number of the device.

		Access: Read
		Valid values: Represented as string

What:		/sys/class/power_supply/<supply_name>/type
Date:		May 2010
Contact:	linux-pm@vger.kernel.org
Description:
		Describes the main type of the supply.

		Access: Read
		Valid values: "Battery", "UPS", "Mains", "USB", "Wireless"

**Battery and USB properties**

What:		/sys/class/power_supply/<supply_name>/current_avg
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports an average IBAT current reading for the battery, over
		  a fixed period. Normally devices will provide a fixed interval
		  in which they average readings to smooth out the reported
		  value.

		USB:

		  Reports an average IBUS current reading over a fixed period.
		  Normally devices will provide a fixed interval in which they
		  average readings to smooth out the reported value.

		Access: Read

		Valid values: Represented in microamps. Negative values are
		used for discharging batteries, positive values for charging
		batteries and for USB IBUS current.

What:		/sys/class/power_supply/<supply_name>/current_max
Date:		October 2010
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports the maximum IBAT current allowed into the battery.

		USB:

		  Reports the maximum IBUS current the supply can support.

		Access: Read
		Valid values: Represented in microamps

What: 		/sys/class/power_supply/<supply_name>/current_now
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:

		Battery:

		  Reports an instant, single IBAT current reading for the
		  battery. This value is not averaged/smoothed.

		  Access: Read

		USB:

		  Reports the IBUS current supplied now. This value is generally
		  read-only reporting, unless the 'online' state of the supply
		  is set to be programmable, in which case this value can be set
		  within the reported min/max range.

		  Access: Read, Write

		Valid values: Represented in microamps. Negative values are
		used for discharging batteries, positive values for charging
		batteries and for USB IBUS current.

What:		/sys/class/power_supply/<supply_name>/temp
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports the current TBAT battery temperature reading.

		USB:

		  Reports the current supply temperature reading. This would
		  normally be the internal temperature of the device itself
		  (e.g TJUNC temperature of an IC)

		Access: Read

		Valid values: Represented in 1/10 Degrees Celsius

What:		/sys/class/power_supply/<supply_name>/temp_alert_max
Date:		July 2012
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Maximum TBAT temperature trip-wire value where the supply will
		  notify user-space of the event.

		USB:

		  Maximum supply temperature trip-wire value where the supply
		  will notify user-space of the event.

		This is normally used for the charging scenario where
		user-space needs to know if the temperature has crossed an
		upper threshold so it can take appropriate action (e.g. warning
		user that the temperature is critically high, and charging has
		stopped).

		Access: Read

		Valid values: Represented in 1/10 Degrees Celsius

What:		/sys/class/power_supply/<supply_name>/temp_alert_min
Date:		July 2012
Contact:	linux-pm@vger.kernel.org
Description:

		Battery:

		  Minimum TBAT temperature trip-wire value where the supply will
		  notify user-space of the event.

		USB:

		  Minimum supply temperature trip-wire value where the supply
		  will notify user-space of the event.

		This is normally used for the charging scenario where user-space
		needs to know if the temperature has crossed a lower threshold
		so it can take appropriate action (e.g. warning user that
		temperature level is high, and charging current has been
		reduced accordingly to remedy the situation).

		Access: Read

		Valid values: Represented in 1/10 Degrees Celsius

What:		/sys/class/power_supply/<supply_name>/temp_max
Date:		July 2014
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports the maximum allowed TBAT battery temperature for
		  charging.

		USB:

		  Reports the maximum allowed supply temperature for operation.

		Access: Read

		Valid values: Represented in 1/10 Degrees Celsius

What:		/sys/class/power_supply/<supply_name>/temp_min
Date:		July 2014
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports the minimum allowed TBAT battery temperature for
		  charging.

		USB:

		  Reports the minimum allowed supply temperature for operation.

		Access: Read

		Valid values: Represented in 1/10 Degrees Celsius

What:		/sys/class/power_supply/<supply_name>/voltage_max,
Date:		January 2008
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports the maximum safe VBAT voltage permitted for the
		  battery, during charging.

		USB:

		  Reports the maximum VBUS voltage the supply can support.

		Access: Read

		Valid values: Represented in microvolts

What:		/sys/class/power_supply/<supply_name>/voltage_min,
Date:		January 2008
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports the minimum safe VBAT voltage permitted for the
		  battery, during discharging.

		USB:

		  Reports the minimum VBUS voltage the supply can support.

		Access: Read

		Valid values: Represented in microvolts

What:		/sys/class/power_supply/<supply_name>/voltage_now,
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Battery:

		  Reports an instant, single VBAT voltage reading for the
		  battery. This value is not averaged/smoothed.

		  Access: Read

		USB:

		  Reports the VBUS voltage supplied now. This value is generally
		  read-only reporting, unless the 'online' state of the supply
		  is set to be programmable, in which case this value can be set
		  within the reported min/max range.

		  Access: Read, Write

		Valid values: Represented in microvolts

**Battery Properties**

What:		/sys/class/power_supply/<supply_name>/capacity
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Fine grain representation of battery capacity.

		Access: Read

		Valid values: 0 - 100 (percent)

What:		/sys/class/power_supply/<supply_name>/capacity_alert_max
Date:		July 2012
Contact:	linux-pm@vger.kernel.org
Description:
		Maximum battery capacity trip-wire value where the supply will
		notify user-space of the event. This is normally used for the
		battery discharging scenario where user-space needs to know the
		battery has dropped to an upper level so it can take
		appropriate action (e.g. warning user that battery level is
		low).

		Access: Read, Write

		Valid values: 0 - 100 (percent)

What:		/sys/class/power_supply/<supply_name>/capacity_alert_min
Date:		July 2012
Contact:	linux-pm@vger.kernel.org
Description:
		Minimum battery capacity trip-wire value where the supply will
		notify user-space of the event. This is normally used for the
		battery discharging scenario where user-space needs to know the
		battery has dropped to a lower level so it can take
		appropriate action (e.g. warning user that battery level is
		critically low).

		Access: Read, Write

		Valid values: 0 - 100 (percent)

What:		/sys/class/power_supply/<supply_name>/capacity_error_margin
Date:		April 2019
Contact:	linux-pm@vger.kernel.org
Description:
		Battery capacity measurement becomes unreliable without
		recalibration. This values provides the maximum error
		margin expected to exist by the fuel gauge in percent.
		Values close to 0% will be returned after (re-)calibration
		has happened. Over time the error margin will increase.
		100% means, that the capacity related values are basically
		completely useless.

		Access: Read

		Valid values: 0 - 100 (percent)

What:		/sys/class/power_supply/<supply_name>/capacity_level
Date:		June 2009
Contact:	linux-pm@vger.kernel.org
Description:
		Coarse representation of battery capacity.

		Access: Read

		Valid values:
			      "Unknown", "Critical", "Low", "Normal", "High",
			      "Full"

What:		/sys/class/power_supply/<supply_name>/charge_control_limit
Date:		Oct 2012
Contact:	linux-pm@vger.kernel.org
Description:
		Maximum allowable charging current. Used for charge rate
		throttling for thermal cooling or improving battery health.

		Access: Read, Write

		Valid values: Represented in microamps

What:		/sys/class/power_supply/<supply_name>/charge_control_limit_max
Date:		Oct 2012
Contact:	linux-pm@vger.kernel.org
Description:
		Maximum legal value for the charge_control_limit property.

		Access: Read

		Valid values: Represented in microamps

What:		/sys/class/power_supply/<supply_name>/charge_control_start_threshold
Date:		April 2019
Contact:	linux-pm@vger.kernel.org
Description:
		Represents a battery percentage level, below which charging will
		begin.

		Access: Read, Write
		Valid values: 0 - 100 (percent)

What:		/sys/class/power_supply/<supply_name>/charge_control_end_threshold
Date:		April 2019
Contact:	linux-pm@vger.kernel.org
Description:
		Represents a battery percentage level, above which charging will
		stop. Not all hardware is capable of setting this to an arbitrary
		percentage. Drivers will round written values to the nearest
		supported value. Reading back the value will show the actual
		threshold set by the driver.

		Access: Read, Write

		Valid values: 0 - 100 (percent)

What:		/sys/class/power_supply/<supply_name>/charge_type
Date:		July 2009
Contact:	linux-pm@vger.kernel.org
Description:
		Represents the type of charging currently being applied to the
		battery. "Trickle", "Fast", and "Standard" all mean different
		charging speeds. "Adaptive" means that the charger uses some
		algorithm to adjust the charge rate dynamically, without
		any user configuration required. "Custom" means that the charger
		uses the charge_control_* properties as configuration for some
		different algorithm. "Long Life" means the charger reduces its
		charging rate in order to prolong the battery health. "Bypass"
		means the charger bypasses the charging path around the
		integrated converter allowing for a "smart" wall adaptor to
		perform the power conversion externally.

		Access: Read, Write

		Valid values:
			      "Unknown", "N/A", "Trickle", "Fast", "Standard",
			      "Adaptive", "Custom", "Long Life", "Bypass"

What:		/sys/class/power_supply/<supply_name>/charge_term_current
Date:		July 2014
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the charging current value which is used to determine
		when the battery is considered full and charging should end.

		Access: Read

		Valid values: Represented in microamps

What:		/sys/class/power_supply/<supply_name>/health
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the health of the battery or battery side of charger
		functionality.

		Access: Read

		Valid values:
			      "Unknown", "Good", "Overheat", "Dead",
			      "Over voltage", "Unspecified failure", "Cold",
			      "Watchdog timer expire", "Safety timer expire",
			      "Over current", "Calibration required", "Warm",
			      "Cool", "Hot", "No battery"

What:		/sys/class/power_supply/<supply_name>/precharge_current
Date:		June 2017
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the charging current applied during pre-charging phase
		for a battery charge cycle.

		Access: Read

		Valid values: Represented in microamps

What:		/sys/class/power_supply/<supply_name>/present
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Reports whether a battery is present or not in the system.

		Access: Read

		Valid values:

			== =======
			0: Absent
			1: Present
			== =======

What:		/sys/class/power_supply/<supply_name>/status
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Represents the charging status of the battery. Normally this
		is read-only reporting although for some supplies this can be
		used to enable/disable charging to the battery.

		Access: Read, Write

		Valid values:
			      "Unknown", "Charging", "Discharging",
			      "Not charging", "Full"

What:		/sys/class/power_supply/<supply_name>/charge_behaviour
Date:		November 2021
Contact:	linux-pm@vger.kernel.org
Description:
		Represents the charging behaviour.

		Access: Read, Write

		Valid values:
			================ ====================================
			auto:            Charge normally, respect thresholds
			inhibit-charge:  Do not charge while AC is attached
			force-discharge: Force discharge while AC is attached
			================ ====================================

What:		/sys/class/power_supply/<supply_name>/technology
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Describes the battery technology supported by the supply.

		Access: Read

		Valid values:
			      "Unknown", "NiMH", "Li-ion", "Li-poly", "LiFe",
			      "NiCd", "LiMn"

What:		/sys/class/power_supply/<supply_name>/voltage_avg,
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Reports an average VBAT voltage reading for the battery, over a
		fixed period. Normally devices will provide a fixed interval in
		which they average readings to smooth out the reported value.

		Access: Read

		Valid values: Represented in microvolts

What:		/sys/class/power_supply/<supply_name>/cycle_count
Date:		January 2010
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the number of full charge + discharge cycles the
		battery has undergone.

		Access: Read

		Valid values:
			Integer > 0: representing full cycles
			Integer = 0: cycle_count info is not available

**USB Properties**

What:		/sys/class/power_supply/<supply_name>/input_current_limit
Date:		July 2014
Contact:	linux-pm@vger.kernel.org
Description:
		Details the incoming IBUS current limit currently set in the
		supply. Normally this is configured based on the type of
		connection made (e.g. A configured SDP should output a maximum
		of 500mA so the input current limit is set to the same value).
		Use preferably input_power_limit, and for problems that can be
		solved using power limit use input_current_limit.

		Access: Read, Write

		Valid values: Represented in microamps

What:		/sys/class/power_supply/<supply_name>/input_voltage_limit
Date:		May 2019
Contact:	linux-pm@vger.kernel.org
Description:
		This entry configures the incoming VBUS voltage limit currently
		set in the supply. Normally this is configured based on
		system-level knowledge or user input (e.g. This is part of the
		Pixel C's thermal management strategy to effectively limit the
		input power to 5V when the screen is on to meet Google's skin
		temperature targets). Note that this feature should not be
		used for safety critical things.
		Use preferably input_power_limit, and for problems that can be
		solved using power limit use input_voltage_limit.

		Access: Read, Write

		Valid values: Represented in microvolts

What:		/sys/class/power_supply/<supply_name>/input_power_limit
Date:		May 2019
Contact:	linux-pm@vger.kernel.org
Description:
		This entry configures the incoming power limit currently set
		in the supply. Normally this is configured based on
		system-level knowledge or user input. Use preferably this
		feature to limit the incoming power and use current/voltage
		limit only for problems that can be solved using power limit.

		Access: Read, Write

		Valid values: Represented in microwatts

What:		/sys/class/power_supply/<supply_name>/online,
Date:		May 2007
Contact:	linux-pm@vger.kernel.org
Description:
		Indicates if VBUS is present for the supply. When the supply is
		online, and the supply allows it, then it's possible to switch
		between online states (e.g. Fixed -> Programmable for a PD_PPS
		USB supply so voltage and current can be controlled).

		Access: Read, Write

		Valid values:

			== ==================================================
			0: Offline
			1: Online Fixed - Fixed Voltage Supply
			2: Online Programmable - Programmable Voltage Supply
			== ==================================================

What: 		/sys/class/power_supply/<supply_name>/usb_type
Date:		March 2018
Contact:	linux-pm@vger.kernel.org
Description:
		Reports what type of USB connection is currently active for
		the supply, for example it can show if USB-PD capable source
		is attached.

		Access: Read-Only

		Valid values:
			      "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
			      "PD_DRP", "PD_PPS", "BrickID"

**Device Specific Properties**

What:		/sys/class/power/ds2760-battery.*/charge_now
Date:		May 2010
KernelVersion:	2.6.35
Contact:	Daniel Mack <daniel@caiaq.de>
Description:
		This file is writeable and can be used to set the current
		coloumb counter value inside the battery monitor chip. This
		is needed for unavoidable corrections of aging batteries.
		A userspace daemon can monitor the battery charging logic
		and once the counter drops out of considerable bounds, take
		appropriate action.

What:		/sys/class/power/ds2760-battery.*/charge_full
Date:		May 2010
KernelVersion:	2.6.35
Contact:	Daniel Mack <daniel@caiaq.de>
Description:
		This file is writeable and can be used to set the assumed
		battery 'full level'. As batteries age, this value has to be
		amended over time.

What:		/sys/class/power_supply/max14577-charger/device/fast_charge_timer
Date:		October 2014
KernelVersion:	3.18.0
Contact:	Krzysztof Kozlowski <krzk@kernel.org>
Description:
		This entry shows and sets the maximum time the max14577
		charger operates in fast-charge mode. When the timer expires
		the device will terminate fast-charge mode (charging current
		will drop to 0 A) and will trigger interrupt.

		Valid values:

		- 5, 6 or 7 (hours),
		- 0: disabled.

What:		/sys/class/power_supply/max77693-charger/device/fast_charge_timer
Date:		January 2015
KernelVersion:	3.19.0
Contact:	Krzysztof Kozlowski <krzk@kernel.org>
Description:
		This entry shows and sets the maximum time the max77693
		charger operates in fast-charge mode. When the timer expires
		the device will terminate fast-charge mode (charging current
		will drop to 0 A) and will trigger interrupt.

		Valid values:

		- 4 - 16 (hours), step by 2 (rounded down)
		- 0: disabled.

What:		/sys/class/power_supply/max77693-charger/device/top_off_threshold_current
Date:		January 2015
KernelVersion:	3.19.0
Contact:	Krzysztof Kozlowski <krzk@kernel.org>
Description:
		This entry shows and sets the charging current threshold for
		entering top-off charging mode. When charging current in fast
		charge mode drops below this value, the charger will trigger
		interrupt and start top-off charging mode.

		Valid values:

		- 100000 - 200000 (microamps), step by 25000 (rounded down)
		- 200000 - 350000 (microamps), step by 50000 (rounded down)
		- 0: disabled.

What:		/sys/class/power_supply/max77693-charger/device/top_off_timer
Date:		January 2015
KernelVersion:	3.19.0
Contact:	Krzysztof Kozlowski <krzk@kernel.org>
Description:
		This entry shows and sets the maximum time the max77693
		charger operates in top-off charge mode. When the timer expires
		the device will terminate top-off charge mode (charging current
		will drop to 0 A) and will trigger interrupt.

		Valid values:

		- 0 - 70 (minutes), step by 10 (rounded down)

What:		/sys/class/power_supply/bq24257-charger/ovp_voltage
Date:		October 2015
KernelVersion:	4.4.0
Contact:	Andreas Dannenberg <dannenberg@ti.com>
Description:
		This entry configures the overvoltage protection feature of bq24257-
		type charger devices. This feature protects the device and other
		components against damage from overvoltage on the input supply. See
		device datasheet for details.

		Valid values:

		- 6000000, 6500000, 7000000, 8000000, 9000000, 9500000, 10000000,
		  10500000 (all uV)

What:		/sys/class/power_supply/bq24257-charger/in_dpm_voltage
Date:		October 2015
KernelVersion:	4.4.0
Contact:	Andreas Dannenberg <dannenberg@ti.com>
Description:
		This entry configures the input dynamic power path management voltage of
		bq24257-type charger devices. Once the supply drops to the configured
		voltage, the input current limit is reduced down to prevent the further
		drop of the supply. When the IC enters this mode, the charge current is
		lower than the set value. See device datasheet for details.

		Valid values:

		- 4200000, 4280000, 4360000, 4440000, 4520000, 4600000, 4680000,
		  4760000 (all uV)

What:		/sys/class/power_supply/bq24257-charger/high_impedance_enable
Date:		October 2015
KernelVersion:	4.4.0
Contact:	Andreas Dannenberg <dannenberg@ti.com>
Description:
		This entry allows enabling the high-impedance mode of bq24257-type
		charger devices. If enabled, it places the charger IC into low power
		standby mode with the switch mode controller disabled. When disabled,
		the charger operates normally. See device datasheet for details.

		Valid values:

		- 1: enabled
		- 0: disabled

What:		/sys/class/power_supply/bq24257-charger/sysoff_enable
Date:		October 2015
KernelVersion:	4.4.0
Contact:	Andreas Dannenberg <dannenberg@ti.com>
Description:
		This entry allows enabling the sysoff mode of bq24257-type charger
		devices. If enabled and the input is removed, the internal battery FET
		is turned off in order to reduce the leakage from the BAT pin to less
		than 1uA. Note that on some devices/systems this disconnects the battery
		from the system. See device datasheet for details.

		Valid values:

		- 1: enabled
		- 0: disabled

What:		/sys/class/power_supply/<supply_name>/manufacture_year
Date:		January 2020
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the year (following Gregorian calendar) when the device has been
		manufactured.

		Access: Read

		Valid values: Reported as integer

What:		/sys/class/power_supply/<supply_name>/manufacture_month
Date:		January 2020
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the month when the device has been manufactured.

		Access: Read

		Valid values: 1-12

What:		/sys/class/power_supply/<supply_name>/manufacture_day
Date:		January 2020
Contact:	linux-pm@vger.kernel.org
Description:
		Reports the day of month when the device has been manufactured.

		Access: Read
		Valid values: 1-31


code:
What:		/sys/class/power_supply/ltc4162-l/charge_status
Date:		Januari 2021
KernelVersion:	5.11
Description:
		Detailed charge status information as reported by the chip.

		Access: Read

		Valid values:
			ilim_reg_active
			thermal_reg_active
			vin_uvcl_active
			iin_limit_active
			constant_current
			constant_voltage
			charger_off

What:		/sys/class/power_supply/ltc4162-l/ibat
Date:		Januari 2021
KernelVersion:	5.11
Description:
		Battery input current as measured by the charger. Negative value
		means that the battery is discharging.

		Access: Read

		Valid values: Signed value in microamps

What:		/sys/class/power_supply/ltc4162-l/vbat
Date:		Januari 2021
KernelVersion:	5.11
Description:
		Battery voltage as measured by the charger.

		Access: Read

		Valid values: In microvolts

What:		/sys/class/power_supply/ltc4162-l/vbat_avg
Date:		Januari 2021
KernelVersion:	5.11
Description:
		Battery voltage, averaged over time, as measured by the charger.

		Access: Read

		Valid values: In microvolts

What:		/sys/class/power_supply/ltc4162-l/force_telemetry
Date:		Januari 2021
KernelVersion:	5.11
Description:
		To save battery current, the measurement system is disabled if
		the battery is the only source of power. This affects all
		voltage, current and temperature measurements.
		Write a "1" to this to keep performing telemetry once every few
		seconds, even when running on battery (as reported by the online
		property, which is "1" when external power is available and "0"
		when the system runs on battery).

		Access: Read, Write

		Valid values: 0 (disabled) or 1 (enabled)

What:		/sys/class/power_supply/ltc4162-l/arm_ship_mode
Date:		Januari 2021
KernelVersion:	5.11
Description:
		The charger will normally drain the battery while inactive,
		typically drawing about 54 microamps. Write a "1" to this
		property to arm a special "ship" mode that extends shelf life
		by reducing the leakage to about 2.8 microamps. The chip will
		remain in this mode (and no longer respond to I2C commands)
		until some external power-supply is attached raising the input
		voltage above 1V. It will then automatically revert to "0".
		Writing a "0" to the property cancels the "ship" mode request.
		The ship mode, when armed, activates once the input voltage
		drops below 1V.

		Access: Read, Write

		Valid values: 0 (disable) or 1 (enable)

repo_name: angery/linux


code:
What:		/sys/class/power_supply/mp2629_battery/batt_impedance_compen
Date:		April 2020
KernelVersion:	5.7
Description:
		Represents a battery impedance compensation to accelerate charging.

                Access: Read, Write

                Valid values: Represented in milli-ohms. Valid range is [0, 140].


code:
What:		/sys/class/power_supply/<supply_name>/alarm
Date:		April 2021
KernelVersion:	5.13
Contact:	Maximilian Luz <luzmaximilian@gmail.com>
Description:
		Battery trip point. When the remaining battery capacity crosses this
		value in either direction, the system will be notified and if
		necessary woken.

		Set to zero to clear/disable.

		Access: Read, Write

		Valid values: In micro-Wh or micro-Ah, depending on the power unit
		of the battery


code:
What: /sys/class/power_supply/twl4030_usb/mode
Description:
	Changing mode for USB port.
	Writing to this can disable charging.

	Possible values are:

		=============	===========================================
		"auto"		draw power as appropriate for detected
				power source and battery status.
		"off"		do not draw any power.
		"continuous"	activate mode described as "linear" in
				TWL data sheets.  This uses whatever
				current is available and doesn't switch off
				when voltage drops.

				This is useful for unstable power sources
				such as bicycle dynamo, but care should
				be taken that battery is not over-charged.
		=============	===========================================

What: /sys/class/power_supply/twl4030_ac/mode
Description:
	Changing mode for 'ac' port.
	Writing to this can disable charging.

	Possible values are:

		======	===========================================
		"auto"	draw power as appropriate for detected
			power source and battery status.
		"off"	do not draw any power.
		======	===========================================


code:
What:		/sys/class/power_supply/wilco-charger/charge_type
Date:		April 2019
KernelVersion:	5.2
Description:
		What charging algorithm to use:

		Standard:
			Fully charges battery at a standard rate.
		Adaptive:
			Battery settings adaptively optimized based on
			typical battery usage pattern.
		Fast:
			Battery charges over a shorter period.
		Trickle:
			Extends battery lifespan, intended for users who
			primarily use their Chromebook while connected to AC.
		Custom:
			A low and high threshold percentage is specified.
			Charging begins when level drops below
			charge_control_start_threshold, and ceases when
			level is above charge_control_end_threshold.
		Long Life:
			Customized charge rate for last longer battery life.
			On Wilco device this mode is pre-configured in the factory
			through EC's private PID. Swiching to a different mode will
			be denied by Wilco EC when Long Life mode is enabled.

What:		/sys/class/power_supply/wilco-charger/charge_control_start_threshold
Date:		April 2019
KernelVersion:	5.2
Description:
		Used when charge_type="Custom", as described above. Measured in
		percentages. The valid range is [50, 95].

What:		/sys/class/power_supply/wilco-charger/charge_control_end_threshold
Date:		April 2019
KernelVersion:	5.2
Description:
		Used when charge_type="Custom", as described above. Measured in
		percentages. The valid range is [55, 100].


code:
What:		/sys/class/powercap/
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		The powercap/ class sub directory belongs to the power cap
		subsystem. Refer to
		Documentation/power/powercap/powercap.rst for details.

What:		/sys/class/powercap/<control type>
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		A <control type> is a unique name under /sys/class/powercap.
		Here <control type> determines how the power is going to be
		controlled. A <control type> can contain multiple power zones.

What:		/sys/class/powercap/<control type>/enabled
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		This allows to enable/disable power capping for a "control type".
		This status affects every power zone using this "control_type.

What:		/sys/class/powercap/<control type>/<power zone>
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		A power zone is a single or a collection of devices, which can
		be independently monitored and controlled. A power zone sysfs
		entry is qualified with the name of the <control type>.
		E.g. intel-rapl:0:1:1.

What:		/sys/class/powercap/<control type>/<power zone>/<child power zone>
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Power zones may be organized in a hierarchy in which child
		power zones provide monitoring and control for a subset of
		devices under the parent. For example, if there is a parent
		power zone for a whole CPU package, each CPU core in it can
		be a child power zone.

What:		/sys/class/powercap/.../<power zone>/name
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Specifies the name of this power zone.

What:		/sys/class/powercap/.../<power zone>/energy_uj
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Current energy counter in micro-joules. Write "0" to reset.
		If the counter can not be reset, then this attribute is
		read-only.

What:		/sys/class/powercap/.../<power zone>/max_energy_range_uj
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Range of the above energy counter in micro-joules.

What:		/sys/class/powercap/.../<power zone>/power_uw
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Current power in micro-watts.

What:		/sys/class/powercap/.../<power zone>/max_power_range_uw
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Range of the above power value in micro-watts.

What:		/sys/class/powercap/.../<power zone>/constraint_X_name
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Each power zone can define one or more constraints. Each
		constraint can have an optional name. Here "X" can have values
		from 0 to max integer.

What:		/sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Power limit in micro-watts should be applicable for
		the time window specified by "constraint_X_time_window_us".
		Here "X" can have values from 0 to max integer.

What:		/sys/class/powercap/.../<power zone>/constraint_X_time_window_us
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Time window in micro seconds. This is used along with
		constraint_X_power_limit_uw to define a power constraint.
		Here "X" can have values from 0 to max integer.

What:		/sys/class/powercap/<control type>/.../constraint_X_max_power_uw
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Maximum allowed power in micro watts for this constraint.
		Here "X" can have values from 0 to max integer.

What:		/sys/class/powercap/<control type>/.../constraint_X_min_power_uw
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Minimum allowed power in micro watts for this constraint.
		Here "X" can have values from 0 to max integer.

What:		/sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Maximum allowed time window in micro seconds for this
		constraint. Here "X" can have values from 0 to max integer.

What:		/sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		Minimum allowed time window in micro seconds for this
		constraint. Here "X" can have values from 0 to max integer.

What:		/sys/class/powercap/.../<power zone>/enabled
Date:		September 2013
KernelVersion:	3.13
Contact:	linux-pm@vger.kernel.org
Description:
		This allows to enable/disable power capping at power zone level.
		This applies to current power zone and its children.


code:
What:		/sys/class/pwm/
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		The pwm/ class sub-directory belongs to the Generic PWM
		Framework and provides a sysfs interface for using PWM
		channels.

What:		/sys/class/pwm/pwmchip<N>/
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		A /sys/class/pwm/pwmchipN directory is created for each
		probed PWM controller/chip where N is the base of the
		PWM chip.

What:		/sys/class/pwm/pwmchip<N>/npwm
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		The number of PWM channels supported by the PWM chip.

What:		/sys/class/pwm/pwmchip<N>/export
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		Exports a PWM channel from the PWM chip for sysfs control.
		Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1.

What:		/sys/class/pwm/pwmchip<N>/unexport
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		Unexports a PWM channel.

What:		/sys/class/pwm/pwmchip<N>/pwmX
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		A /sys/class/pwm/pwmchipN/pwmX directory is created for
		each exported PWM channel where X is the exported PWM
		channel number.

What:		/sys/class/pwm/pwmchip<N>/pwmX/period
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		Sets the PWM signal period in nanoseconds.

What:		/sys/class/pwm/pwmchip<N>/pwmX/duty_cycle
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		Sets the PWM signal duty cycle in nanoseconds.

What:		/sys/class/pwm/pwmchip<N>/pwmX/polarity
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		Sets the output polarity of the PWM signal to "normal" or
		"inversed".

What:		/sys/class/pwm/pwmchip<N>/pwmX/enable
Date:		May 2013
KernelVersion:	3.11
Contact:	H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
		Enable/disable the PWM signal.
		0 is disabled
		1 is enabled

What:		/sys/class/pwm/pwmchip<N>/pwmX/capture
Date:		June 2016
KernelVersion:	4.8
Contact:	Lee Jones <lee@kernel.org>
Description:
		Capture information about a PWM signal. The output format is a
		pair unsigned integers (period and duty cycle), separated by a
		single space.


code:
What:		/sys/class/rapidio_port
Description:
		On-chip RapidIO controllers and PCIe-to-RapidIO bridges
		(referenced as "Master Port" or "mport") are presented in sysfs
		as the special class of devices: "rapidio_port".
		The /sys/class/rapidio_port subdirectory contains individual
		subdirectories named as "rapidioN" where N = mport ID registered
		with RapidIO subsystem.

		NOTE: An mport ID is not a RapidIO destination ID assigned to a
		given local mport device.

What:		/sys/class/rapidio_port/rapidio<N>/sys_size
Date:		Apr, 2014
KernelVersion:	v3.15
Contact:	Matt Porter <mporter@kernel.crashing.org>,
		Alexandre Bounine <alexandre.bounine@idt.com>
Description:
		(RO) reports RapidIO common transport system size:

		0 = small (8-bit destination ID, max. 256 devices),

		1 = large (16-bit destination ID, max. 65536 devices).

What:		/sys/class/rapidio_port/rapidio<N>/port_destid
Date:		Apr, 2014
KernelVersion:	v3.15
Contact:	Matt Porter <mporter@kernel.crashing.org>,
		Alexandre Bounine <alexandre.bounine@idt.com>
Description:

(RO) reports RapidIO destination ID assigned to the given
RapidIO mport device. If value 0xFFFFFFFF is returned this means
that no valid destination ID have been assigned to the mport
(yet). Normally, before enumeration/discovery have been executed
only fabric enumerating mports have a valid destination ID
assigned to them using "hdid=..." rapidio module parameter.

After enumeration or discovery was performed for a given mport device,
the corresponding subdirectory will also contain subdirectories for each
child RapidIO device connected to the mport.

The example below shows mport device subdirectory with several child RapidIO
devices attached to it::

    [rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l
    total 0
    drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0001
    drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0004
    drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0007
    drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0002
    drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0003
    drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0005
    lrwxrwxrwx 1 root root    0 Feb 11 15:11 device -> ../../../0000:01:00.0
    -r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid
    drwxr-xr-x 2 root root    0 Feb 11 15:11 power
    lrwxrwxrwx 1 root root    0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port
    -r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size
    -rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent


code:
What:		/sys/class/rc/
Date:		Apr 2010
KernelVersion:	2.6.35
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		The rc/ class sub-directory belongs to the Remote Controller
		core and provides a sysfs interface for configuring infrared
		remote controller receivers.

What:		/sys/class/rc/rc<N>/
Date:		Apr 2010
KernelVersion:	2.6.35
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		A /sys/class/rc/rcN directory is created for each remote
		control receiver device where N is the number of the receiver.

What:		/sys/class/rc/rc<N>/protocols
Date:		Jun 2010
KernelVersion:	2.6.36
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Reading this file returns a list of available protocols,
		something like::

		    "rc5 [rc6] nec jvc [sony]"

		Enabled protocols are shown in [] brackets.

		Writing "+proto" will add a protocol to the list of enabled
		protocols.

		Writing "-proto" will remove a protocol from the list of enabled
		protocols.

		Writing "proto" will enable only "proto".

		Writing "none" will disable all protocols.

		Write fails with EINVAL if an invalid protocol combination or
		unknown protocol name is used.

What:		/sys/class/rc/rc<N>/filter
Date:		Jan 2014
KernelVersion:	3.15
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Sets the scancode filter expected value.

		Use in combination with /sys/class/rc/rcN/filter_mask to set the
		expected value of the bits set in the filter mask.
		If the hardware supports it then scancodes which do not match
		the filter will be ignored. Otherwise the write will fail with
		an error.

		This value may be reset to 0 if the current protocol is altered.

What:		/sys/class/rc/rc<N>/filter_mask
Date:		Jan 2014
KernelVersion:	3.15
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Sets the scancode filter mask of bits to compare.
		Use in combination with /sys/class/rc/rcN/filter to set the bits
		of the scancode which should be compared against the expected
		value. A value of 0 disables the filter to allow all valid
		scancodes to be processed.

		If the hardware supports it then scancodes which do not match
		the filter will be ignored. Otherwise the write will fail with
		an error.

		This value may be reset to 0 if the current protocol is altered.

What:		/sys/class/rc/rc<N>/wakeup_protocols
Date:		Feb 2017
KernelVersion:	4.11
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Reading this file returns a list of available protocols to use
		for the wakeup filter, something like::

		    "rc-5 nec nec-x rc-6-0 rc-6-6a-24 [rc-6-6a-32] rc-6-mce"

		Note that protocol variants are listed, so "nec", "sony",
		"rc-5", "rc-6" have their different bit length encodings
		listed if available.

		The enabled wakeup protocol is shown in [] brackets.

		Only one protocol can be selected at a time.

		Writing "proto" will use "proto" for wakeup events.

		Writing "none" will disable wakeup.

		Write fails with EINVAL if an invalid protocol combination or
		unknown protocol name is used, or if wakeup is not supported by
		the hardware.

What:		/sys/class/rc/rc<N>/wakeup_filter
Date:		Jan 2014
KernelVersion:	3.15
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Sets the scancode wakeup filter expected value.

		Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to
		set the expected value of the bits set in the wakeup filter mask
		to trigger a system wake event.

		If the hardware supports it and wakeup_filter_mask is not 0 then
		scancodes which match the filter will wake the system from e.g.
		suspend to RAM or power off.

		Otherwise the write will fail with an error.

		This value may be reset to 0 if the wakeup protocol is altered.

What:		/sys/class/rc/rc<N>/wakeup_filter_mask
Date:		Jan 2014
KernelVersion:	3.15
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Sets the scancode wakeup filter mask of bits to compare.

		Use in combination with /sys/class/rc/rcN/wakeup_filter to set
		the bits of the scancode which should be compared against the
		expected value to trigger a system wake event.

		If the hardware supports it and wakeup_filter_mask is not 0 then
		scancodes which match the filter will wake the system from e.g.
		suspend to RAM or power off.

		Otherwise the write will fail with an error.

		This value may be reset to 0 if the wakeup protocol is altered.


code:
What:		/sys/class/rc/rc<N>/wakeup_data
Date:		Mar 2016
KernelVersion:	4.6
Contact:	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
		Reading this file returns the stored CIR wakeup sequence.
		It starts with a pulse, followed by a space, pulse etc.
		All values are in microseconds.
		The same format can be used to store a wakeup sequence
		in the Nuvoton chip by writing to this file.

		Note: Some systems reset the stored wakeup sequence to a
		factory default on each boot. On such systems store the
		wakeup sequence in a file and set it on boot using e.g.
		a udev rule.


code:
What:		/sys/class/regulator/.../state
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		state. This reports the regulator enable control, for
		regulators which can report that input value.

		This will be one of the following strings:

		'enabled'
		'disabled'
		'unknown'

		'enabled' means the regulator output is ON and is supplying
		power to the system (assuming no error prevents it).

		'disabled' means the regulator output is OFF and is not
		supplying power to the system (unless some non-Linux
		control has enabled it).

		'unknown' means software cannot determine the state, or
		the reported state is invalid.

		NOTE: this field can be used in conjunction with microvolts
		or microamps to determine configured regulator output levels.

What:		/sys/class/regulator/.../status
Description:
		Some regulator directories will contain a field called
		"status". This reports the current regulator status, for
		regulators which can report that output value.

		This will be one of the following strings:

			- off
			- on
			- error
			- fast
			- normal
			- idle
			- standby

		"off" means the regulator is not supplying power to the
		system.

		"on" means the regulator is supplying power to the system,
		and the regulator can't report a detailed operation mode.

		"error" indicates an out-of-regulation status such as being
		disabled due to thermal shutdown, or voltage being unstable
		because of problems with the input power supply.

		"fast", "normal", "idle", and "standby" are all detailed
		regulator operation modes (described elsewhere).  They
		imply "on", but provide more detail.

		Note that regulator status is a function of many inputs,
		not limited to control inputs from Linux.  For example,
		the actual load presented may trigger "error" status; or
		a regulator may be enabled by another user, even though
		Linux did not enable it.

What:		/sys/class/regulator/.../type
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Each regulator directory will contain a field called
		type. This holds the regulator type.

		This will be one of the following strings:

		- 'voltage'
		- 'current'
		- 'unknown'

		'voltage' means the regulator output voltage can be controlled
		by software.

		'current' means the regulator output current limit can be
		controlled by software.

		'unknown' means software cannot control either voltage or
		current limit.

What:		/sys/class/regulator/.../microvolts
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		microvolts. This holds the regulator output voltage setting
		measured in microvolts (i.e. E-6 Volts), for regulators
		which can report the control input for voltage.

		NOTE: This value should not be used to determine the regulator
		output voltage level as this value is the same regardless of
		whether the regulator is enabled or disabled.

What:		/sys/class/regulator/.../microamps
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		microamps. This holds the regulator output current limit
		setting measured in microamps (i.e. E-6 Amps), for regulators
		which can report the control input for a current limit.

		NOTE: This value should not be used to determine the regulator
		output current level as this value is the same regardless of
		whether the regulator is enabled or disabled.

What:		/sys/class/regulator/.../opmode
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		opmode. This holds the current regulator operating mode,
		for regulators which can report that control input value.

		The opmode value can be one of the following strings:

		- 'fast'
		- 'normal'
		- 'idle'
		- 'standby'
		- 'unknown'

		The modes are described in include/linux/regulator/consumer.h

		NOTE: This value should not be used to determine the regulator
		output operating mode as this value is the same regardless of
		whether the regulator is enabled or disabled.  A "status"
		attribute may be available to determine the actual mode.

What:		/sys/class/regulator/.../min_microvolts
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		min_microvolts. This holds the minimum safe working regulator
		output voltage setting for this domain measured in microvolts,
		for regulators which support voltage constraints.

		NOTE: this will return the string 'constraint not defined' if
		the power domain has no min microvolts constraint defined by
		platform code.

What:		/sys/class/regulator/.../max_microvolts
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		max_microvolts. This holds the maximum safe working regulator
		output voltage setting for this domain measured in microvolts,
		for regulators which support voltage constraints.

		NOTE: this will return the string 'constraint not defined' if
		the power domain has no max microvolts constraint defined by
		platform code.

What:		/sys/class/regulator/.../min_microamps
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		min_microamps. This holds the minimum safe working regulator
		output current limit setting for this domain measured in
		microamps, for regulators which support current constraints.

		NOTE: this will return the string 'constraint not defined' if
		the power domain has no min microamps constraint defined by
		platform code.

What:		/sys/class/regulator/.../max_microamps
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		max_microamps. This holds the maximum safe working regulator
		output current limit setting for this domain measured in
		microamps, for regulators which support current constraints.

		NOTE: this will return the string 'constraint not defined' if
		the power domain has no max microamps constraint defined by
		platform code.

What:		/sys/class/regulator/.../name
Date:		October 2008
KernelVersion:	2.6.28
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Each regulator directory will contain a field called
		name. This holds a string identifying the regulator for
		display purposes.

		NOTE: this will be empty if no suitable name is provided
		by platform or regulator drivers.

What:		/sys/class/regulator/.../num_users
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Each regulator directory will contain a field called
		num_users. This holds the number of consumer devices that
		have called regulator_enable() on this regulator.

What:		/sys/class/regulator/.../requested_microamps
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		requested_microamps. This holds the total requested load
		current in microamps for this regulator from all its consumer
		devices.

What:		/sys/class/regulator/.../parent
Date:		April 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a link called parent.
		This points to the parent or supply regulator if one exists.

What:		/sys/class/regulator/.../suspend_mem_microvolts
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_mem_microvolts. This holds the regulator output
		voltage setting for this domain measured in microvolts when
		the system is suspended to memory, for voltage regulators
		implementing suspend voltage configuration constraints.

What:		/sys/class/regulator/.../suspend_disk_microvolts
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_disk_microvolts. This holds the regulator output
		voltage setting for this domain measured in microvolts when
		the system is suspended to disk, for voltage regulators
		implementing suspend voltage configuration constraints.

What:		/sys/class/regulator/.../suspend_standby_microvolts
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_standby_microvolts. This holds the regulator output
		voltage setting for this domain measured in microvolts when
		the system is suspended to standby, for voltage regulators
		implementing suspend voltage configuration constraints.

What:		/sys/class/regulator/.../suspend_mem_mode
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_mem_mode. This holds the regulator operating mode
		setting for this domain when the system is suspended to
		memory, for regulators implementing suspend mode
		configuration constraints.

What:		/sys/class/regulator/.../suspend_disk_mode
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_disk_mode. This holds the regulator operating mode
		setting for this domain when the system is suspended to disk,
		for regulators implementing suspend mode configuration
		constraints.

What:		/sys/class/regulator/.../suspend_standby_mode
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_standby_mode. This holds the regulator operating mode
		setting for this domain when the system is suspended to
		standby, for regulators implementing suspend mode
		configuration constraints.

What:		/sys/class/regulator/.../suspend_mem_state
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_mem_state. This holds the regulator operating state
		when suspended to memory, for regulators implementing suspend
		configuration constraints.

		This will be one of the same strings reported by
		the "state" attribute.

What:		/sys/class/regulator/.../suspend_disk_state
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_disk_state. This holds the regulator operating state
		when suspended to disk, for regulators implementing
		suspend configuration constraints.

		This will be one of the same strings reported by
		the "state" attribute.

What:		/sys/class/regulator/.../suspend_standby_state
Date:		May 2008
KernelVersion:	2.6.26
Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
Description:
		Some regulator directories will contain a field called
		suspend_standby_state. This holds the regulator operating
		state when suspended to standby, for regulators implementing
		suspend configuration constraints.

		This will be one of the same strings reported by
		the "state" attribute.

What:		/sys/class/regulator/.../bypass
Date:		September 2012
KernelVersion:	3.7
Contact:	Mark Brown <broonie@opensource.wolfsonmicro.com>
Description:
		Some regulator directories will contain a field called
		bypass.  This indicates if the device is in bypass mode.

		This will be one of the following strings:

		- 'enabled'
		- 'disabled'
		- 'unknown'

		'enabled' means the regulator is in bypass mode.

		'disabled' means that the regulator is regulating.

		'unknown' means software cannot determine the state, or
		the reported state is invalid.

What:		/sys/class/regulator/.../under_voltage
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		under_voltage.  This indicates if the device reports an
		under-voltage fault (1) or not (0).

What:		/sys/class/regulator/.../over_current
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		over_current.  This indicates if the device reports an
		over-current fault (1) or not (0).

What:		/sys/class/regulator/.../regulation_out
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		regulation_out.  This indicates if the device reports an
		out-of-regulation fault (1) or not (0).

What:		/sys/class/regulator/.../fail
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		fail.  This indicates if the device reports an output failure
		(1) or not (0).

What:		/sys/class/regulator/.../over_temp
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		over_temp.  This indicates if the device reports an
		over-temperature fault (1) or not (0).

What:		/sys/class/regulator/.../under_voltage_warn
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		under_voltage_warn.  This indicates if the device reports an
		under-voltage warning (1) or not (0).

What:		/sys/class/regulator/.../over_current_warn
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		over_current_warn.  This indicates if the device reports an
		over-current warning (1) or not (0).

What:		/sys/class/regulator/.../over_voltage_warn
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		over_voltage_warn.  This indicates if the device reports an
		over-voltage warning (1) or not (0).

What:		/sys/class/regulator/.../over_temp_warn
Date:		April 2022
KernelVersion:	5.18
Contact:	Zev Weiss <zev@bewilderbeest.net>
Description:
		Some regulator directories will contain a field called
		over_temp_warn.  This indicates if the device reports an
		over-temperature warning (1) or not (0).


code:
What:		/sys/class/remoteproc/.../firmware
Date:		October 2016
Contact:	Matt Redfearn <matt.redfearn@mips.com>
Description:	Remote processor firmware

		Reports the name of the firmware currently loaded to the
		remote processor.

		To change the running firmware, ensure the remote processor is
		stopped (using /sys/class/remoteproc/.../state) and write a new filename.

What:		/sys/class/remoteproc/.../state
Date:		October 2016
Contact:	Matt Redfearn <matt.redfearn@mips.com>
Description:	Remote processor state

		Reports the state of the remote processor, which will be one of:

		- "offline"
		- "suspended"
		- "running"
		- "crashed"
		- "invalid"

		"offline" means the remote processor is powered off.

		"suspended" means that the remote processor is suspended and
		must be woken to receive messages.

		"running" is the normal state of an available remote processor

		"crashed" indicates that a problem/crash has been detected on
		the remote processor.

		"invalid" is returned if the remote processor is in an
		unknown state.

		Writing this file controls the state of the remote processor.
		The following states can be written:

		- "start"
		- "stop"

		Writing "start" will attempt to start the processor running the
		firmware indicated by, or written to,
		/sys/class/remoteproc/.../firmware. The remote processor should
		transition to "running" state.

		Writing "stop" will attempt to halt the remote processor and
		return it to the "offline" state.

What:		/sys/class/remoteproc/.../name
Date:		August 2019
KernelVersion:	5.4
Contact:	Suman Anna <s-anna@ti.com>
Description:	Remote processor name

		Reports the name of the remote processor. This can be used by
		userspace in exactly identifying a remote processor and ease
		up the usage in modifying the 'firmware' or 'state' files.

What:		/sys/class/remoteproc/.../coredump
Date:		July 2020
Contact:	Bjorn Andersson <bjorn.andersson@linaro.org>, Ohad Ben-Cohen <ohad@wizery.com>
Description:	Remote processor coredump configuration

		Reports the coredump configuration of the remote processor,
		which will be one of:

		"disabled"
		"enabled"
		"inline"

		"disabled" means no dump will be collected.

		"enabled" means when the remote processor's coredump is
		collected it will be copied to a separate buffer and that
		buffer is exposed to userspace.

		"inline" means when the remote processor's coredump is
		collected userspace will directly read from the remote
		processor's device memory. Extra buffer will not be used to
		copy the dump. Also recovery process will not proceed until
		all data is read by usersapce.

What:		/sys/class/remoteproc/.../recovery
Date:		July 2020
Contact:	Bjorn Andersson <bjorn.andersson@linaro.org>, Ohad Ben-Cohen <ohad@wizery.com>
Description:	Remote processor recovery mechanism

		Reports the recovery mechanism of the remote processor,
		which will be one of:

		"enabled"
		"disabled"

		"enabled" means, the remote processor will be automatically
		recovered whenever it crashes. Moreover, if the remote
		processor crashes while recovery is disabled, it will
		be automatically recovered too as soon as recovery is enabled.

		"disabled" means, a remote processor will remain in a crashed
		state if it crashes. This is useful for debugging purposes;
		without it, debugging a crash is substantially harder.


code:
What:		/sys/class/rnbd-client
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Provide information about RNBD-client.
		All sysfs files that are not read-only provide the usage information on read:

		Example::

		    # cat /sys/class/rnbd-client/ctl/map_device

		    > Usage: echo "sessname=<name of the rtrs session> path=<[srcaddr,]dstaddr>
		    > [path=<[srcaddr,]dstaddr>] device_path=<full path on remote side>
		    > [access_mode=<ro|rw|migration>] > map_device
		    >
		    > addr ::= [ ip:<ipv4> | ip:<ipv6> | gid:<gid> ]

What:		/sys/class/rnbd-client/ctl/map_device
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Expected format is the following::

		    sessname=<name of the rtrs session>
		    path=<[srcaddr,]dstaddr> [path=<[srcaddr,]dstaddr> ...]
		    device_path=<full path on remote side>
		    [access_mode=<ro|rw|migration>]

		Where:

		sessname:
		    accepts a string not bigger than 256 chars, which identifies
		    a given session on the client and on the server.
		    I.e. "clt_hostname-srv_hostname" could be a natural choice.

		path:
		    describes a connection between the client and the server by
		    specifying destination and, when required, the source address.
		    The addresses are to be provided in the following format::

			ip:<IPv6>
			ip:<IPv4>
			gid:<GID>

		for example::

		    path=ip:10.0.0.66

		The single addr is treated as the destination.
		The connection will be established to this server from any client IP address.

		::

		    path=ip:10.0.0.66,ip:10.0.1.66

		First addr is the source address and the second is the destination.

		If multiple "path=" options are specified multiple connection
		will be established and data will be sent according to
		the selected multipath policy (see RTRS mp_policy sysfs entry description).

		device_path:
		    Path to the block device on the server side. Path is specified
		    relative to the directory on server side configured in the
		    'dev_search_path' module parameter of the rnbd_server.
		    The rnbd_server prepends the <device_path> received from client
		    with <dev_search_path> and tries to open the
		    <dev_search_path>/<device_path> block device.  On success,
		    a /dev/rnbd<N> device file, a /sys/block/rnbd<N>/
		    directory and an entry in /sys/class/rnbd-client/ctl/devices
		    will be created.

		If 'dev_search_path' contains '%SESSNAME%', then each session can
		have different devices namespace, e.g. server was configured with
		the following parameter "dev_search_path=/run/rnbd-devs/%SESSNAME%",
		client has this string "sessname=blya device_path=sda", then server
		will try to open: /run/rnbd-devs/blya/sda.

		access_mode:
		    the access_mode parameter specifies if the device is to be
		    mapped as "ro" read-only or "rw" read-write. The server allows
		    a device to be exported in rw mode only once. The "migration"
		    access mode has to be specified if a second mapping in read-write
		    mode is desired.

		By default "rw" is used.

		nr_poll_queues
		  specifies the number of poll-mode queues. If the IO has HIPRI flag,
		  the block-layer will send the IO via the poll-mode queue.
		  For fast network and device the polling is faster than interrupt-base
		  IO handling because it saves time for context switching, switching to
		  another process, handling the interrupt and switching back to the
		  issuing process.

		  Set -1 if you want to set it as the number of CPUs
		  By default rnbd client creates only irq-mode queues.

		  NOTICE: MUST make a unique session for a device using the poll-mode queues.

		Exit Codes:

		If the device is already mapped it will fail with EEXIST. If the input
		has an invalid format it will return EINVAL. If the device path cannot
		be found on the server, it will fail with ENOENT.

		Finding device file after mapping
		---------------------------------

		After mapping, the device file can be found by:
		o  The symlink /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>
		points to /sys/block/<dev-name>. The last part of the symlink destination
		is the same as the device name.  By extracting the last part of the
		path the path to the device /dev/<dev-name> can be build.

		* /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>/dev)

		How to find the <device_id> of the device is described on the next
		section.

What:		/sys/class/rnbd-client/ctl/devices/
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	For each device mapped on the client a new symbolic link is created as
		/sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>, which points
		to the block device created by rnbd (/sys/block/rnbd<N>/).
		The <device_id> of each device is created as follows:

		- If the 'device_path' provided during mapping contains slashes ("/"),
		  they are replaced by exclamation mark ("!") and used as as the
		  <device_id>. Otherwise, the <device_id> will be the same as the
		  "device_path" provided.


code:
What:		/sys/class/rnbd-server
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	provide information about RNBD-server.

What:		/sys/class/rnbd-server/ctl/
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	When a client maps a device, a directory entry with the name of the
		block device is created under /sys/class/rnbd-server/ctl/devices/.

What:		/sys/class/rnbd-server/ctl/devices/<device_name>/block_dev
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Is a symlink to the sysfs entry of the exported device.

		Example:
		block_dev -> ../../../../class/block/ram0

What:		/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	For each client a particular device is exported to, following directory will be
		created:

		/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/

		When the device is unmapped by that client, the directory will be removed.

What:		/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/read_only
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains '1' if device is mapped read-only, otherwise '0'.

What:		/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/mapping_path
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains the relative device path provided by the user during mapping.

What:		/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/access_mode
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains the device access mode: ro, rw or migration.

What:		/sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/force_close
Date:		Nov 2020
KernelVersion:	5.10
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Write "1" to the file to close the device on server side. Please
		note that the client side device will not be closed, read or
		write to the device will get -ENOTCONN.


code:
What:		/sys/class/rtc/
Date:		March 2006
KernelVersion:	2.6.17
Contact:	linux-rtc@vger.kernel.org
Description:
		The rtc/ class subdirectory belongs to the RTC subsystem.

What:		/sys/class/rtc/rtcX/
Date:		March 2006
KernelVersion:	2.6.17
Contact:	linux-rtc@vger.kernel.org
Description:
		The /sys/class/rtc/rtc{0,1,2,3,...} directories correspond
		to each RTC device.

What:		/sys/class/rtc/rtcX/date
Date:		March 2006
KernelVersion:	2.6.17
Contact:	linux-rtc@vger.kernel.org
Description:
		(RO) RTC-provided date in YYYY-MM-DD format

What:		/sys/class/rtc/rtcX/hctosys
Date:		September 2009
KernelVersion:	2.6.32
Contact:	linux-rtc@vger.kernel.org
Description:
		(RO) 1 if the RTC provided the system time at boot via the
		CONFIG_RTC_HCTOSYS kernel option, 0 otherwise

What:		/sys/class/rtc/rtcX/max_user_freq
Date:		October 2007
KernelVersion:	2.6.24
Contact:	linux-rtc@vger.kernel.org
Description:
		(RW) The maximum interrupt rate an unprivileged user may request
		from this RTC.

What:		/sys/class/rtc/rtcX/name
Date:		March 2006
KernelVersion:	2.6.17
Contact:	linux-rtc@vger.kernel.org
Description:
		(RO) The name of the RTC corresponding to this sysfs directory

What:		/sys/class/rtc/rtcX/range
Date:		January 2018
KernelVersion:	4.16
Contact:	linux-rtc@vger.kernel.org
Description:
		Valid time range for the RTC, as seconds from epoch, formatted
		as [min, max]

What:		/sys/class/rtc/rtcX/since_epoch
Date:		March 2006
KernelVersion:	2.6.17
Contact:	linux-rtc@vger.kernel.org
Description:
		(RO) RTC-provided time as the number of seconds since the epoch

What:		/sys/class/rtc/rtcX/time
Date:		March 2006
KernelVersion:	2.6.17
Contact:	linux-rtc@vger.kernel.org
Description:
		(RO) RTC-provided time in 24-hour notation (hh:mm:ss)

What:		/sys/class/rtc/rtcX/offset
Date:		February 2016
KernelVersion:	4.6
Contact:	linux-rtc@vger.kernel.org
Description:
		(RW) The amount which the rtc clock has been adjusted in
		firmware. Visible only if the driver supports clock offset
		adjustment. The unit is parts per billion, i.e. The number of
		clock ticks which are added to or removed from the rtc's base
		clock per billion ticks. A positive value makes a day pass more
		slowly, longer, and a negative value makes a day pass more
		quickly.

What:		/sys/class/rtc/rtcX/wakealarm
Date:		February 2007
KernelVersion:	2.6.20
Contact:	linux-rtc@vger.kernel.org
Description:
		(RW) The time at which the clock will generate a system wakeup
		event. This is a one shot wakeup event, so must be reset after
		wake if a daily wakeup is required. Format is seconds since the
		epoch by default, or if there's a leading +, seconds in the
		future, or if there is a leading +=, seconds ahead of the
		current alarm.


code:
What:           /sys/class/rtc/rtc0/device/rtc_calibration
Date:           Oct 2011
KernelVersion:  3.0
Contact:        Mark Godfrey <mark.godfrey@stericsson.com>
Description:    Attribute for calibrating ST-Ericsson AB8500 Real Time Clock
		The rtc_calibration attribute allows the userspace to
                calibrate the AB8500.s 32KHz Real Time Clock.
                Every 60 seconds the AB8500 will correct the RTC's value
                by adding to it the value of this attribute.

                The range of the attribute is -127 to +127 in units of
                30.5 micro-seconds (half-parts-per-million of the 32KHz clock)
Users:          The /vendor/st-ericsson/base_utilities/core/rtc_calibration
                daemon uses this interface.


code:
What:		/sys/class/rtrs-client
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	When a user of RTRS API creates a new session, a directory entry with
		the name of that session is created under /sys/class/rtrs-client/<session-name>/

What:		/sys/class/rtrs-client/<session-name>/add_path
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RW, adds a new path (connection) to an existing session. Expected format is the
		following::

		    <[source addr,]destination addr>
		    *addr ::= [ ip:<ipv4|ipv6> | gid:<gid> ]

What:		/sys/class/rtrs-client/<session-name>/max_reconnect_attempts
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Maximum number reconnect attempts the client should make before giving up
		after connection breaks unexpectedly.

What:		/sys/class/rtrs-client/<session-name>/mp_policy
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Multipath policy specifies which path should be selected on each IO:

		round-robin (0):
		    select path in per CPU round-robin manner.

		min-inflight (1):
		    select path with minimum inflights.

		min-latency (2):
		    select path with minimum latency.

What:		/sys/class/rtrs-client/<session-name>/paths/
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Each path belonging to a given session is listed here by its source and
		destination address. When a new path is added to a session by writing to
		the "add_path" entry, a directory <src@dst> is created.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/state
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains "connected" if the session is connected to the peer and fully
		functional.  Otherwise the file contains "disconnected"

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/reconnect
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Write "1" to the file in order to reconnect the path.
		Operation is blocking and returns 0 if reconnect was successful.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/disconnect
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Write "1" to the file in order to disconnect the path.
		Operation blocks until RTRS path is disconnected.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/remove_path
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Write "1" to the file in order to disconnected and remove the path
		from the session.  Operation blocks until the path is disconnected
		and removed from the session.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_name
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the name of HCA the connection established on.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_port
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the port number of active port traffic is going through.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/src_addr
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the source address of the path

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/dst_addr
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the destination address of the path

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/cur_latency
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the latency time calculated by the heart-beat messages.
		Whenever the client sends heart-beat message, it checks the time gap
		between sending the heart-beat message and receiving the ACK.
		This value can be changed regularly.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reset_all
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RW, Read will return usage help, write 0 will clear all the statistics.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/cpu_migration
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RTRS expects that each HCA IRQ is pinned to a separate CPU. If it's
		not the case, the processing of an I/O response could be processed on a
		different CPU than where it was originally submitted.  This file shows
		how many interrupts where generated on a non expected CPU.

		"from:"
		    is the CPU on which the IRQ was expected, but not generated.
		"to:"
		    is the CPU on which the IRQ was generated, but not expected.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reconnects
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains 2 unsigned int values, the first one records number of successful
		reconnects in the path lifetime, the second one records number of failed
		reconnects in the path lifetime.

What:		/sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/rdma
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains statistics regarding rdma operations and inflight operations.
		The output consists of 6 values::

		    <read-count> <read-total-size> <write-count> \
		    <write-total-size> <inflights> <failovered>


code:
What:		/sys/class/rtrs-server
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	When a user of RTRS API creates a new session on a client side, a
		directory entry with the name of that session is created in here.

What:		/sys/class/rtrs-server/<session-name>/paths/
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	When new path is created by writing to "add_path" entry on client side,
		a directory entry named as <source address>@<destination address> is created
		on server.

What:		/sys/class/rtrs-server/<session-name>/paths/<src@dst>/disconnect
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	When "1" is written to the file, the RTRS session is being disconnected.
		Operations is non-blocking and returns control immediately to the caller.

What:		/sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_name
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the name of HCA the connection established on.

What:		/sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_port
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the port number of active port traffic is going through.

What:		/sys/class/rtrs-server/<session-name>/paths/<src@dst>/src_addr
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the source address of the path

What:		/sys/class/rtrs-server/<session-name>/paths/<src@dst>/dst_addr
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RO, Contains the destination address of the path

What:		/sys/class/rtrs-server/<session-name>/paths/<src@dst>/stats/rdma
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains statistics regarding rdma operations and inflight operations.
		The output consists of 5 values:
		<read-count> <read-total-size> <write-count> <write-total-size> <inflights>


code:
What:		/sys/class/scsi_host/hostX/isci_id
Date:		June 2011
Contact:	Dave Jiang <dave.jiang@intel.com>
Description:
		This file contains the enumerated host ID for the Intel
		SCU controller. The Intel(R) C600 Series Chipset SATA/SAS
		Storage Control Unit embeds up to two 4-port controllers in
		a single PCI device.  The controllers are enumerated in order
		which usually means the lowest number scsi_host corresponds
		with the first controller, but this association is not
		guaranteed.  The 'isci_id' attribute unambiguously identifies
		the controller index: '0' for the first controller,
		'1' for the second.

What:		/sys/class/scsi_host/hostX/acciopath_status
Date:		November 2013
Contact:	Stephen M. Cameron <scameron@beardog.cce.hp.com>
Description:	This file contains the current status of the "SSD Smart Path"
		feature of HP Smart Array RAID controllers using the hpsa
		driver.  SSD Smart Path, when enabled permits the driver to
		send i/o requests directly to physical devices that are part
		of a logical drive, bypassing the controllers firmware RAID
		stack for a performance advantage when possible.  A value of
		'1' indicates the feature is enabled, and the controller may
		use the direct i/o path to physical devices.  A value of zero
		means the feature is disabled and the controller may not use
		the direct i/o path to physical devices.  This setting is
		controller wide, affecting all configured logical drives on the
		controller.  This file is readable and writable.

What:		/sys/class/scsi_host/hostX/link_power_management_policy
Date:		Oct, 2007
KernelVersion:	v2.6.24
Contact:	linux-ide@vger.kernel.org
Description:
		(RW) This parameter allows the user to read and set the link
		(interface) power management.

		There are four possible options:

		min_power: Tell the controller to try to make the link use the
		least possible power when possible. This may sacrifice some
		performance due to increased latency when coming out of lower
		power states.

		max_performance: Generally, this means no power management.
		Tell the controller to have performance be a priority over power
		management.

		medium_power: Tell the controller to enter a lower power state
		when possible, but do not enter the lowest power state, thus
		improving latency over min_power setting.

		med_power_with_dipm: Identical to the existing medium_power
		setting except that it enables dipm (device initiated power
		management) on top, which makes it match the Windows IRST (Intel
		Rapid Storage Technology) driver settings. This setting is also
		close to min_power, except that:

		a) It does not use host-initiated slumber mode, but it does
		   allow device-initiated slumber
		b) It does not enable low power device sleep mode (DevSlp).

What:		/sys/class/scsi_host/hostX/em_message
What:		/sys/class/scsi_host/hostX/em_message_type
Date:		Jun, 2008
KernelVersion:	v2.6.27
Contact:	linux-ide@vger.kernel.org
Description:
		em_message: (RW) Enclosure management support. For the LED
		protocol, writes and reads correspond to the LED message format
		as defined in the AHCI spec.

		The user must turn sw_activity (under `/sys/block/*/device/`)
		OFF it they wish to control the activity LED via the em_message
		file.

		em_message_type: (RO) Displays the current enclosure management
		protocol that is being used by the driver (for eg. LED, SAF-TE,
		SES-2, SGPIO etc).

What:		/sys/class/scsi_host/hostX/ahci_port_cmd
What:		/sys/class/scsi_host/hostX/ahci_host_caps
What:		/sys/class/scsi_host/hostX/ahci_host_cap2
Date:		Mar, 2010
KernelVersion:	v2.6.35
Contact:	linux-ide@vger.kernel.org
Description:
		[to be documented]

What:		/sys/class/scsi_host/hostX/ahci_host_version
Date:		Mar, 2010
KernelVersion:	v2.6.35
Contact:	linux-ide@vger.kernel.org
Description:
		(RO) Display the version of the AHCI spec implemented by the
		host.

What:		/sys/class/scsi_host/hostX/em_buffer
Date:		Apr, 2010
KernelVersion:	v2.6.35
Contact:	linux-ide@vger.kernel.org
Description:
		(RW) Allows access to AHCI EM (enclosure management) buffer
		directly if the host supports EM.

		For eg. the AHCI driver supports SGPIO EM messages but the
		SATA/AHCI specs do not define the SGPIO message format of the EM
		buffer. Different hardware(HW) vendors may have different
		definitions. With the em_buffer attribute, this issue can be
		solved by allowing HW vendors to provide userland drivers and
		tools for their SGPIO initiators.

What:		/sys/class/scsi_host/hostX/em_message_supported
Date:		Oct, 2009
KernelVersion:	v2.6.39
Contact:	linux-ide@vger.kernel.org
Description:
		(RO) Displays supported enclosure management message types.


code:
What:           /sys/class/scsi_tape/*/stats/in_flight
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Show the number of I/Os currently in-flight between the st
		module and the SCSI mid-layer.
Users:

What:           /sys/class/scsi_tape/*/stats/io_ns
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total amount of time spent waiting for all I/O
                to and from the tape drive to complete. This includes all
                reads, writes, and other SCSI commands issued to the tape
                drive. An example of other SCSI commands would be tape
                movement such as a rewind when a rewind tape device is
                closed. This item is measured in nanoseconds.

                To determine the amount of time spent waiting for other I/O
                to complete subtract read_ns and write_ns from this value.
Users:

What:           /sys/class/scsi_tape/*/stats/other_cnt
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		The number of I/O requests issued to the tape drive other
		than SCSI read/write requests.
Users:

What:           /sys/class/scsi_tape/*/stats/read_byte_cnt
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total number of bytes requested from the tape drive.
		This value is presented in bytes because tape drives support
		variable length block sizes.
Users:

What:           /sys/class/scsi_tape/*/stats/read_cnt
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total number of read requests issued to the tape
		drive.
Users:

What:           /sys/class/scsi_tape/*/stats/read_ns
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total amount of time in nanoseconds waiting for
		read I/O requests to complete.
Users:

What:           /sys/class/scsi_tape/*/stats/write_byte_cnt
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total number of bytes written to the tape drive.
		This value is presented in bytes because tape drives support
		variable length block sizes.
Users:

What:           /sys/class/scsi_tape/*/stats/write_cnt
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total number of write requests issued to the tape
		drive.
Users:

What:           /sys/class/scsi_tape/*/stats/write_ms
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the total amount of time in nanoseconds waiting for
		write I/O requests to complete.
Users:

What:           /sys/class/scsi_tape/*/stats/resid_cnt
Date:           Apr 2015
KernelVersion:  4.2
Contact:        Shane Seymour <shane.seymour@hp.com>
Description:
		Shows the number of times we found that a residual >0
		was found when the SCSI midlayer indicated that there was
		an error. For reads this may be a case of someone issuing
		reads greater than the block size.
Users:


code:
What:		/sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fram
Date:		June 2021
KernelVersion:	5.14
Contact:	Jiri Prchal <jiri.prchal@aksignal.cz>
Description:
	Contains the FRAM binary data. Same as EEPROM, just another file
	name to indicate that it employs ferroelectric process.
	It performs write operations at bus speed - no write delays.

What:		/sys/class/spi_master/spi<bus>/spi<bus>.<dev>/sernum
Date:		May 2021
KernelVersion:	5.14
Contact:	Jiri Prchal <jiri.prchal@aksignal.cz>
Description:
	Contains the serial number of the Cypress FRAM (FM25VN) if it is
	present.  It will be displayed as a 8 byte hex string, as read
	from the device.

	This is a read-only attribute.


code:
What:		/sys/class/stm/<stm>/masters
Date:		June 2015
KernelVersion:	4.3
Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
		Shows first and last available to software master numbers on
		this STM device.

What:		/sys/class/stm/<stm>/channels
Date:		June 2015
KernelVersion:	4.3
Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
		Shows the number of channels per master on this STM device.

What:		/sys/class/stm/<stm>/hw_override
Date:		March 2016
KernelVersion:	4.7
Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
		Reads as 0 if master numbers in the STP stream produced by
		this stm device will match the master numbers assigned by
		the software or 1 if the stm hardware overrides software
		assigned masters.


code:
What:		/sys/class/stm_source/<stm_source>/stm_source_link
Date:		June 2015
KernelVersion:	4.3
Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
		stm_source device linkage to stm device, where its tracing data
		is directed. Reads return an existing connection or "<none>" if
		this stm_source is not connected to any stm device yet.
		Write an existing (registered) stm device's name here to
		connect that device. If a device is already connected to this
		stm_source, it will first be disconnected.


code:
switchtec - Microsemi Switchtec PCI Switch Management Endpoint

For details on this subsystem look at Documentation/driver-api/switchtec.rst.

What: 		/sys/class/switchtec
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	The switchtec class subsystem folder.
		Each registered switchtec driver is represented by a switchtecX
		subfolder (X being an integer >= 0).

What:		/sys/class/switchtec/switchtec[0-9]+/component_id
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Component identifier as stored in the hardware (eg. PM8543)
		(read only)
Values: 	arbitrary string.

What:		/sys/class/switchtec/switchtec[0-9]+/component_revision
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Component revision stored in the hardware (read only)
Values: 	integer.

What:		/sys/class/switchtec/switchtec[0-9]+/component_vendor
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Component vendor as stored in the hardware (eg. MICROSEM)
		(read only)
Values: 	arbitrary string.

What:		/sys/class/switchtec/switchtec[0-9]+/device_version
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Device version as stored in the hardware (read only)
Values: 	integer.

What:		/sys/class/switchtec/switchtec[0-9]+/fw_version
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Currently running firmware version (read only)
Values: 	integer (in hexadecimal).

What:		/sys/class/switchtec/switchtec[0-9]+/partition
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Partition number for this device in the switch (read only)
Values: 	integer.

What:		/sys/class/switchtec/switchtec[0-9]+/partition_count
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Total number of partitions in the switch (read only)
Values: 	integer.

What:		/sys/class/switchtec/switchtec[0-9]+/product_id
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Product identifier as stored in the hardware (eg. PSX 48XG3)
		(read only)
Values: 	arbitrary string.

What:		/sys/class/switchtec/switchtec[0-9]+/product_revision
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Product revision stored in the hardware (eg. RevB)
		(read only)
Values: 	arbitrary string.

What:		/sys/class/switchtec/switchtec[0-9]+/product_vendor
Date:		05-Jan-2017
KernelVersion:	v4.11
Contact:	Logan Gunthorpe <logang@deltatee.com>
Description:	Product vendor as stored in the hardware (eg. MICROSEM)
		(read only)
Values: 	arbitrary string.