code:
What:		/dev/wmi/dell-smbios
Date:		November 2017
KernelVersion:	4.15
Contact:	Dell.Client.Kernel@dell.com
Description:
		Perform SMBIOS calls on supported Dell machines.
		through the Dell ACPI-WMI interface.

		IOCTL's and buffer formats are defined in:
		<uapi/linux/wmi.h>

		1) To perform an SMBIOS call from userspace, you'll need to
		   first determine the minimum size of the calling interface
		   buffer for your machine.
		   Platforms that contain larger buffers can return larger
		   objects from the system firmware.
		   Commonly this size is either 4k or 32k.

		   To determine the size of the buffer read() a u64 dword from
		   the WMI character device /dev/wmi/dell-smbios.

		2) After you've determined the minimum size of the calling
		   interface buffer, you can allocate a structure that represents
		   the structure documented above.

		3) In the 'length' object store the size of the buffer you
		   determined above and allocated.

		4) In this buffer object, prepare as necessary for the SMBIOS
		   call you're interested in.  Typically SMBIOS buffers have
		   "class", "select", and "input" defined to values that coincide
		   with the data you are interested in.
		   Documenting class/select/input values is outside of the scope
		   of this documentation. Check with the libsmbios project for
		   further documentation on these values.

		6) Run the call by using ioctl() as described in the header.

		7) The output will be returned in the buffer object.

		8) Be sure to free up your allocated object.


code:
What:		/dev/kmsg
Date:		Mai 2012
KernelVersion:	3.5
Contact:	Kay Sievers <kay@vrfy.org>
Description:	The /dev/kmsg character device node provides userspace access
		to the kernel's printk buffer.

		Injecting messages:

		Every write() to the opened device node places a log entry in
		the kernel's printk buffer.

		The logged line can be prefixed with a <N> syslog prefix, which
		carries the syslog priority and facility. The single decimal
		prefix number is composed of the 3 lowest bits being the syslog
		priority and the next 8 bits the syslog facility number.

		If no prefix is given, the priority number is the default kernel
		log priority and the facility number is set to LOG_USER (1). It
		is not possible to inject messages from userspace with the
		facility number LOG_KERN (0), to make sure that the origin of
		the messages can always be reliably determined.

		Accessing the buffer:

		Every read() from the opened device node receives one record
		of the kernel's printk buffer.

		The first read() directly following an open() always returns
		first message in the buffer; there is no kernel-internal
		persistent state; many readers can concurrently open the device
		and read from it, without affecting other readers.

		Every read() will receive the next available record. If no more
		records are available read() will block, or if O_NONBLOCK is
		used -EAGAIN returned.

		Messages in the record ring buffer get overwritten as whole,
		there are never partial messages received by read().

		In case messages get overwritten in the circular buffer while
		the device is kept open, the next read() will return -EPIPE,
		and the seek position be updated to the next available record.
		Subsequent reads() will return available records again.

		Unlike the classic syslog() interface, the 64 bit record
		sequence numbers allow to calculate the amount of lost
		messages, in case the buffer gets overwritten. And they allow
		to reconnect to the buffer and reconstruct the read position
		if needed, without limiting the interface to a single reader.

		The device supports seek with the following parameters:

		SEEK_SET, 0
		  seek to the first entry in the buffer
		SEEK_END, 0
		  seek after the last entry in the buffer
		SEEK_DATA, 0
		  seek after the last record available at the time
		  the last SYSLOG_ACTION_CLEAR was issued.

		Other seek operations or offsets are not supported because of
		the special behavior this device has. The device allows to read
		or write only whole variable length messages (records) that are
		stored in a ring buffer.

		Because of the non-standard behavior also the error values are
		non-standard. -ESPIPE is returned for non-zero offset. -EINVAL
		is returned for other operations, e.g. SEEK_CUR. This behavior
		and values are historical and could not be modified without the
		risk of breaking userspace.

		The output format consists of a prefix carrying the syslog
		prefix including priority and facility, the 64 bit message
		sequence number and the monotonic timestamp in microseconds,
		and a flag field. All fields are separated by a ','.

		Future extensions might add more comma separated values before
		the terminating ';'. Unknown fields and values should be
		gracefully ignored.

		The human readable text string starts directly after the ';'
		and is terminated by a '\n'. Untrusted values derived from
		hardware or other facilities are printed, therefore
		all non-printable characters and '\' itself in the log message
		are escaped by "\x00" C-style hex encoding.

		A line starting with ' ', is a continuation line, adding
		key/value pairs to the log message, which provide the machine
		readable context of the message, for reliable processing in
		userspace.

		Example::

		  7,160,424069,-;pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7] (ignored)
		   SUBSYSTEM=acpi
		   DEVICE=+acpi:PNP0A03:00
		  6,339,5140900,-;NET: Registered protocol family 10
		  30,340,5690716,-;udevd[80]: starting version 181

		The DEVICE= key uniquely identifies devices the following way:

		  ============  =================
		  b12:8         block dev_t
		  c127:3        char dev_t
		  n8            netdev ifindex
		  +sound:card0  subsystem:devname
		  ============  =================

		The flags field carries '-' by default. A 'c' indicates a
		fragment of a line. Note, that these hints about continuation
		lines are not necessarily correct, and the stream could be
		interleaved with unrelated messages, but merging the lines in
		the output usually produces better human readable results. A
		similar logic is used internally when messages are printed to
		the console, /proc/kmsg or the syslog() syscall.

		By default, kernel tries to avoid fragments by concatenating
		when it can and fragments are rare; however, when extended
		console support is enabled, the in-kernel concatenation is
		disabled and /dev/kmsg output will contain more fragments. If
		the log consumer performs concatenation, the end result
		should be the same. In the future, the in-kernel concatenation
		may be removed entirely and /dev/kmsg users are recommended to
		implement fragment handling.

Users:		dmesg(1), userspace kernel log consumers

repo_name: angery/linux

path: Documentation/ABI/testing/dev-kmsg


code:
What: 		/kvd/
Date:		08-Jan-2018
KernelVersion:	v4.16
Contact:	mlxsw@mellanox.com
Description:	The main database in the Spectrum device is a centralized
		KVD database used for many of the tables used to configure
		the chip including L2 FDB, L3 LPM, ECMP and more. The KVD
		is divided into two sections, the first is hash-based table
		and the second is a linear access table. The division
		between the linear and hash-based sections is static and
		require reload before the changes take effect.

What: 		/kvd/linear
Date:		08-Jan-2018
KernelVersion:	v4.16
Contact:	mlxsw@mellanox.com
Description:	The linear section of the KVD is managed by software as a
		flat memory accessed using an index.

What: 		/kvd/hash_single
Date:		08-Jan-2018
KernelVersion:	v4.16
Contact:	mlxsw@mellanox.com
Description:	The hash based section of the KVD is managed by the switch
		device. Used in case the key size is smaller or equal to
		64bit.

What: 		/kvd/hash_double
Date:		08-Jan-2018
KernelVersion:	v4.16
Contact:	mlxsw@mellanox.com
Description:	The hash based section of the KVD is managed by the switch
		device. Used in case the key is larger than 64 bit.


code:
What:		/sys/kernel/security/evm
What:		/sys/kernel/security/*/evm
Date:		March 2011
Contact:	Mimi Zohar <zohar@us.ibm.com>
Description:
		EVM protects a file's security extended attributes(xattrs)
		against integrity attacks. The initial method maintains an
		HMAC-sha1 value across the extended attributes, storing the
		value as the extended attribute 'security.evm'.

		EVM supports two classes of security.evm. The first is
		an HMAC-sha1 generated locally with a
		trusted/encrypted key stored in the Kernel Key
		Retention System. The second is a digital signature
		generated either locally or remotely using an
		asymmetric key. These keys are loaded onto root's
		keyring using keyctl, and EVM is then enabled by
		echoing a value to <securityfs>/evm made up of the
		following bits:

		===	  ==================================================
		Bit	  Effect
		===	  ==================================================
		0	  Enable HMAC validation and creation
		1	  Enable digital signature validation
		2	  Permit modification of EVM-protected metadata at
			  runtime. Not supported if HMAC validation and
			  creation is enabled (deprecated).
		31	  Disable further runtime modification of EVM policy
		===	  ==================================================

		For example::

		  echo 1 ><securityfs>/evm

		will enable HMAC validation and creation

		::

		  echo 0x80000003 ><securityfs>/evm

		will enable HMAC and digital signature validation and
		HMAC creation and disable all further modification of policy.

		::

		  echo 0x80000006 ><securityfs>/evm

		will enable digital signature validation, permit
		modification of EVM-protected metadata and
		disable all further modification of policy. This option is now
		deprecated in favor of::

		  echo 0x80000002 ><securityfs>/evm

		as the outstanding issues that prevent the usage of EVM portable
		signatures have been solved.

		Echoing a value is additive, the new value is added to the
		existing initialization flags.

		For example, after::

		  echo 2 ><securityfs>/evm

		another echo can be performed::

		  echo 1 ><securityfs>/evm

		and the resulting value will be 3.

		Note that once an HMAC key has been loaded, it will no longer
		be possible to enable metadata modification. Signaling that an
		HMAC key has been loaded will clear the corresponding flag.
		For example, if the current value is 6 (2 and 4 set)::

		  echo 1 ><securityfs>/evm

		will set the new value to 3 (4 cleared).

		Loading an HMAC key is the only way to disable metadata
		modification.

		Until key loading has been signaled EVM can not create
		or validate the 'security.evm' xattr, but returns
		INTEGRITY_UNKNOWN.  Loading keys and signaling EVM
		should be done as early as possible.  Normally this is
		done in the initramfs, which has already been measured
		as part of the trusted boot.  For more information on
		creating and loading existing trusted/encrypted keys,
		refer to:
		Documentation/security/keys/trusted-encrypted.rst. Both
		dracut (via 97masterkey and 98integrity) and systemd (via
		core/ima-setup) have support for loading keys at boot
		time.

What:		/sys/kernel/security/*/evm/evm_xattrs
Date:		April 2018
Contact:	Matthew Garrett <mjg59@google.com>
Description:
		Shows the set of extended attributes used to calculate or
		validate the EVM signature, and allows additional attributes
		to be added at runtime. Any signatures generated after
		additional attributes are added (and on files possessing those
		additional attributes) will only be valid if the same
		additional attributes are configured on system boot. Writing
		a single period (.) will lock the xattr list from any further
		modification.

path: Documentation/ABI/testing/evm


code:
What:		/dev/gpiochip[0-9]+
Date:		November 2015
KernelVersion:	4.4
Contact:	linux-gpio@vger.kernel.org
Description:
		The character device files /dev/gpiochip* are the interface
		between GPIO chips and userspace.

		The ioctl(2)-based ABI is defined and documented in
		[include/uapi]<linux/gpio.h>.

		The following file operations are supported:

		open(2)
		  Currently the only useful flags are O_RDWR.

		ioctl(2)
		  Initiate various actions.

		  See the inline documentation in [include/uapi]<linux/gpio.h>
		  for descriptions of all ioctls.

		close(2)
		  Stops and free up the I/O contexts that was associated
		  with the file descriptor.

Users:		TBD

path: Documentation/ABI/testing/gpio-cdev


code:
What:		/sys/kernel/security/*/ima/policy
Date:		May 2008
Contact:	Mimi Zohar <zohar@us.ibm.com>
Description:
		The Trusted Computing Group(TCG) runtime Integrity
		Measurement Architecture(IMA) maintains a list of hash
		values of executables and other sensitive system files
		loaded into the run-time of this system.  At runtime,
		the policy can be constrained based on LSM specific data.
		Policies are loaded into the securityfs file ima/policy
		by opening the file, writing the rules one at a time and
		then closing the file.  The new policy takes effect after
		the file ima/policy is closed.

		IMA appraisal, if configured, uses these file measurements
		for local measurement appraisal.

		::

		  rule format: action [condition ...]

		  action: measure | dont_measure | appraise | dont_appraise |
			  audit | hash | dont_hash
		  condition:= base | lsm  [option]
			base:	[[func=] [mask=] [fsmagic=] [fsuuid=] [fsname=]
				[uid=] [euid=] [gid=] [egid=]
				[fowner=] [fgroup=]]
			lsm:	[[subj_user=] [subj_role=] [subj_type=]
				 [obj_user=] [obj_role=] [obj_type=]]
			option:	[digest_type=] [template=] [permit_directio]
				[appraise_type=] [appraise_flag=]
				[appraise_algos=] [keyrings=]
		  base:
			func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
				[FIRMWARE_CHECK]
				[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
				[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
				[SETXATTR_CHECK]
			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
			       [[^]MAY_EXEC]
			fsmagic:= hex value
			fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
			uid:= decimal value
			euid:= decimal value
			gid:= decimal value
			egid:= decimal value
			fowner:= decimal value
			fgroup:= decimal value
		  lsm:  are LSM specific
		  option:
			appraise_type:= [imasig] | [imasig|modsig] | [sigv3]
			    where 'imasig' is the original or the signature
				format v2.
			    where 'modsig' is an appended signature,
			    where 'sigv3' is the signature format v3. (Currently
				limited to fsverity digest based signatures
				stored in security.ima xattr. Requires
				specifying "digest_type=verity" first.)

			appraise_flag:= [check_blacklist]
			Currently, blacklist check is only for files signed with appended
			signature.
			digest_type:= verity
			    Require fs-verity's file digest instead of the
			    regular IMA file hash.
			keyrings:= list of keyrings
			(eg, .builtin_trusted_keys|.ima). Only valid
			when action is "measure" and func is KEY_CHECK.
			template:= name of a defined IMA template type
			(eg, ima-ng). Only valid when action is "measure".
			pcr:= decimal value
			label:= [selinux]|[kernel_info]|[data_label]
			data_label:= a unique string used for grouping and limiting critical data.
			For example, "selinux" to measure critical data for SELinux.
			appraise_algos:= comma-separated list of hash algorithms
			For example, "sha256,sha512" to only accept to appraise
			files where the security.ima xattr was hashed with one
			of these two algorithms.

		  default policy:
			# PROC_SUPER_MAGIC
			dont_measure fsmagic=0x9fa0
			dont_appraise fsmagic=0x9fa0
			# SYSFS_MAGIC
			dont_measure fsmagic=0x62656572
			dont_appraise fsmagic=0x62656572
			# DEBUGFS_MAGIC
			dont_measure fsmagic=0x64626720
			dont_appraise fsmagic=0x64626720
			# TMPFS_MAGIC
			dont_measure fsmagic=0x01021994
			dont_appraise fsmagic=0x01021994
			# RAMFS_MAGIC
			dont_appraise fsmagic=0x858458f6
			# DEVPTS_SUPER_MAGIC
			dont_measure fsmagic=0x1cd1
			dont_appraise fsmagic=0x1cd1
			# BINFMTFS_MAGIC
			dont_measure fsmagic=0x42494e4d
			dont_appraise fsmagic=0x42494e4d
			# SECURITYFS_MAGIC
			dont_measure fsmagic=0x73636673
			dont_appraise fsmagic=0x73636673
			# SELINUX_MAGIC
			dont_measure fsmagic=0xf97cff8c
			dont_appraise fsmagic=0xf97cff8c
			# CGROUP_SUPER_MAGIC
			dont_measure fsmagic=0x27e0eb
			dont_appraise fsmagic=0x27e0eb
			# NSFS_MAGIC
			dont_measure fsmagic=0x6e736673
			dont_appraise fsmagic=0x6e736673

			measure func=BPRM_CHECK
			measure func=FILE_MMAP mask=MAY_EXEC
			measure func=FILE_CHECK mask=MAY_READ uid=0
			measure func=MODULE_CHECK
			measure func=FIRMWARE_CHECK
			appraise fowner=0

		The default policy measures all executables in bprm_check,
		all files mmapped executable in file_mmap, and all files
		open for read by root in do_filp_open.  The default appraisal
		policy appraises all files owned by root.

		Examples of LSM specific definitions:

		SELinux::

			dont_measure obj_type=var_log_t
			dont_appraise obj_type=var_log_t
			dont_measure obj_type=auditd_log_t
			dont_appraise obj_type=auditd_log_t
			measure subj_user=system_u func=FILE_CHECK mask=MAY_READ
			measure subj_role=system_r func=FILE_CHECK mask=MAY_READ

		Smack::

			measure subj_user=_ func=FILE_CHECK mask=MAY_READ

		Example of measure rules using alternate PCRs::

			measure func=KEXEC_KERNEL_CHECK pcr=4
			measure func=KEXEC_INITRAMFS_CHECK pcr=5

		Example of appraise rule allowing modsig appended signatures:

			appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig

		Example of measure rule using KEY_CHECK to measure all keys:

			measure func=KEY_CHECK

		Example of measure rule using KEY_CHECK to only measure
		keys added to .builtin_trusted_keys or .ima keyring:

			measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima

		Example of the special SETXATTR_CHECK appraise rule, that
		restricts the hash algorithms allowed when writing to the
		security.ima xattr of a file:

			appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512

		Example of a 'measure' rule requiring fs-verity's digests
		with indication of type of digest in the measurement list.

			measure func=FILE_CHECK digest_type=verity \
				template=ima-ngv2

		Example of 'measure' and 'appraise' rules requiring fs-verity
		signatures (format version 3) stored in security.ima xattr.

		The 'measure' rule specifies the 'ima-sigv3' template option,
		which includes the indication of type of digest and the file
		signature in the measurement list.

			measure func=BPRM_CHECK digest_type=verity \
				template=ima-sigv3

		The 'appraise' rule specifies the type and signature format
		version (sigv3) required.

			appraise func=BPRM_CHECK digest_type=verity \
				appraise_type=sigv3

		All of these policy rules could, for example, be constrained
		either based on a filesystem's UUID (fsuuid) or based on LSM
		labels.


code:
What:		/sys/kernel/debug/powerpc/memtrace
Date:		Aug 2017
KernelVersion:	4.14
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	This folder contains the relevant debugfs files for the
		hardware trace macro to use. CONFIG_PPC64_HARDWARE_TRACING
		must be set.

What:		/sys/kernel/debug/powerpc/memtrace/enable
Date:		Aug 2017
KernelVersion:	4.14
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	Write an integer containing the size in bytes of the memory
		you want removed from each NUMA node to this file - it must be
		aligned to the memblock size. This amount of RAM will be removed
		from each NUMA node in the kernel mappings and the following
		debugfs files will be created. Once memory is successfully
		removed from each node, the following files are created. To
		re-add memory to the kernel, echo 0 into this file (it will be
		automatically onlined).

What:		/sys/kernel/debug/powerpc/memtrace/<node-id>
Date:		Aug 2017
KernelVersion:	4.14
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	This directory contains information about the removed memory
		from the specific NUMA node.

What:		/sys/kernel/debug/powerpc/memtrace/<node-id>/size
Date:		Aug 2017
KernelVersion:	4.14
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	This contains the size of the memory removed from the node.

What:		/sys/kernel/debug/powerpc/memtrace/<node-id>/start
Date:		Aug 2017
KernelVersion:	4.14
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	This contains the start address of the removed memory.

What:		/sys/kernel/debug/powerpc/memtrace/<node-id>/trace
Date:		Aug 2017
KernelVersion:	4.14
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	This is where the hardware trace macro will output the trace
		it generates.

path: Documentation/ABI/testing/ppc-memtrace


code:
What:		/proc/*/attr/current
Contact:	linux-security-module@vger.kernel.org,
		selinux@vger.kernel.org,
		apparmor@lists.ubuntu.com
Description:	The current security information used by a Linux
		security module (LSM) that is active on the system.
		The details of permissions required to read from
		this interface and hence obtain the security state
		of the task identified is LSM dependent.
		A process cannot write to this interface unless it
		refers to itself.
		The other details of permissions required to write to
		this interface and hence change the security state of
		the task identified are LSM dependent.
		The format of the data used by this interface is LSM
		dependent.
		SELinux, Smack and AppArmor provide this interface.
Users:		SELinux user-space
		Smack user-space
		AppArmor user-space


code:
What:		/proc/*/attr/exec
Contact:	linux-security-module@vger.kernel.org,
		selinux@vger.kernel.org,
		apparmor@lists.ubuntu.com
Description:	The security information to be used on the process
		by a Linux security module (LSM) active on the system
		after a subsequent exec() call.
		The details of permissions required to read from
		this interface and hence obtain the security state
		of the task identified is LSM dependent.
		A process cannot write to this interface unless it
		refers to itself.
		The other details of permissions required to write to
		this interface and hence change the security state of
		the task identified are LSM dependent.
		The format of the data used by this interface is LSM
		dependent.
		SELinux and AppArmor provide this interface.
Users:		SELinux user-space
		AppArmor user-space


code:
What:		/proc/*/attr/prev
Contact:	linux-security-module@vger.kernel.org,
		selinux@vger.kernel.org,
		apparmor@lists.ubuntu.com
Description:	The security information used on the process by
		a Linux security module (LSM) active on the system
		prior to the most recent exec() call.
		The details of permissions required to read from
		this interface is LSM dependent.
		A process cannot write to this interface unless it
		refers to itself.
		The other details of permissions required to write to
		this interface are LSM dependent.
		The format of the data used by this interface is LSM
		dependent.
		SELinux and AppArmor provide this interface.
Users:		SELinux user-space
		AppArmor user-space


code:
What:		/proc/diskstats
Date:		February 2008
Contact:	Jerome Marchand <jmarchan@redhat.com>
Description:
		The /proc/diskstats file displays the I/O statistics
		of block devices. Each line contains the following 14
		fields:

		==  ===================================
		 1  major number
		 2  minor mumber
		 3  device name
		 4  reads completed successfully
		 5  reads merged
		 6  sectors read
		 7  time spent reading (ms)
		 8  writes completed
		 9  writes merged
		10  sectors written
		11  time spent writing (ms)
		12  I/Os currently in progress
		13  time spent doing I/Os (ms)
		14  weighted time spent doing I/Os (ms)
		==  ===================================

		Kernel 4.18+ appends four more fields for discard
		tracking putting the total at 18:

		==  ===================================
		15  discards completed successfully
		16  discards merged
		17  sectors discarded
		18  time spent discarding
		==  ===================================

		Kernel 5.5+ appends two more fields for flush requests:

		==  =====================================
		19  flush requests completed successfully
		20  time spent flushing
		==  =====================================

		For more details refer to Documentation/admin-guide/iostats.rst


code:
What:		/proc/pid/smaps_rollup
Date:		August 2017
Contact:	Daniel Colascione <dancol@google.com>
Description:
		This file provides pre-summed memory information for a
		process.  The format is almost identical to /proc/pid/smaps,
		except instead of an entry for each VMA in a process,
		smaps_rollup has a single entry (tagged "[rollup]")
		for which each field is the sum of the corresponding
		fields from all the maps in /proc/pid/smaps.
		Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem
		are not present in /proc/pid/smaps.  These fields represent
		the sum of the Pss field of each type (anon, file, shmem).
		For more details, see Documentation/filesystems/proc.rst
		and the procfs man page.

		Typical output looks like this::

			00100000-ff709000 ---p 00000000 00:00 0		 [rollup]
			Size:               1192 kB
			KernelPageSize:        4 kB
			MMUPageSize:           4 kB
			Rss:		     884 kB
			Pss:		     385 kB
			Pss_Dirty:	      68 kB
			Pss_Anon:	     301 kB
			Pss_File:	      80 kB
			Pss_Shmem:	       4 kB
			Shared_Clean:	     696 kB
			Shared_Dirty:	       0 kB
			Private_Clean:	     120 kB
			Private_Dirty:	      68 kB
			Referenced:	     884 kB
			Anonymous:	      68 kB
			LazyFree:	       0 kB
			AnonHugePages:	       0 kB
			ShmemPmdMapped:	       0 kB
			Shared_Hugetlb:	       0 kB
			Private_Hugetlb:       0 kB
			Swap:		       0 kB
			SwapPss:	       0 kB
			Locked:		     385 kB


code:
What:		/sys/fs/pstore/...
What:		/dev/pstore/...
Date:		March 2011
KernelVersion: 2.6.39
Contact:	tony.luck@intel.com
Description:	Generic interface to platform dependent persistent storage.

		Platforms that provide a mechanism to preserve some data
		across system reboots can register with this driver to
		provide a generic interface to show records captured in
		the dying moments.  In the case of a panic the last part
		of the console log is captured, but other interesting
		data can also be saved::

		    # mount -t pstore -o kmsg_bytes=8000 - /sys/fs/pstore

		    $ ls -l /sys/fs/pstore/
		    total 0
		    -r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1

		Different users of this interface will result in different
		filename prefixes.  Currently two are defined:

		- "dmesg" - saved console log
		- "mce"   - architecture dependent data from fatal h/w error

		Once the information in a file has been read, removing
		the file will signal to the underlying persistent storage
		device that it can reclaim the space for later re-use::

		    $ rm /sys/fs/pstore/dmesg-erst-1

		The expectation is that all files in /sys/fs/pstore/
		will be saved elsewhere and erased from persistent store
		soon after boot to free up space ready for the next
		catastrophe.

		The 'kmsg_bytes' mount option changes the target amount of
		data saved on each oops/panic. Pstore saves (possibly
		multiple) files based on the record size of the underlying
		persistent storage until at least this amount is reached.
		Default is 10 Kbytes.

		Pstore only supports one backend at a time. If multiple
		backends are available, the preferred backend may be
		set by passing the pstore.backend= argument to the kernel at
		boot time.

path: Documentation/ABI/testing/pstore


code:
What:		/dev/rtcX
Date:		April 2005
KernelVersion:	2.6.12
Contact:	linux-rtc@vger.kernel.org
Description:
		The ioctl interface to drivers for real-time clocks (RTCs).
		Following actions are supported:

		* RTC_RD_TIME, RTC_SET_TIME: Read or set the RTC time. Time
		  format is a Gregorian calendar date and 24 hour wall clock
		  time.

		* RTC_AIE_ON, RTC_AIE_OFF: Enable or disable the alarm interrupt
		  for RTCs that support alarms

		* RTC_ALM_READ, RTC_ALM_SET: Read or set the alarm time for
		  RTCs that support alarms. Can be set upto 24 hours in the
		  future. Requires a separate RTC_AIE_ON call to enable the
		  alarm interrupt. (Prefer to use RTC_WKALM_*)

		* RTC_WKALM_RD, RTC_WKALM_SET: For RTCs that support a more
		  powerful interface, which can issue alarms beyond 24 hours and
		  enable IRQs in the same request.

		* RTC_PIE_ON, RTC_PIE_OFF: Enable or disable the periodic
		  interrupt for RTCs that support periodic interrupts.

		* RTC_UIE_ON, RTC_UIE_OFF: Enable or disable the update
		  interrupt for RTCs that support it.

		* RTC_IRQP_READ, RTC_IRQP_SET: Read or set the frequency for
		  periodic interrupts for RTCs that support periodic interrupts.
		  Requires a separate RTC_PIE_ON call to enable the periodic
		  interrupts.

		* RTC_VL_READ: Read the voltage inputs status of the RTC when
		  supported. The value is a bit field of RTC_VL_*, giving the
		  status of the main and backup voltages.

		* RTC_VL_CLEAR: Clear the voltage status of the RTC. Some RTCs
		  need user interaction when the backup power provider is
		  replaced or charged to be able to clear the status.

		The ioctl() calls supported by the older /dev/rtc interface are
		also supported by the newer RTC class framework. However,
		because the chips and systems are not standardized, some PC/AT
		functionality might not be provided. And in the same way, some
		newer features -- including those enabled by ACPI -- are exposed
		by the RTC class framework, but can't be supported by the older
		driver.

path: Documentation/ABI/testing/rtc-cdev


code:
What:		security/secrets/coco
Date:		February 2022
Contact:	Dov Murik <dovmurik@linux.ibm.com>
Description:
		Exposes confidential computing (coco) EFI secrets to
		userspace via securityfs.

		EFI can declare memory area used by confidential computing
		platforms (such as AMD SEV and SEV-ES) for secret injection by
		the Guest Owner during VM's launch.  The secrets are encrypted
		by the Guest Owner and decrypted inside the trusted enclave,
		and therefore are not readable by the untrusted host.

		The efi_secret module exposes the secrets to userspace.  Each
		secret appears as a file under <securityfs>/secrets/coco,
		where the filename is the GUID of the entry in the secrets
		table.  This module is loaded automatically by the EFI driver
		if the EFI secret area is populated.

		Two operations are supported for the files: read and unlink.
		Reading the file returns the content of secret entry.
		Unlinking the file overwrites the secret data with zeroes and
		removes the entry from the filesystem.  A secret cannot be read
		after it has been unlinked.

		For example, listing the available secrets::

		  # modprobe efi_secret
		  # ls -l /sys/kernel/security/secrets/coco
		  -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
		  -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
		  -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
		  -r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910

		Reading the secret data by reading a file::

		  # cat /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
		  the-content-of-the-secret-data

		Wiping a secret by unlinking a file::

		  # rm /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
		  # ls -l /sys/kernel/security/secrets/coco
		  -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
		  -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
		  -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2

		Note: The binary format of the secrets table injected by the
		Guest Owner is described in
		drivers/virt/coco/efi_secret/efi_secret.c under "Structure of
		the EFI secret area".


code:
What:		/sys/bus/platform/drivers/amd_pmc/*/smu_fw_version
Date:		October 2022
Contact:	Mario Limonciello <mario.limonciello@amd.com>
Description:	Reading this file reports the version of the firmware loaded to
		System Management Unit (SMU) contained in AMD CPUs and
		APUs.

What:		/sys/bus/platform/drivers/amd_pmc/*/smu_program
Date:		October 2022
Contact:	Mario Limonciello <mario.limonciello@amd.com>
Description:	Reading this file reports the program corresponding to the SMU
		firmware version.  The program field is used to disambiguate two
		APU/CPU models that can share the same firmware binary.

path: Documentation/ABI/testing/sysfs-amd-pmc


code:
What:		/sys/devices/platform/*/cnqf_enable
Date:		September 2022
Contact:	Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Description:	Reading this file tells if the AMD Platform Management(PMF)
		Cool n Quiet Framework(CnQF) feature is enabled or not.

		This feature is not enabled by default and gets only turned on
		if OEM BIOS passes a "flag" to PMF ACPI function (index 11 or 12)
		or in case the user writes "on".

		To turn off CnQF user can write "off" to the sysfs node.
		Note: Systems that support auto mode will not have this sysfs file
		available.

path: Documentation/ABI/testing/sysfs-amd-pmf


code:
What:		/sys/class/ata_*
Description:
		Provide a place in sysfs for storing the ATA topology of the
		system. This allows retrieving various information about ATA
		objects.

Files under /sys/class/ata_port
-------------------------------

For each port, a directory ataX is created where X is the ata_port_id of the
port. The device parent is the ata host device.

What:		/sys/class/ata_port/ataX/nr_pmp_links
What:		/sys/class/ata_port/ataX/idle_irq
Date:		May, 2010
KernelVersion:	v2.6.37
Contact:	Gwendal Grignou <gwendal@chromium.org>
Description:
		nr_pmp_links:	(RO) If a SATA Port Multiplier (PM) is
				connected, the number of links behind it.

		idle_irq:	(RO) Number of IRQ received by the port while
				idle [some ata HBA only].

What:		/sys/class/ata_port/ataX/port_no
Date:		May, 2013
KernelVersion:	v3.11
Contact:	Gwendal Grignou <gwendal@chromium.org>
Description:
		(RO) Host local port number. While registering host controller,
		port numbers are tracked based upon number of ports available on
		the controller. This attribute is needed by udev for composing
		persistent links in /dev/disk/by-path.

Files under /sys/class/ata_link
-------------------------------

Behind each port, there is a ata_link. If there is a SATA PM in the topology, 15
ata_link objects are created.

If a link is behind a port, the directory name is linkX, where X is ata_port_id
of the port. If a link is behind a PM, its name is linkX.Y where X is
ata_port_id of the parent port and Y the PM port.

What:		/sys/class/ata_link/linkX[.Y]/hw_sata_spd_limit
What:		/sys/class/ata_link/linkX[.Y]/sata_spd_limit
What:		/sys/class/ata_link/linkX[.Y]/sata_spd
Date:		May, 2010
KernelVersion:	v2.6.37
Contact:	Gwendal Grignou <gwendal@chromium.org>
Description:
		hw_sata_spd_limit:	(RO) Maximum speed supported by the
					connected SATA device.

		sata_spd_limit:		(RO) Maximum speed imposed by libata.

		sata_spd:		(RO) Current speed of the link
					eg. 1.5, 3 Gbps etc.

Files under /sys/class/ata_device
---------------------------------

Behind each link, up to two ata devices are created.
The name of the directory is devX[.Y].Z where:
- X is ata_port_id of the port where the device is connected,
- Y the port of the PM if any, and
- Z the device id: for PATA, there is usually 2 devices [0,1], only 1 for SATA.

What:		/sys/class/ata_device/devX[.Y].Z/spdn_cnt
What:		/sys/class/ata_device/devX[.Y].Z/gscr
What:		/sys/class/ata_device/devX[.Y].Z/ering
What:		/sys/class/ata_device/devX[.Y].Z/id
What:		/sys/class/ata_device/devX[.Y].Z/pio_mode
What:		/sys/class/ata_device/devX[.Y].Z/xfer_mode
What:		/sys/class/ata_device/devX[.Y].Z/dma_mode
What:		/sys/class/ata_device/devX[.Y].Z/class
Date:		May, 2010
KernelVersion:	v2.6.37
Contact:	Gwendal Grignou <gwendal@chromium.org>
Description:
		spdn_cnt:	(RO) Number of times libata decided to lower the
				speed of link due to errors.

		gscr:		(RO) Cached result of the dump of PM GSCR
				register. Valid registers are:

				0:      SATA_PMP_GSCR_PROD_ID,
				1:	SATA_PMP_GSCR_REV,
				2:      SATA_PMP_GSCR_PORT_INFO,
				32:     SATA_PMP_GSCR_ERROR,
				33:     SATA_PMP_GSCR_ERROR_EN,
				64:     SATA_PMP_GSCR_FEAT,
				96:     SATA_PMP_GSCR_FEAT_EN,
				130:    SATA_PMP_GSCR_SII_GPIO

				Only valid if the device is a PM.

		ering:		(RO) Formatted output of the error ring of the
				device.

		id:		(RO) Cached result of IDENTIFY command, as
				described in ATA8 7.16 and 7.17. Only valid if
				the device is not a PM.

		pio_mode:	(RO) PIO transfer mode used by the device.
				Mostly used by PATA devices.

		xfer_mode:	(RO) Current transfer mode. Mostly used by
				PATA devices.

		dma_mode:	(RO) DMA transfer mode used by the device.
				Mostly used by PATA devices.

		class:		(RO) Device class. Can be "ata" for disk,
				"atapi" for packet device, "pmp" for PM, or
				"none" if no device was found behind the link.

What:		/sys/class/ata_device/devX[.Y].Z/trim
Date:		May, 2015
KernelVersion:	v4.10
Contact:	Gwendal Grignou <gwendal@chromium.org>
Description:
		(RO) Shows the DSM TRIM mode currently used by the device. Valid
		values are:

		unsupported:		Drive does not support DSM TRIM

		unqueued:               Drive supports unqueued DSM TRIM only

		queued:                 Drive supports queued DSM TRIM

		forced_unqueued:	Drive's queued DSM support is known to
					be buggy and only unqueued TRIM commands
					are sent

path: Documentation/ABI/testing/sysfs-ata


code:
What:		/sys/block/etherd*/mac
Date:		Apr, 2005
KernelVersion:	v2.6.12
Contact:	Ed L. Cashin <ed.cashin@acm.org>
Description:
		(RO) The ethernet address of the remote Ata over Ethernet (AoE)
		device.

What:		/sys/block/etherd*/netif
Date:		Apr, 2005
KernelVersion:	v2.6.12
Contact:	Ed L. Cashin <ed.cashin@acm.org>
Description:
		(RO) The names of the network interfaces on the localhost (comma
		separated) through which we are communicating with the remote
		AoE device.

What:		/sys/block/etherd*/state
Date:		Apr, 2005
KernelVersion:	v2.6.12
Contact:	Ed L. Cashin <ed.cashin@acm.org>
Description:
		(RO) Device status. The state attribute is "up" when the device
		is ready for I/O and "down" if detected but unusable. The
		"down,closewait" state shows that the device is still open and
		cannot come up again until it has been closed.  The "up,kickme"
		state means that the driver wants to send more commands to the
		target but found out there were already the max number of
		commands waiting for a response. It will retry again after being
		kicked by the periodic timer handler routine.

What:		/sys/block/etherd*/firmware-version
Date:		Apr, 2005
KernelVersion:	v2.6.12
Contact:	Ed L. Cashin <ed.cashin@acm.org>
Description:
		(RO) Version of the firmware in the target.

What:		/sys/block/etherd*/payload
Date:		Dec, 2012
KernelVersion:	v3.10
Contact:	Ed L. Cashin <ed.cashin@acm.org>
Description:
		(RO) The amount of user data transferred (in bytes) inside each AoE
		command on the network, network headers excluded.


code:
What:		/sys/block/<disk>/bcache/unregister
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		A write to this file causes the backing device or cache to be
		unregistered. If a backing device had dirty data in the cache,
		writeback mode is automatically disabled and all dirty data is
		flushed before the device is unregistered. Caches unregister
		all associated backing devices before unregistering themselves.

What:		/sys/block/<disk>/bcache/clear_stats
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		Writing to this file resets all the statistics for the device.

What:		/sys/block/<disk>/bcache/cache
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a backing device that has cache, a symlink to
		the bcache/ dir of that cache.

What:		/sys/block/<disk>/bcache/cache_hits
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: integer number of full cache hits,
		counted per bio. A partial cache hit counts as a miss.

What:		/sys/block/<disk>/bcache/cache_misses
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: integer number of cache misses.

What:		/sys/block/<disk>/bcache/cache_hit_ratio
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: cache hits as a percentage.

What:		/sys/block/<disk>/bcache/sequential_cutoff
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: Threshold past which sequential IO will
		skip the cache. Read and written as bytes in human readable
		units (i.e. echo 10M > sequntial_cutoff).

What:		/sys/block/<disk>/bcache/bypassed
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		Sum of all reads and writes that have bypassed the cache (due
		to the sequential cutoff).  Expressed as bytes in human
		readable units.

What:		/sys/block/<disk>/bcache/writeback
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: When on, writeback caching is enabled and
		writes will be buffered in the cache. When off, caching is in
		writethrough mode; reads and writes will be added to the
		cache but no write buffering will take place.

What:		/sys/block/<disk>/bcache/writeback_running
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: when off, dirty data will not be written
		from the cache to the backing device. The cache will still be
		used to buffer writes until it is mostly full, at which point
		writes transparently revert to writethrough mode. Intended only
		for benchmarking/testing.

What:		/sys/block/<disk>/bcache/writeback_delay
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: In writeback mode, when dirty data is
		written to the cache and the cache held no dirty data for that
		backing device, writeback from cache to backing device starts
		after this delay, expressed as an integer number of seconds.

What:		/sys/block/<disk>/bcache/writeback_percent
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For backing devices: If nonzero, writeback from cache to
		backing device only takes place when more than this percentage
		of the cache is used, allowing more write coalescing to take
		place and reducing total number of writes sent to the backing
		device. Integer between 0 and 40.

What:		/sys/block/<disk>/bcache/synchronous
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, a boolean that allows synchronous mode to be
		switched on and off. In synchronous mode all writes are ordered
		such that the cache can reliably recover from unclean shutdown;
		if disabled bcache will not generally wait for writes to
		complete but if the cache is not shut down cleanly all data
		will be discarded from the cache. Should not be turned off with
		writeback caching enabled.

What:		/sys/block/<disk>/bcache/discard
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, a boolean allowing discard/TRIM to be turned off
		or back on if the device supports it.

What:		/sys/block/<disk>/bcache/bucket_size
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, bucket size in human readable units, as set at
		cache creation time; should match the erase block size of the
		SSD for optimal performance.

What:		/sys/block/<disk>/bcache/nbuckets
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, the number of usable buckets.

What:		/sys/block/<disk>/bcache/tree_depth
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, height of the btree excluding leaf nodes (i.e. a
		one node tree will have a depth of 0).

What:		/sys/block/<disk>/bcache/btree_cache_size
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		Number of btree buckets/nodes that are currently cached in
		memory; cache dynamically grows and shrinks in response to
		memory pressure from the rest of the system.

What:		/sys/block/<disk>/bcache/written
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, total amount of data in human readable units
		written to the cache, excluding all metadata.

What:		/sys/block/<disk>/bcache/btree_written
Date:		November 2010
Contact:	Kent Overstreet <kent.overstreet@gmail.com>
Description:
		For a cache, sum of all btree writes in human readable units.


code:
What:		/sys/block/*/device/sw_activity
Date:		Jun, 2008
KernelVersion:	v2.6.27
Contact:	linux-ide@vger.kernel.org
Description:
		(RW) Used by drivers which support software controlled activity
		LEDs.

		It has the following valid values:

		==	========================================================
		0	OFF - the LED is not activated on activity
		1	BLINK_ON - the LED blinks on every 10ms when activity is
			detected.
		2	BLINK_OFF - the LED is on when idle, and blinks off
			every 10ms when activity is detected.
		==	========================================================

		Note that the user must turn sw_activity OFF it they wish to
		control the activity LED via the em_message file.

What:		/sys/block/*/device/unload_heads
Date:		Sep, 2008
KernelVersion:	v2.6.28
Contact:	linux-ide@vger.kernel.org
Description:
		(RW) Hard disk shock protection

		Writing an integer value to this file will take the heads of the
		respective drive off the platter and block all I/O operations
		for the specified number of milliseconds.

		- If the device does not support the unload heads feature,
		  access is denied with -EOPNOTSUPP.
		- The maximal value accepted for a timeout is 30000
		  milliseconds.
		- A previously set timeout can be cancelled and disk can resume
		  normal operation immediately by specifying a timeout of 0.
		- Some hard drives only comply with an earlier version of the
		  ATA standard, but support the unload feature nonetheless.
		  There is no safe way Linux can detect these devices, so this
		  is not enabled by default. If it is known that your device
		  does support the unload feature, then you can tell the kernel
		  to enable it by writing -1. It can be disabled again by
		  writing -2.
		- Values below -2 are rejected with -EINVAL

		For more information, see
		Documentation/admin-guide/laptops/disk-shock-protection.rst

What:		/sys/block/*/device/ncq_prio_enable
Date:		Oct, 2016
KernelVersion:	v4.10
Contact:	linux-ide@vger.kernel.org
Description:
		(RW) Write to the file to turn on or off the SATA NCQ (native
		command queueing) priority support. By default this feature is
		turned off. If the device does not support the SATA NCQ
		priority feature, writing "1" to this file results in an error
		(see ncq_prio_supported).

What:		/sys/block/*/device/sas_ncq_prio_enable
Date:		Oct, 2016
KernelVersion:	v4.10
Contact:	linux-ide@vger.kernel.org
Description:
		(RW) This is the equivalent of the ncq_prio_enable attribute
		file for SATA devices connected to a SAS host-bus-adapter
		(HBA) implementing support for the SATA NCQ priority feature.
		This file does not exist if the HBA driver does not implement
		support for the SATA NCQ priority feature, regardless of the
		device support for this feature (see sas_ncq_prio_supported).

What:		/sys/block/*/device/ncq_prio_supported
Date:		Aug, 2021
KernelVersion:	v5.15
Contact:	linux-ide@vger.kernel.org
Description:
		(RO) Indicates if the device supports the SATA NCQ (native
		command queueing) priority feature.

What:		/sys/block/*/device/sas_ncq_prio_supported
Date:		Aug, 2021
KernelVersion:	v5.15
Contact:	linux-ide@vger.kernel.org
Description:
		(RO) This is the equivalent of the ncq_prio_supported attribute
		file for SATA devices connected to a SAS host-bus-adapter
		(HBA) implementing support for the SATA NCQ priority feature.
		This file does not exist if the HBA driver does not implement
		support for the SATA NCQ priority feature, regardless of the
		device support for this feature.


code:
What:		/sys/block/dm-<num>/dm/name
Date:		January 2009
KernelVersion:	2.6.29
Contact:	dm-devel@redhat.com
Description:	Device-mapper device name.
		Read-only string containing mapped device name.
Users:		util-linux, device-mapper udev rules

What:		/sys/block/dm-<num>/dm/uuid
Date:		January 2009
KernelVersion:	2.6.29
Contact:	dm-devel@redhat.com
Description:	Device-mapper device UUID.
		Read-only string containing DM-UUID or empty string
		if DM-UUID is not set.
Users:		util-linux, device-mapper udev rules

What:		/sys/block/dm-<num>/dm/suspended
Date:		June 2009
KernelVersion:	2.6.31
Contact:	dm-devel@redhat.com
Description:	Device-mapper device suspend state.
		Contains the value 1 while the device is suspended.
		Otherwise it contains 0. Read-only attribute.
Users:		util-linux, device-mapper udev rules

What:		/sys/block/dm-<num>/dm/rq_based_seq_io_merge_deadline
Date:		March 2015
KernelVersion:	4.1
Contact:	dm-devel@redhat.com
Description:	Allow control over how long a request that is a
		reasonable merge candidate can be queued on the request
		queue.  The resolution of this deadline is in
		microseconds (ranging from 1 to 100000 usecs).
		Setting this attribute to 0 (the default) will disable
		request-based DM's merge heuristic and associated extra
		accounting.  This attribute is not applicable to
		bio-based DM devices so it will only ever report 0 for
		them.

What:		/sys/block/dm-<num>/dm/use_blk_mq
Date:		March 2015
KernelVersion:	4.1
Contact:	dm-devel@redhat.com
Description:	Request-based Device-mapper blk-mq I/O path mode.
		Contains the value 1 if the device is using blk-mq.
		Otherwise it contains 0. Read-only attribute.


code:
What:		/sys/block/loopX/loop/autoclear
Date:		Aug, 2010
KernelVersion:	v2.6.37
Contact:	linux-block@vger.kernel.org
Description:
		(RO) Shows if the device is in autoclear mode or not ( "1" or
		"0"). Autoclear (if set) indicates that the loopback device will
		self-distruct after last close.

What:		/sys/block/loopX/loop/backing_file
Date:		Aug, 2010
KernelVersion:	v2.6.37
Contact:	linux-block@vger.kernel.org
Description:
		(RO) The path of the backing file that the loop device maps its
		data blocks to.

What:		/sys/block/loopX/loop/offset
Date:		Aug, 2010
KernelVersion:	v2.6.37
Contact:	linux-block@vger.kernel.org
Description:
		(RO) Start offset (in bytes).

What:		/sys/block/loopX/loop/sizelimit
Date:		Aug, 2010
KernelVersion:	v2.6.37
Contact:	linux-block@vger.kernel.org
Description:
		(RO) The size (in bytes) that the block device maps, starting
		from the offset.

What:		/sys/block/loopX/loop/partscan
Date:		Aug, 2011
KernelVersion:	v3.10
Contact:	linux-block@vger.kernel.org
Description:
		(RO) Shows if automatic partition scanning is enabled for the
		device or not ("1" or "0"). This can be requested individually
		per loop device during its setup by setting LO_FLAGS_PARTSCAN in
		in the ioctl request. By default, no partition tables are
		scanned.

What:		/sys/block/loopX/loop/dio
Date:		Aug, 2015
KernelVersion:	v4.10
Contact:	linux-block@vger.kernel.org
Description:
		(RO) Shows if direct IO is being used to access backing file or
		not ("1 or "0").


code:
What:		/sys/block/rnbd<N>/rnbd/unmap_device
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	To unmap a volume, "normal" or "force" has to be written to:
		/sys/block/rnbd<N>/rnbd/unmap_device

		When "normal" is used, the operation will fail with EBUSY if any process
		is using the device.  When "force" is used, the device is also unmapped
		when device is in use.  All I/Os that are in progress will fail.

		Example::

		  # echo "normal" > /sys/block/rnbd0/rnbd/unmap_device

What:		/sys/block/rnbd<N>/rnbd/state
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	The file contains the current state of the block device. The state file
		returns "open" when the device is successfully mapped from the server
		and accepting I/O requests. When the connection to the server gets
		disconnected in case of an error (e.g. link failure), the state file
		returns "closed" and all I/O requests submitted to it will fail with -EIO.

What:		/sys/block/rnbd<N>/rnbd/session
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	RNBD uses RTRS session to transport the data between client and
		server.  The entry "session" contains the name of the session, that
		was used to establish the RTRS session.  It's the same name that
		was passed as server parameter to the map_device entry.

What:		/sys/block/rnbd<N>/rnbd/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 path that was passed as "device_path" to the map_device
		operation.

What:		/sys/block/rnbd<N>/rnbd/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/block/rnbd<N>/rnbd/resize
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Write the number of sectors to change the size of the disk.

What:		/sys/block/rnbd<N>/rnbd/remap_device
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Remap the disconnected device if the session is not destroyed yet.

What:		/sys/block/rnbd<N>/rnbd/nr_poll_queues
Date:		Feb 2020
KernelVersion:	5.7
Contact:	Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description:	Contains the number of poll-mode queues


code:
What:           /sys/block/rssd*/status
Date:           April 2012
KernelVersion:  3.4
Contact:        Asai Thambi S P <asamymuthupa@micron.com>
Description:    This is a read-only file. Indicates the status of the device.


code:
What:		/sys/block/zram<id>/disksize
Date:		August 2010
Contact:	Nitin Gupta <ngupta@vflare.org>
Description:
		The disksize file is read-write and specifies the disk size
		which represents the limit on the *uncompressed* worth of data
		that can be stored in this disk.
		Unit: bytes

What:		/sys/block/zram<id>/initstate
Date:		August 2010
Contact:	Nitin Gupta <ngupta@vflare.org>
Description:
		The initstate file is read-only and shows the initialization
		state of the device.

What:		/sys/block/zram<id>/reset
Date:		August 2010
Contact:	Nitin Gupta <ngupta@vflare.org>
Description:
		The reset file is write-only and allows resetting the
		device. The reset operation frees all the memory associated
		with this device.

What:		/sys/block/zram<id>/max_comp_streams
Date:		February 2014
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		The max_comp_streams file is read-write and specifies the
		number of backend's zcomp_strm compression streams (number of
		concurrent compress operations).

What:		/sys/block/zram<id>/comp_algorithm
Date:		February 2014
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		The comp_algorithm file is read-write and lets to show
		available and selected compression algorithms, change
		compression algorithm selection.

What:		/sys/block/zram<id>/mem_used_max
Date:		August 2014
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The mem_used_max file is write-only and is used to reset
		the counter of maximum memory zram have consumed to store
		compressed data. For resetting the value, you should write
		"0". Otherwise, you could see -EINVAL.
		Unit: bytes

What:		/sys/block/zram<id>/mem_limit
Date:		August 2014
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The mem_limit file is write-only and specifies the maximum
		amount of memory ZRAM can use to store the compressed data.
		The limit could be changed in run time and "0" means disable
		the limit. No limit is the initial state.  Unit: bytes

What:		/sys/block/zram<id>/compact
Date:		August 2015
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The compact file is write-only and trigger compaction for
		allocator zrm uses. The allocator moves some objects so that
		it could free fragment space.

What:		/sys/block/zram<id>/io_stat
Date:		August 2015
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		The io_stat file is read-only and accumulates device's I/O
		statistics not accounted by block layer. For example,
		failed_reads, failed_writes, etc. File format is similar to
		block layer statistics file format.

What:		/sys/block/zram<id>/mm_stat
Date:		August 2015
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		The mm_stat file is read-only and represents device's mm
		statistics (orig_data_size, compr_data_size, etc.) in a format
		similar to block layer statistics file format.

What:		/sys/block/zram<id>/debug_stat
Date:		July 2016
Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
		The debug_stat file is read-only and represents various
		device's debugging info useful for kernel developers. Its
		format is not documented intentionally and may change
		anytime without any notice.

What:		/sys/block/zram<id>/backing_dev
Date:		June 2017
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The backing_dev file is read-write and set up backing
		device for zram to write incompressible pages.
		For using, user should enable CONFIG_ZRAM_WRITEBACK.

What:		/sys/block/zram<id>/idle
Date:		November 2018
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		idle file is write-only and mark zram slot as idle.
		If system has mounted debugfs, user can see which slots
		are idle via /sys/kernel/debug/zram/zram<id>/block_state

What:		/sys/block/zram<id>/writeback
Date:		November 2018
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The writeback file is write-only and trigger idle and/or
		huge page writeback to backing device.

What:		/sys/block/zram<id>/bd_stat
Date:		November 2018
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The bd_stat file is read-only and represents backing device's
		statistics (bd_count, bd_reads, bd_writes) in a format
		similar to block layer statistics file format.

What:		/sys/block/zram<id>/writeback_limit_enable
Date:		November 2018
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The writeback_limit_enable file is read-write and specifies
		eanbe of writeback_limit feature. "1" means eable the feature.
		No limit "0" is the initial state.

What:		/sys/block/zram<id>/writeback_limit
Date:		November 2018
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		The writeback_limit file is read-write and specifies the maximum
		amount of writeback ZRAM can do. The limit could be changed
		in run time.

What:		/sys/block/zram<id>/recomp_algorithm
Date:		November 2022
Contact:	Sergey Senozhatsky <senozhatsky@chromium.org>
Description:
		The recomp_algorithm file is read-write and allows to set
		or show secondary compression algorithms.

What:		/sys/block/zram<id>/recompress
Date:		November 2022
Contact:	Sergey Senozhatsky <senozhatsky@chromium.org>
Description:
		The recompress file is write-only and triggers re-compression
		with secondary compression algorithms.


code:
What:		/sys/bus/acpi/devices/.../path
Date:		December 2006
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		This attribute indicates the full path of ACPI namespace
		object associated with the device object.  For example,
		\_SB_.PCI0.

		This file is not present for device objects representing
		fixed ACPI hardware features (like power and sleep
		buttons).

What:		/sys/bus/acpi/devices/.../modalias
Date:		July 2007
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		This attribute indicates the PNP IDs of the device object.
		That is acpi:HHHHHHHH:[CCCCCCC:].  Where each HHHHHHHH or
		CCCCCCCC contains device object's PNPID (_HID or _CID).

What:		/sys/bus/acpi/devices/.../hid
Date:		April 2005
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		This attribute indicates the hardware ID (_HID) of the
		device object.  For example, PNP0103.
		This file is present for device objects having the _HID
		control method.

What:		/sys/bus/acpi/devices/.../description
Date:		October 2012
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		This attribute contains the output of the device object's
		_STR control method, if present.

What:		/sys/bus/acpi/devices/.../adr
Date:		October 2012
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		This attribute contains the output of the device object's
		_ADR control method, which is present for ACPI device
		objects representing devices having standard enumeration
		algorithms, such as PCI.

What:		/sys/bus/acpi/devices/.../uid
Date:		October 2012
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		This attribute contains the output of the device object's
		_UID control method, if present.

What:		/sys/bus/acpi/devices/.../eject
Date:		December 2006
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		Writing 1 to this attribute will trigger hot removal of
		this device object.  This file exists for every device
		object that has _EJ0 method.

What:		/sys/bus/acpi/devices/.../status
Date:		Jan, 2014
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		(RO) Returns the ACPI device status: enabled, disabled or
		functioning or present, if the method _STA is present.

		The return value is a decimal integer representing the device's
		status bitmap:

		===========  ==================================================
		Bit [0]      Set if the device is present.
		Bit [1]      Set if the device is enabled and decoding its
		             resources.
		Bit [2]      Set if the device should be shown in the UI.
		Bit [3]      Set if the device is functioning properly (cleared
			     if device failed its diagnostics).
		Bit [4]      Set if the battery is present.
		Bits [31:5]  Reserved (must be cleared)
		===========  ==================================================

		If bit [0] is clear, then bit 1 must also be clear (a device
		that is not present cannot be enabled).

		Bit 0 can be clear (not present) with bit [3] set (device is
		functional).  This case is used to indicate a valid device for
		which no device driver should be loaded.

		More special cases are covered in the ACPI specification.

What:		/sys/bus/acpi/devices/.../hrv
Date:		Apr, 2016
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		(RO) Allows users to read the hardware version of non-PCI
		hardware, if the _HRV control method is present.  It is mostly
		useful for non-PCI devices because lspci can list the hardware
		version for PCI devices.


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


code:
What:		/sys/bus/bcma/devices/.../manuf
Date:		May 2011
KernelVersion:	3.0
Contact:	Rafał Miłecki <zajec5@gmail.com>
Description:
		Each BCMA core has its manufacturer id. See
		include/linux/bcma/bcma.h for possible values.

What:		/sys/bus/bcma/devices/.../id
Date:		May 2011
KernelVersion:	3.0
Contact:	Rafał Miłecki <zajec5@gmail.com>
Description:
		There are a few types of BCMA cores, they can be identified by
		id field.

What:		/sys/bus/bcma/devices/.../rev
Date:		May 2011
KernelVersion:	3.0
Contact:	Rafał Miłecki <zajec5@gmail.com>
Description:
		BCMA cores of the same type can still slightly differ depending
		on their revision. Use it for detailed programming.

What:		/sys/bus/bcma/devices/.../class
Date:		May 2011
KernelVersion:	3.0
Contact:	Rafał Miłecki <zajec5@gmail.com>
Description:
		Each BCMA core is identified by few fields, including class it
		belongs to. See include/linux/bcma/bcma.h for possible values.


code:
What:		/sys/bus/coreboot
Date:		August 2022
Contact:	Jack Rosenthal <jrosenth@chromium.org>
Description:
		The coreboot bus provides a variety of virtual devices used to
		access data structures created by the Coreboot BIOS.

What:		/sys/bus/coreboot/devices/cbmem-<id>
Date:		August 2022
Contact:	Jack Rosenthal <jrosenth@chromium.org>
Description:
		CBMEM is a downwards-growing memory region created by Coreboot,
		and contains tagged data structures to be shared with payloads
		in the boot process and the OS.  Each CBMEM entry is given a
		directory in /sys/bus/coreboot/devices based on its id.
		A list of ids known to Coreboot can be found in the coreboot
		source tree at
		``src/commonlib/bsd/include/commonlib/bsd/cbmem_id.h``.

What:		/sys/bus/coreboot/devices/cbmem-<id>/address
Date:		August 2022
Contact:	Jack Rosenthal <jrosenth@chromium.org>
Description:
		This is the pyhsical memory address that the CBMEM entry's data
		begins at, in hexadecimal (e.g., ``0x76ffe000``).

What:		/sys/bus/coreboot/devices/cbmem-<id>/size
Date:		August 2022
Contact:	Jack Rosenthal <jrosenth@chromium.org>
Description:
		This is the size of the CBMEM entry's data, in hexadecimal
		(e.g., ``0x1234``).

What:		/sys/bus/coreboot/devices/cbmem-<id>/mem
Date:		August 2022
Contact:	Jack Rosenthal <jrosenth@chromium.org>
Description:
		A file exposing read/write access to the entry's data.  Note
		that this file does not support mmap(), as coreboot
		does not guarantee that the data will be page-aligned.

		The mode of this file is 0600.  While there shouldn't be
		anything security-sensitive contained in CBMEM, read access
		requires root privileges given this is exposing a small subset
		of physical memory.


code:
What:		/sys/bus/coresight/devices/<cti-name>/enable
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Enable/Disable the CTI hardware.

What:		/sys/bus/coresight/devices/<cti-name>/powered
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Indicate if the CTI hardware is powered.

What:		/sys/bus/coresight/devices/<cti-name>/ctmid
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Display the associated CTM ID

What:		/sys/bus/coresight/devices/<cti-name>/nr_trigger_cons
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Number of devices connected to triggers on this CTI

What:		/sys/bus/coresight/devices/<cti-name>/triggers<N>/name
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Name of connected device <N>

What:		/sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Input trigger signals from connected device <N>

What:		/sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Functional types for the input trigger signals
		from connected device <N>

What:		/sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Output trigger signals to connected device <N>

What:		/sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Functional types for the output trigger signals
		to connected device <N>

What:		/sys/bus/coresight/devices/<cti-name>/regs/inout_sel
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Select the index for inen and outen registers.

What:		/sys/bus/coresight/devices/<cti-name>/regs/inen
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Read or write the CTIINEN register selected by inout_sel.

What:		/sys/bus/coresight/devices/<cti-name>/regs/outen
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Read or write the CTIOUTEN register selected by inout_sel.

What:		/sys/bus/coresight/devices/<cti-name>/regs/gate
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Read or write CTIGATE register.

What:		/sys/bus/coresight/devices/<cti-name>/regs/asicctl
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Read or write ASICCTL register.

What:		/sys/bus/coresight/devices/<cti-name>/regs/intack
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Write the INTACK register.

What:		/sys/bus/coresight/devices/<cti-name>/regs/appset
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Set CTIAPPSET register to activate channel. Read back to
		determine current value of register.

What:		/sys/bus/coresight/devices/<cti-name>/regs/appclear
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Write APPCLEAR register to deactivate channel.

What:		/sys/bus/coresight/devices/<cti-name>/regs/apppulse
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Write APPPULSE to pulse a channel active for one clock
		cycle.

What:		/sys/bus/coresight/devices/<cti-name>/regs/chinstatus
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Read current status of channel inputs.

What:		/sys/bus/coresight/devices/<cti-name>/regs/choutstatus
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) read current status of channel outputs.

What:		/sys/bus/coresight/devices/<cti-name>/regs/triginstatus
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) read current status of input trigger signals

What:		/sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) read current status of output trigger signals.

What:		/sys/bus/coresight/devices/<cti-name>/channels/trigin_attach
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Attach a CTI input trigger to a CTM channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/trigin_detach
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Detach a CTI input trigger from a CTM channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/trigout_attach
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Attach a CTI output trigger to a CTM channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/trigout_detach
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Detach a CTI output trigger from a CTM channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Enable CTIGATE for single channel (Write) or list enabled
		channels through the gate (R).

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Disable CTIGATE for single channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_set
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Activate a single channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_clear
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Deactivate a single channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_pulse
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Pulse a single channel - activate for a single clock cycle.

What:		/sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) List of output triggers filtered across all connections.

What:		/sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Enable or disable trigger output signal filtering.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_inuse
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) show channels with at least one attached trigger signal.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_free
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) show channels with no attached trigger signals.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(RW) Write channel number to select a channel to view, read to
		see selected channel number.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Read to see input triggers connected to selected view
		channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Read) Read to see output triggers connected to selected view
		channel.

What:		/sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset
Date:		March 2020
KernelVersion	5.7
Contact:	Mike Leach or Mathieu Poirier
Description:	(Write) Clear all channel / trigger programming.


code:
What:		/sys/bus/coresight/devices/<memory_map>.etb/enable_sink
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Add/remove a sink from a trace path.  There can be multiple
		source for a single sink.

		ex::

		  echo 1 > /sys/bus/coresight/devices/20010000.etb/enable_sink

What:		/sys/bus/coresight/devices/<memory_map>.etb/trigger_cntr
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Disables write access to the Trace RAM by stopping the
		formatter after a defined number of words have been stored
		following the trigger event. The number of 32-bit words written
		into the Trace RAM following the trigger event is equal to the
		value stored in this register+1 (from ARM ETB-TRM).

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/rdp
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Defines the depth, in words, of the trace RAM in powers of
		2.  The value is read directly from HW register RDP, 0x004.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/sts
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Shows the value held by the ETB status register.  The value
		is read directly from HW register STS, 0x00C.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/rrp
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Shows the value held by the ETB RAM Read Pointer register
		that is used to read entries from the Trace RAM over the APB
		interface.  The value is read directly from HW register RRP,
		0x014.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/rwp
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Shows the value held by the ETB RAM Write Pointer register
		that is used to sets the write pointer to write entries from
		the CoreSight bus into the Trace RAM. The value is read directly
		from HW register RWP, 0x018.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/trg
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Similar to "trigger_cntr" above except that this value is
		read directly from HW register TRG, 0x01C.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/ctl
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Shows the value held by the ETB Control register. The value
		is read directly from HW register CTL, 0x020.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/ffsr
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Shows the value held by the ETB Formatter and Flush Status
		register.  The value is read directly from HW register FFSR,
		0x300.

What:		/sys/bus/coresight/devices/<memory_map>.etb/mgmt/ffcr
Date:		March 2016
KernelVersion:	4.7
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(Read) Shows the value held by the ETB Formatter and Flush Control
		register.  The value is read directly from HW register FFCR,
		0x304.


code:
What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_source
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Enable/disable tracing on this specific trace entiry.
		Enabling a source implies the source has been configured
		properly and a sink has been identidifed for it.  The path
		of coresight components linking the source to the sink is
		configured and managed automatically by the coresight framework.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_idx
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	Select which address comparator or pair (of comparators) to
		work with.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_acctype
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Used in conjunction with @addr_idx.  Specifies
		characteristics about the address comparator being configure,
		for example the access type, the kind of instruction to trace,
		processor contect ID to trigger on, etc.  Individual fields in
		the access type register may vary on the version of the trace
		entity.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_range
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Used in conjunction with @addr_idx.  Specifies the range of
		addresses to trigger on.  Inclusion or exclusion is specificed
		in the corresponding access type register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Used in conjunction with @addr_idx.  Specifies the single
		address to trigger on, highly influenced by the configuration
		options of the corresponding access type register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_start
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Used in conjunction with @addr_idx.  Specifies the single
		address to start tracing on, highly influenced by the
		configuration options of the corresponding access type register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_stop
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Used in conjunction with @addr_idx.  Specifies the single
		address to stop tracing on, highly influenced by the
		configuration options of the corresponding access type register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_idx
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RW) Specifies the counter to work on.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Used in conjunction with cntr_idx, give access to the
		counter event register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_val
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Used in conjunction with cntr_idx, give access to the
		counter value register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_val
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Used in conjunction with cntr_idx, give access to the
		counter reload value register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Used in conjunction with cntr_idx, give access to the
		counter reload event register.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_idx
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Specifies the index of the context ID register to be
		selected.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_mask
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Mask to apply to all the context ID comparator.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_pid
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Used with the ctxid_idx, specify with context ID to trigger
		on.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines which event triggers a trace.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/etmsr
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Gives access to the ETM status register, which holds
		programming information and status on certains events.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/fifofull_level
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Number of byte left in the fifo before considering it full.
		Depending on the tracer's version, can also hold threshold for
		data suppression.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mode
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Interface with the driver's 'mode' field, controlling
		various aspect of the trace entity such as time stamping,
		context ID size and cycle accurate tracing.  Driver specific
		and bound to change depending on the driver.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_addr_cmp
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(Read) Provides the number of address comparators pairs accessible
		on a trace unit, as specified by bit 3:0 of register ETMCCR.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_cntr
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(Read) Provides the number of counters accessible on a trace unit,
		as specified by bit 15:13 of register ETMCCR.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_ctxid_cmp
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(Read) Provides the number of context ID comparator available on a
		trace unit, as specified by bit 25:24 of register ETMCCR.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/reset
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(Write) Cancels all configuration on a trace unit and set it back
		to its boot configuration.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_12_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines the event that causes the sequencer to transition
		from state 1 to state 2.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_13_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines the event that causes the sequencer to transition
		from state 1 to state 3.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_21_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines the event that causes the sequencer to transition
		from state 2 to state 1.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_23_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines the event that causes the sequencer to transition
		from state 2 to state 3.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_31_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines the event that causes the sequencer to transition
		from state 3 to state 1.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_32_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines the event that causes the sequencer to transition
		from state 3 to state 2.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/curr_seq_state
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(Read) Holds the current state of the sequencer.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/sync_freq
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Holds the trace synchronization frequency value - must be
		programmed with the various implementation behavior in mind.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/timestamp_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Defines an event that requests the insertion of a timestamp
		into the trace stream.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/traceid
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Holds the trace ID that will appear in the trace stream
		coming from this trace entity.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/trigger_event
Date:		November 2014
KernelVersion:	3.19
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RW) Define the event that controls the trigger.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cpu
Date:		October 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description:	(RO) Holds the cpu number this tracer is affined to.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Configuration Code register
		(0x004).  The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccer
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Configuration Code Extension
		register (0x1e8).  The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmscr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM System Configuration
		register (0x014).  The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmidr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM ID register (0x1e4).  The
		value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmcr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Main Control register (0x000).
		The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtraceidr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Trace ID register (0x200).
		The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmteevr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Trace Enable Event register
		(0x020). The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtsscr
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Trace Start/Stop Conrol
		register (0x018). The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Enable Conrol #1
		register (0x024). The value is read directly from the HW.

What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2
Date:		September 2015
KernelVersion:	4.4
Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
Description: 	(RO) Print the content of the ETM Enable Conrol #2
		register (0x01c). The value is read directly from the HW.