AetherDroid/android_kernel_samsung_on5xelte
1
0
Fork 0
mirror of https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git synced 2025-10-29 15:28:50 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed MTP to work with TWRP

Browse source
This commit is contained in:
awab228 2018-06-19 23:16:04 +02:00
commit f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

31
Documentation/ABI/testing/configfs-spear-pcie-gadget Normal file
View file

@ -0,0 +1,31 @@
What: /config/pcie-gadget
Date: Feb 2011
KernelVersion: 2.6.37
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Interface is used to configure selected dual mode PCIe controller
as device and then program its various registers to configure it
as a particular device type.
This interfaces can be used to show spear's PCIe device capability.
Nodes are only visible when configfs is mounted. To mount configfs
in /config directory use:
# mount -t configfs none /config/
For nth PCIe Device Controller
/config/pcie-gadget.n/
link ... used to enable ltssm and read its status.
int_type ...used to configure and read type of supported
interrupt
no_of_msi ... used to configure number of MSI vector needed and
to read no of MSI granted.
inta ... write 1 to assert INTA and 0 to de-assert.
send_msi ... write MSI vector to be sent.
vendor_id ... used to write and read vendor id (hex)
device_id ... used to write and read device id (hex)
bar0_size ... used to write and read bar0_size
bar0_address ... used to write and read bar0 mapped area in hex.
bar0_rw_offset ... used to write and read offset of bar0 where
bar0_data will be written or read.
bar0_data ... used to write and read data at bar0_rw_offset.

126
Documentation/ABI/testing/configfs-usb-gadget Normal file
View file

@ -0,0 +1,126 @@
What: /config/usb-gadget
Date: Jun 2013
KernelVersion: 3.11
Description:
This group contains sub-groups corresponding to created
USB gadgets.
What: /config/usb-gadget/gadget
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes of a gadget:
UDC - bind a gadget to UDC/unbind a gadget;
write UDC's name found in /sys/class/udc/*
to bind a gadget, empty string "" to unbind.
bDeviceClass - USB device class code
bDeviceSubClass - USB device subclass code
bDeviceProtocol - USB device protocol code
bMaxPacketSize0 - maximum endpoint 0 packet size
bcdDevice - bcd device release number
bcdUSB - bcd USB specification version number
idProduct - product ID
idVendor - vendor ID
What: /config/usb-gadget/gadget/configs
Date: Jun 2013
KernelVersion: 3.11
Description:
This group contains a USB gadget's configurations
What: /config/usb-gadget/gadget/configs/config
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes of a configuration:
bmAttributes - configuration characteristics
MaxPower - maximum power consumption from the bus
What: /config/usb-gadget/gadget/configs/config/strings
Date: Jun 2013
KernelVersion: 3.11
Description:
This group contains subdirectories for language-specific
strings for this configuration.
What: /config/usb-gadget/gadget/configs/config/strings/language
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
configuration - configuration description
What: /config/usb-gadget/gadget/functions
Date: Jun 2013
KernelVersion: 3.11
Description:
This group contains functions available to this USB gadget.
What: /config/usb-gadget/gadget/functions/<func>.<inst>/interface.<n>
Date: May 2014
KernelVersion: 3.16
Description:
This group contains "Feature Descriptors" specific for one
gadget's USB interface or one interface group described
by an IAD.
The attributes:
compatible_id - 8-byte string for "Compatible ID"
sub_compatible_id - 8-byte string for "Sub Compatible ID"
What: /config/usb-gadget/gadget/functions/<func>.<inst>/interface.<n>/<property>
Date: May 2014
KernelVersion: 3.16
Description:
This group contains "Extended Property Descriptors" specific for one
gadget's USB interface or one interface group described
by an IAD.
The attributes:
type - value 1..7 for interpreting the data
1: unicode string
2: unicode string with environment variable
3: binary
4: little-endian 32-bit
5: big-endian 32-bit
6: unicode string with a symbolic link
7: multiple unicode strings
data - blob of data to be interpreted depending on
type
What: /config/usb-gadget/gadget/strings
Date: Jun 2013
KernelVersion: 3.11
Description:
This group contains subdirectories for language-specific
strings for this gadget.
What: /config/usb-gadget/gadget/strings/language
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
serialnumber - gadget's serial number (string)
product - gadget's product description
manufacturer - gadget's manufacturer description
What: /config/usb-gadget/gadget/os_desc
Date: May 2014
KernelVersion: 3.16
Description:
This group contains "OS String" extension handling attributes.
use - flag turning "OS Desctiptors" support on/off
b_vendor_code - one-byte value used for custom per-device and
per-interface requests
qw_sign - an identifier to be reported as "OS String"
proper

8
Documentation/ABI/testing/configfs-usb-gadget-acm Normal file
View file

@ -0,0 +1,8 @@
What: /config/usb-gadget/gadget/functions/acm.name
Date: Jun 2013
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: port_num.
It contains the port number of the /dev/ttyGS<n> device
associated with acm function's instance "name".

16
Documentation/ABI/testing/configfs-usb-gadget-ecm Normal file
View file

@ -0,0 +1,16 @@
What: /config/usb-gadget/gadget/functions/ecm.name
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
ifname - network device interface name associated with
this function instance
qmult - queue length multiplier for high and
super speed
host_addr - MAC address of host's end of this
Ethernet over USB link
dev_addr - MAC address of device's end of this
Ethernet over USB link

14
Documentation/ABI/testing/configfs-usb-gadget-eem Normal file
View file

@ -0,0 +1,14 @@
What: /config/usb-gadget/gadget/functions/eem.name
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
ifname - network device interface name associated with
this function instance
qmult - queue length multiplier for high and
super speed
host_addr - MAC address of host's end of this
Ethernet over USB link
dev_addr - MAC address of device's end of this
Ethernet over USB link

9
Documentation/ABI/testing/configfs-usb-gadget-ffs Normal file
View file

@ -0,0 +1,9 @@
What: /config/usb-gadget/gadget/functions/ffs.name
Date: Nov 2013
KernelVersion: 3.13
Description: The purpose of this directory is to create and remove it.
A corresponding USB function instance is created/removed.
There are no attributes here.
All parameters are set through FunctionFS.

8
Documentation/ABI/testing/configfs-usb-gadget-loopback Normal file
View file

@ -0,0 +1,8 @@
What: /config/usb-gadget/gadget/functions/Loopback.name
Date: Nov 2013
KernelVersion: 3.13
Description:
The attributes:
qlen - depth of loopback queue
bulk_buflen - buffer length

31
Documentation/ABI/testing/configfs-usb-gadget-mass-storage Normal file
View file

@ -0,0 +1,31 @@
What: /config/usb-gadget/gadget/functions/mass_storage.name
Date: Oct 2013
KernelVersion: 3.13
Description:
The attributes:
stall - Set to permit function to halt bulk endpoints.
Disabled on some USB devices known not to work
correctly. You should set it to true.
num_buffers - Number of pipeline buffers. Valid numbers
are 2..4. Available only if
CONFIG_USB_GADGET_DEBUG_FILES is set.
What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
Date: Oct 2013
KernelVersion: 3.13
Description:
The attributes:
file - The path to the backing file for the LUN.
Required if LUN is not marked as removable.
ro - Flag specifying access to the LUN shall be
read-only. This is implied if CD-ROM emulation
is enabled as well as when it was impossible
to open "filename" in R/W mode.
removable - Flag specifying that LUN shall be indicated as
being removable.
cdrom - Flag specifying that LUN shall be reported as
being a CD-ROM.
nofua - Flag specifying that FUA flag
in SCSI WRITE(10,12)

15
Documentation/ABI/testing/configfs-usb-gadget-ncm Normal file
View file

@ -0,0 +1,15 @@
What: /config/usb-gadget/gadget/functions/ncm.name
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
ifname - network device interface name associated with
this function instance
qmult - queue length multiplier for high and
super speed
host_addr - MAC address of host's end of this
Ethernet over USB link
dev_addr - MAC address of device's end of this
Ethernet over USB link

9
Documentation/ABI/testing/configfs-usb-gadget-obex Normal file
View file

@ -0,0 +1,9 @@
What: /config/usb-gadget/gadget/functions/obex.name
Date: Jun 2013
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: port_num.
It contains the port number of the /dev/ttyGS<n> device
associated with obex function's instance "name".

8
Documentation/ABI/testing/configfs-usb-gadget-phonet Normal file
View file

@ -0,0 +1,8 @@
What: /config/usb-gadget/gadget/functions/phonet.name
Date: Jun 2013
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: ifname.
It contains the network interface name assigned during
network device registration.

14
Documentation/ABI/testing/configfs-usb-gadget-rndis Normal file
View file

@ -0,0 +1,14 @@
What: /config/usb-gadget/gadget/functions/rndis.name
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
ifname - network device interface name associated with
this function instance
qmult - queue length multiplier for high and
super speed
host_addr - MAC address of host's end of this
Ethernet over USB link
dev_addr - MAC address of device's end of this
Ethernet over USB link

9
Documentation/ABI/testing/configfs-usb-gadget-serial Normal file
View file

@ -0,0 +1,9 @@
What: /config/usb-gadget/gadget/functions/gser.name
Date: Jun 2013
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: port_num.
It contains the port number of the /dev/ttyGS<n> device
associated with gser function's instance "name".

12
Documentation/ABI/testing/configfs-usb-gadget-sourcesink Normal file
View file

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/SourceSink.name
Date: Nov 2013
KernelVersion: 3.13
Description:
The attributes:
pattern - 0 (all zeros), 1 (mod63), 2 (none)
isoc_interval - 1..16
isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss)
isoc_mult - 0..2 (hs/ss only)
isoc_maxburst - 0..15 (ss only)
qlen - buffer length

14
Documentation/ABI/testing/configfs-usb-gadget-subset Normal file
View file

@ -0,0 +1,14 @@
What: /config/usb-gadget/gadget/functions/geth.name
Date: Jun 2013
KernelVersion: 3.11
Description:
The attributes:
ifname - network device interface name associated with
this function instance
qmult - queue length multiplier for high and
super speed
host_addr - MAC address of host's end of this
Ethernet over USB link
dev_addr - MAC address of device's end of this
Ethernet over USB link

12
Documentation/ABI/testing/configfs-usb-gadget-uac1 Normal file
View file

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/uac1.name
Date: Sep 2014
KernelVersion: 3.18
Description:
The attributes:
audio_buf_size - audio buffer size
fn_cap - capture pcm device file name
fn_cntl - control device file name
fn_play - playback pcm device file name
req_buf_size - ISO OUT endpoint request buffer size
req_count - ISO OUT endpoint request count

12
Documentation/ABI/testing/configfs-usb-gadget-uac2 Normal file
View file

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/uac2.name
Date: Sep 2014
KernelVersion: 3.18
Description:
The attributes:
c_chmask - capture channel mask
c_srate - capture sampling rate
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
p_srate - playback sampling rate
p_ssize - playback sample size (bytes)

91
Documentation/ABI/testing/debugfs-driver-genwqe Normal file
View file

@ -0,0 +1,91 @@
What: /sys/kernel/debug/genwqe/genwqe<n>_card/ddcb_info
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: DDCB queue dump used for debugging queueing problems.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_regs
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump of the current error registers.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid0
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID0 (unit id 0).
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid1
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID1.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid2
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID2.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump of the error registers before the last reset of
the card occured.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID0 before card was reset.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid1
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID1 before card was reset.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid2
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID2 before card was reset.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/info
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Comprehensive summary of bitstream version and software
version. Used bitstream and bitstream clocking information.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/err_inject
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Possibility to inject error cases to ensure that the drivers
error handling code works well.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/vf<0..14>_jobtimeout_msec
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Default VF timeout 250ms. Testing might require 1000ms.
Using 0 will use the cards default value (whatever that is).
The timeout depends on the max number of available cards
in the system and the maximum allowed queue size.
The driver ensures that the settings are done just before
the VFs get enabled. Changing the timeouts in flight is not
possible.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/jobtimer
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump job timeout register values for PF and VFs.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/queue_working_time
Date: Dec 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump queue working time register values for PF and VFs.
Only available for PF.

20
Documentation/ABI/testing/debugfs-ec Normal file
View file

@ -0,0 +1,20 @@
What: /sys/kernel/debug/ec/*/{gpe,use_global_lock,io}
Date: July 2010
Contact: Thomas Renninger <trenn@suse.de>
Description:
General information like which GPE is assigned to the EC and whether
the global lock should get used.
Knowing the EC GPE one can watch the amount of HW events related to
the EC here (XY -> GPE number from /sys/kernel/debug/ec/*/gpe):
/sys/firmware/acpi/interrupts/gpeXY
The io file is binary and a userspace tool located here:
ftp://ftp.suse.com/pub/people/trenn/sources/ec/
should get used to read out the 256 Embedded Controller registers
or writing to them.
CAUTION: Do not write to the Embedded Controller if you don't know
what you are doing! Rebooting afterwards also is a good idea.
This can influence the way your machine is cooled and fans may
not get switched on again after you did a wrong write.

19
Documentation/ABI/testing/debugfs-ideapad Normal file
View file

@ -0,0 +1,19 @@
What: /sys/kernel/debug/ideapad/cfg
Date: Sep 2011
KernelVersion: 3.2
Contact: Ike Panhc <ike.pan@canonical.com>
Description:
cfg shows the return value of _CFG method in VPC2004 device. It tells machine
capability and what graphic component within the machine.
What: /sys/kernel/debug/ideapad/status
Date: Sep 2011
KernelVersion: 3.2
Contact: Ike Panhc <ike.pan@canonical.com>
Description:
status shows infos we can read and tells its meaning and value.

16
Documentation/ABI/testing/debugfs-olpc Normal file
View file

@ -0,0 +1,16 @@
What: /sys/kernel/debug/olpc-ec/cmd
Date: Dec 2011
KernelVersion: 3.4
Contact: devel@lists.laptop.org
Description:
A generic interface for executing OLPC Embedded Controller commands and
reading their responses.
To execute a command, write data with the format: CC:N A A A A
CC is the (hex) command, N is the count of expected reply bytes, and A A A A
are optional (hex) arguments.
To read the response (if any), read from the generic node after executing
a command. Hex reply bytes will be returned, *whether or not* they came from
the immediately previous command.

45
Documentation/ABI/testing/debugfs-pfo-nx-crypto Normal file
View file

@ -0,0 +1,45 @@
What: /sys/kernel/debug/nx-crypto/*
Date: March 2012
KernelVersion: 3.4
Contact: Kent Yoder <key@linux.vnet.ibm.com>
Description:
These debugfs interfaces are built by the nx-crypto driver, built in
arch/powerpc/crypto/nx.
Error Detection
===============
errors:
- A u32 providing a total count of errors since the driver was loaded. The
only errors counted here are those returned from the hcall, H_COP_OP.
last_error:
- The most recent non-zero return code from the H_COP_OP hcall. -EBUSY is not
recorded here (the hcall will retry until -EBUSY goes away).
last_error_pid:
- The process ID of the process who received the most recent error from the
hcall.
Device Use
==========
aes_bytes:
- The total number of bytes encrypted using AES in any of the driver's
supported modes.
aes_ops:
- The total number of AES operations submitted to the hardware.
sha256_bytes:
- The total number of bytes hashed by the hardware using SHA-256.
sha256_ops:
- The total number of SHA-256 operations submitted to the hardware.
sha512_bytes:
- The total number of bytes hashed by the hardware using SHA-512.
sha512_ops:
- The total number of SHA-512 operations submitted to the hardware.

19
Documentation/ABI/testing/debugfs-pktcdvd Normal file
View file

@ -0,0 +1,19 @@
What: /sys/kernel/debug/pktcdvd/pktcdvd[0-7]
Date: Oct. 2006
KernelVersion: 2.6.20
Contact: Thomas Maier <balagi@justmail.de>
Description:
debugfs interface
-----------------
The pktcdvd module (packet writing driver) creates
these files in debugfs:
/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/
info (0444) Lots of driver statistics and infos.
Example:
-------
cat /sys/kernel/debug/pktcdvd/pktcdvd0/info

101
Documentation/ABI/testing/dev-kmsg Normal file
View file

@ -0,0 +1,101 @@
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 higher 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.
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. All following fragments are flagged with
'+'. 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.
Users: dmesg(1), userspace kernel log consumers

23
Documentation/ABI/testing/evm Normal file
View file

@ -0,0 +1,23 @@
What: 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 depends on the Kernel Key Retention System to provide it
with a trusted/encrypted key for the HMAC-sha1 operation.
The key is loaded onto the root's keyring using keyctl. Until
EVM receives notification that the key has been successfully
loaded onto the keyring (echo 1 > <securityfs>/evm), EVM
can not create or validate the 'security.evm' xattr, but
returns INTEGRITY_UNKNOWN. Loading the key 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/keys-trusted-encrypted.txt. (A sample dracut
patch, which loads the trusted/encrypted key and enables
EVM, is available from http://linux-ima.sourceforge.net/#EVM.)

85
Documentation/ABI/testing/ima_policy Normal file
View file

@ -0,0 +1,85 @@
What: 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
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
[fowner]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]] [permit_directio]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_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
fowner:=decimal value
lsm: are LSM specific
option: appraise_type:= [imasig]
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_measure fsmagic=0x858458f6
dont_appraise fsmagic=0x858458f6
# SECURITYFS_MAGIC
dont_measure fsmagic=0x73636673
dont_appraise fsmagic=0x73636673
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:
# SELINUX_MAGIC
dont_measure fsmagic=0xf97cff8c
dont_appraise fsmagic=0xf97cff8c
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

22
Documentation/ABI/testing/procfs-diskstats Normal file
View file

@ -0,0 +1,22 @@
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)
For more details refer to Documentation/iostats.txt

47
Documentation/ABI/testing/pstore Normal file
View file

@ -0,0 +1,47 @@
Where: /sys/fs/pstore/... (or /dev/pstore/...)
Date: March 2011
Kernel Version: 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.

99
Documentation/ABI/testing/sysfs-ata Normal file
View file

@ -0,0 +1,99 @@
What: /sys/class/ata_...
Date: August 2008
Contact: Gwendal Grignou<gwendal@google.com>
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.
idle_irq (read)
Number of IRQ received by the port while idle [some ata HBA only].
nr_pmp_links (read)
If a SATA Port Multiplier (PM) is connected, number of link behind it.
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.
hw_sata_spd_limit
Maximum speed supported by the connected SATA device.
sata_spd_limit
Maximum speed imposed by libata.
sata_spd
Current speed of the link [1.5, 3Gps,...].
Files under /sys/class/ata_device
---------------------------------
Behind each link, up to two ata device 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.
class
Device class. Can be "ata" for disk, "atapi" for packet device,
"pmp" for PM, or "none" if no device was found behind the link.
dma_mode
Transfer modes supported by the device when in DMA mode.
Mostly used by PATA device.
pio_mode
Transfer modes supported by the device when in PIO mode.
Mostly used by PATA device.
xfer_mode
Current transfer mode.
id
Cached result of IDENTIFY command, as described in ATA8 7.16 and 7.17.
Only valid if the device is not a PM.
gscr
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.
spdn_cnt
Number of time libata decided to lower the speed of link due to errors.
ering
Formatted output of the error ring of the device.

230
Documentation/ABI/testing/sysfs-block Normal file
View file

@ -0,0 +1,230 @@
What: /sys/block/<disk>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/stat files displays the I/O
statistics of disk <disk>. They contain 11 fields:
1 - reads completed successfully
2 - reads merged
3 - sectors read
4 - time spent reading (ms)
5 - writes completed
6 - writes merged
7 - sectors written
8 - time spent writing (ms)
9 - I/Os currently in progress
10 - time spent doing I/Os (ms)
11 - weighted time spent doing I/Os (ms)
For more details refer Documentation/iostats.txt
What: /sys/block/<disk>/<part>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/<part>/stat files display the
I/O statistics of partition <part>. The format is the
same as the above-written /sys/block/<disk>/stat
format.
What: /sys/block/<disk>/integrity/format
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Metadata format for integrity capable block device.
E.g. T10-DIF-TYPE1-CRC.
What: /sys/block/<disk>/integrity/read_verify
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether the block layer should verify the
integrity of read requests serviced by devices that
support sending integrity metadata.
What: /sys/block/<disk>/integrity/tag_size
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Number of bytes of integrity tag space available per
512 bytes of data.
What: /sys/block/<disk>/integrity/device_is_integrity_capable
Date: July 2014
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether a storage device is capable of storing
integrity metadata. Set if the device is T10 PI-capable.
What: /sys/block/<disk>/integrity/write_generate
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether the block layer should automatically
generate checksums for write requests bound for
devices that support receiving integrity metadata.
What: /sys/block/<disk>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a physical block size that is
bigger than the logical block size (for instance a drive
with 4KB physical sectors exposing 512-byte logical
blocks to the operating system). This parameter
indicates how many bytes the beginning of the device is
offset from the disk's natural alignment.
What: /sys/block/<disk>/<partition>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a physical block size that is
bigger than the logical block size (for instance a drive
with 4KB physical sectors exposing 512-byte logical
blocks to the operating system). This parameter
indicates how many bytes the beginning of the partition
is offset from the disk's natural alignment.
What: /sys/block/<disk>/queue/logical_block_size
Date: May 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
This is the smallest unit the storage device can
address. It is typically 512 bytes.
What: /sys/block/<disk>/queue/physical_block_size
Date: May 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
This is the smallest unit a physical storage device can
write atomically. It is usually the same as the logical
block size but may be bigger. One example is SATA
drives with 4KB sectors that expose a 512-byte logical
block size to the operating system. For stacked block
devices the physical_block_size variable contains the
maximum physical_block_size of the component devices.
What: /sys/block/<disk>/queue/minimum_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a granularity or preferred
minimum I/O size which is the smallest request the
device can perform without incurring a performance
penalty. For disk drives this is often the physical
block size. For RAID arrays it is often the stripe
chunk size. A properly aligned multiple of
minimum_io_size is the preferred request size for
workloads where a high number of I/O operations is
desired.
What: /sys/block/<disk>/queue/optimal_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report an optimal I/O size, which is
the device's preferred unit for sustained I/O. This is
rarely reported for disk drives. For RAID arrays it is
usually the stripe width or the internal track size. A
properly aligned multiple of optimal_io_size is the
preferred request size for workloads where sustained
throughput is desired. If no optimal I/O size is
reported this file contains 0.
What: /sys/block/<disk>/queue/nomerges
Date: January 2010
Contact:
Description:
Standard I/O elevator operations include attempts to
merge contiguous I/Os. For known random I/O loads these
attempts will always fail and result in extra cycles
being spent in the kernel. This allows one to turn off
this behavior on one of two ways: When set to 1, complex
merge checks are disabled, but the simple one-shot merges
with the previous I/O request are enabled. When set to 2,
all merge tries are disabled. The default value is 0 -
which enables all types of merge tries.
What: /sys/block/<disk>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
device is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/<partition>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
partition is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/queue/discard_granularity
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space using units that are bigger
than the logical block size. The discard_granularity
parameter indicates the size of the internal allocation
unit in bytes if reported by the device. Otherwise the
discard_granularity will be set to match the device's
physical block size. A discard_granularity of 0 means
that the device does not support discard functionality.
What: /sys/block/<disk>/queue/discard_max_bytes
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may have
internal limits on the number of bytes that can be
trimmed or unmapped in a single operation. Some storage
protocols also have inherent limits on the number of
blocks that can be described in a single command. The
discard_max_bytes parameter is set by the device driver
to the maximum number of bytes that can be discarded in
a single operation. Discard requests issued to the
device must not exceed this limit. A discard_max_bytes
value of 0 means that the device does not support
discard functionality.
What: /sys/block/<disk>/queue/discard_zeroes_data
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may return
stale or random data when a previously discarded block
is read back. This can cause problems if the filesystem
expects discarded blocks to be explicitly cleared. If a
device reports that it deterministically returns zeroes
when a discarded area is read the discard_zeroes_data
parameter will be set to one. Otherwise it will be 0 and
the result of reading a discarded area is undefined.
What: /sys/block/<disk>/queue/write_same_max_bytes
Date: January 2012
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Some devices support a write same operation in which a
single data block can be written to a range of several
contiguous blocks on storage. This can be used to wipe
areas on disk or to initialize drives in a RAID
configuration. write_same_max_bytes indicates how many
bytes can be written in a single write same command. If
write_same_max_bytes is 0, write same is not supported
by the device.

156
Documentation/ABI/testing/sysfs-block-bcache Normal file
View file

@ -0,0 +1,156 @@
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.

25
Documentation/ABI/testing/sysfs-block-dm Normal file
View file

@ -0,0 +1,25 @@
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

5
Documentation/ABI/testing/sysfs-block-rssd Normal file
View file

@ -0,0 +1,5 @@
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.

143
Documentation/ABI/testing/sysfs-block-zram Normal file
View file

@ -0,0 +1,143 @@
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>/num_reads
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The num_reads file is read-only and specifies the number of
reads (failed or successful) done on this device.
What: /sys/block/zram<id>/num_writes
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The num_writes file is read-only and specifies the number of
writes (failed or successful) done on this device.
What: /sys/block/zram<id>/invalid_io
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The invalid_io file is read-only and specifies the number of
non-page-size-aligned I/O requests issued to this device.
What: /sys/block/zram<id>/failed_reads
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_reads file is read-only and specifies the number of
failed reads happened on this device.
What: /sys/block/zram<id>/failed_writes
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_writes file is read-only and specifies the number of
failed writes happened on 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>/notify_free
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The notify_free file is read-only. Depending on device usage
scenario it may account a) the number of pages freed because
of swap slot free notifications or b) the number of pages freed
because of REQ_DISCARD requests sent by bio. The former ones
are sent to a swap block device when a swap slot is freed, which
implies that this disk is being used as a swap disk. The latter
ones are sent by filesystem mounted with discard option,
whenever some data blocks are getting discarded.
What: /sys/block/zram<id>/zero_pages
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The zero_pages file is read-only and specifies number of zero
filled pages written to this disk. No memory is allocated for
such pages.
What: /sys/block/zram<id>/orig_data_size
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The orig_data_size file is read-only and specifies uncompressed
size of data stored in this disk. This excludes zero-filled
pages (zero_pages) since no memory is allocated for them.
Unit: bytes
What: /sys/block/zram<id>/compr_data_size
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The compr_data_size file is read-only and specifies compressed
size of data stored in this disk. So, compression ratio can be
calculated using orig_data_size and this statistic.
Unit: bytes
What: /sys/block/zram<id>/mem_used_total
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The mem_used_total file is read-only and specifies the amount
of memory, including allocator fragmentation and metadata
overhead, allocated for this disk. So, allocator space
efficiency can be calculated using compr_data_size and this
statistic.
Unit: bytes
What: /sys/block/zram<id>/mem_used_max
Date: August 2014
Contact: Minchan Kim <minchan@kernel.org>
Description:
The mem_used_max file is read/write and specifies the amount
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 read/write 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

58
Documentation/ABI/testing/sysfs-bus-acpi Normal file
View file

@ -0,0 +1,58 @@
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.

31
Documentation/ABI/testing/sysfs-bus-bcma Normal file
View file

@ -0,0 +1,31 @@
What: /sys/bus/bcma/devices/.../manuf
Date: May 2011
KernelVersion: 3.0
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core has it's 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.

35
Documentation/ABI/testing/sysfs-bus-css Normal file
View file

@ -0,0 +1,35 @@
What: /sys/bus/css/devices/.../type
Date: March 2008
Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the subchannel type, as reported by the hardware.
This attribute is present for all subchannel types.
What: /sys/bus/css/devices/.../modalias
Date: March 2008
Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the module alias as reported with uevents.
It is of the format css:t<type> and present for all
subchannel types.
What: /sys/bus/css/drivers/io_subchannel/.../chpids
Date: December 2002
Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the ids of the channel paths used by this
subchannel, as reported by the channel subsystem
during subchannel recognition.
Note: This is an I/O-subchannel specific attribute.
Users: s390-tools, HAL
What: /sys/bus/css/drivers/io_subchannel/.../pimpampom
Date: December 2002
Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the PIM/PAM/POM values, as reported by the
channel subsystem when last queried by the common I/O
layer (this implies that this attribute is not necessarily
in sync with the values current in the channel subsystem).
Note: This is an I/O-subchannel specific attribute.
Users: s390-tools, HAL

88
Documentation/ABI/testing/sysfs-bus-event_source-devices-events Normal file
View file

@ -0,0 +1,88 @@
What: /sys/devices/cpu/events/
/sys/devices/cpu/events/branch-misses
/sys/devices/cpu/events/cache-references
/sys/devices/cpu/events/cache-misses
/sys/devices/cpu/events/stalled-cycles-frontend
/sys/devices/cpu/events/branch-instructions
/sys/devices/cpu/events/stalled-cycles-backend
/sys/devices/cpu/events/instructions
/sys/devices/cpu/events/cpu-cycles
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Generic performance monitoring events
A collection of performance monitoring events that may be
supported by many/most CPUs. These events can be monitored
using the 'perf(1)' tool.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
What: /sys/bus/event_source/devices/<pmu>/events/<event>
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Per-pmu performance monitoring events specific to the running system
Each file (except for some of those with a '.' in them, '.unit'
and '.scale') in the 'events' directory describes a single
performance monitoring event supported by the <pmu>. The name
of the file is the name of the event.
File contents:
<term>[=<value>][,<term>[=<value>]]...
Where <term> is one of the terms listed under
/sys/bus/event_source/devices/<pmu>/format/ and <value> is
a number is base-16 format with a '0x' prefix (lowercase only).
If a <term> is specified alone (without an assigned value), it
is implied that 0x1 is assigned to that <term>.
Examples (each of these lines would be in a seperate file):
event=0x2abc
event=0x423,inv,cmask=0x3
domain=0x1,offset=0x8,starting_index=0xffff
Each of the assignments indicates a value to be assigned to a
particular set of bits (as defined by the format file
corresponding to the <term>) in the perf_event structure passed
to the perf_open syscall.
What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Perf event units
A string specifying the English plural numerical unit that <event>
(once multiplied by <event>.scale) represents.
Example:
Joules
What: /sys/bus/event_source/devices/<pmu>/events/<event>.scale
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Perf event scaling factors
A string representing a floating point value expressed in
scientific notation to be multiplied by the event count
recieved from the kernel to match the unit specified in the
<event>.unit file.
Example:
2.3283064365386962890625e-10
This is provided to avoid performing floating point arithmetic
in the kernel.

20
Documentation/ABI/testing/sysfs-bus-event_source-devices-format Normal file
View file

@ -0,0 +1,20 @@
Where: /sys/bus/event_source/devices/<dev>/format
Date: January 2012
Kernel Version: 3.3
Contact: Jiri Olsa <jolsa@redhat.com>
Description:
Attribute group to describe the magic bits that go into
perf_event_attr::config[012] for a particular pmu.
Each attribute of this group defines the 'hardware' bitmask
we want to export, so that userspace can deal with sane
name/value pairs.
Userspace must be prepared for the possibility that attributes
define overlapping bit ranges. For example:
attr1 = 'config:0-23'
attr2 = 'config:0-7'
attr3 = 'config:12-35'
Example: 'config1:1,6-10,44'
Defines contents of attribute that occupies bits 1,6-10,44 of
perf_event_attr::config1.

23
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 Normal file
View file

@ -0,0 +1,23 @@
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Provides access to the binary "24x7 catalog" provided by the
hypervisor on POWER7 and 8 systems. This catalog lists events
avaliable from the powerpc "hv_24x7" pmu. Its format is
documented here:
https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_length
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number equal to the length in bytes of the catalog. This is
also extractable from the provided binary "catalog" sysfs entry.
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_version
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.

43
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci Normal file
View file

@ -0,0 +1,43 @@
What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
'0' if the hypervisor is configured to forbid access to event
counters being accumulated by other guests and to physical
domain event counters.
'1' if that access is allowed.
What: /sys/bus/event_source/devices/hv_gpci/interface/ga
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
0 or 1. Indicates whether we have access to "GA" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/expanded
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
0 or 1. Indicates whether we have access to "EXPANDED" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/lab
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
0 or 1. Indicates whether we have access to "LAB" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/version
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number indicating the version of the gpci interface that the
hypervisor reports supporting.
What: /sys/bus/event_source/devices/hv_gpci/interface/kernel_version
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number indicating the latest version of the gpci interface
that the kernel is aware of.

116
Documentation/ABI/testing/sysfs-bus-fcoe Normal file
View file

@ -0,0 +1,116 @@
What: /sys/bus/fcoe/
Date: August 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: The FCoE bus. Attributes in this directory are control interfaces.
Attributes:
ctlr_create: 'FCoE Controller' instance creation interface. Writing an
<ifname> to this file will allocate and populate sysfs with a
fcoe_ctlr_device (ctlr_X). The user can then configure any
per-port settings and finally write to the fcoe_ctlr_device's
'start' attribute to begin the kernel's discovery and login
process.
ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
fcoe_ctlr_device's sysfs name to this file will log the
fcoe_ctlr_device out of the fabric or otherwise connected
FCoE devices. It will also free all kernel memory allocated
for this fcoe_ctlr_device and any structures associated
with it, this includes the scsi_host.
What: /sys/bus/fcoe/devices/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: 'FCoE Controller' instances on the fcoe bus.
The FCoE Controller now has a three stage creation process.
1) Write interface name to ctlr_create 2) Configure the FCoE
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
discovery and login. The FCoE Controller is destroyed by
writing it's name, i.e. ctlr_X to the ctlr_delete file.
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
mode: Display or change the FCoE Controller's mode. Possible
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
is started in 'Fabric' mode then FIP FCF discovery is
initiated and ultimately a fabric login is attempted.
If a FCoE Controller is started in 'VN2VN' mode then
FIP VN2VN discovery and login is performed. A FCoE
Controller only supports one mode at a time.
enabled: Whether an FCoE controller is enabled or disabled.
0 if disabled, 1 if enabled. Writing either 0 or 1
to this file will enable or disable the FCoE controller.
lesb/link_fail: Link Error Status Block (LESB) link failure count.
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
failure count.
lesb/miss_fka: Link Error Status Block (LESB) missed FCoE
Initialization Protocol (FIP) Keep-Alives (FKA).
lesb/symb_err: Link Error Status Block (LESB) symbolic error count.
lesb/err_block: Link Error Status Block (LESB) block error count.
lesb/fcs_error: Link Error Status Block (LESB) Fibre Channel
Serivces error count.
Notes: ctlr_X (global increment starting at 0)
What: /sys/bus/fcoe/devices/fcf_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: 'FCoE FCF' instances on the fcoe bus. A FCF is a Fibre Channel
Forwarder, which is a FCoE switch that can accept FCoE
(Ethernet) packets, unpack them, and forward the embedded
Fibre Channel frames into a FC fabric. It can also take
outbound FC frames and pack them in Ethernet packets to
be sent to their destination on the Ethernet segment.
Attributes:
fabric_name: Identifies the fabric that the FCF services.
switch_name: Identifies the FCF.
priority: The switch's priority amongst other FCFs on the same
fabric.
selected: 1 indicates that the switch has been selected for use;
0 indicates that the swich will not be used.
fc_map: The Fibre Channel MAP
vfid: The Virtual Fabric ID
mac: The FCF's MAC address
fka_peroid: The FIP Keep-Alive peroid
fabric_state: The internal kernel state
"Unknown" - Initialization value
"Disconnected" - No link to the FCF/fabric
"Connected" - Host is connected to the FCF
"Deleted" - FCF is being removed from the system
dev_loss_tmo: The device loss timeout peroid for this FCF.
Notes: A device loss infrastructre similar to the FC Transport's
is present in fcoe_sysfs. It is nice to have so that a
link flapping adapter doesn't continually advance the count
used to identify the discovered FCF. FCFs will exist in a
"Disconnected" state until either the timer expires and the
FCF becomes "Deleted" or the FCF is rediscovered and becomes
"Connected."
Users: The first user of this interface will be the fcoeadm application,
which is commonly packaged in the fcoe-utils package.

19
Documentation/ABI/testing/sysfs-bus-hsi Normal file
View file

@ -0,0 +1,19 @@
What: /sys/bus/hsi
Date: April 2012
KernelVersion: 3.4
Contact: Carlos Chinea <carlos.chinea@nokia.com>
Description:
High Speed Synchronous Serial Interface (HSI) is a
serial interface mainly used for connecting application
engines (APE) with cellular modem engines (CMT) in cellular
handsets.
The bus will be populated with devices (hsi_clients) representing
the protocols available in the system. Bus drivers implement
those protocols.
What: /sys/bus/hsi/devices/.../modalias
Date: April 2012
KernelVersion: 3.4
Contact: Carlos Chinea <carlos.chinea@nokia.com>
Description: Stores the same MODALIAS value emitted by uevent
Format: hsi:<hsi_client device name>

21
Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 Normal file
View file

@ -0,0 +1,21 @@
What: /sys/bus/i2c/devices/.../device
Date: February 2011
Contact: Minkyu Kang <mk7.kang@samsung.com>
Description:
show what device is attached
NONE - no device
USB - USB device is attached
UART - UART is attached
CHARGER - Charger is attaced
JIG - JIG is attached
What: /sys/bus/i2c/devices/.../switch
Date: February 2011
Contact: Minkyu Kang <mk7.kang@samsung.com>
Description:
show or set the state of manual switch
VAUDIO - switch to VAUDIO path
UART - switch to UART path
AUDIO - switch to AUDIO path
DHOST - switch to DHOST path
AUTO - switch automatically by device

21
Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 Normal file
View file

@ -0,0 +1,21 @@
Where: /sys/bus/i2c/devices/.../heading0_input
Date: April 2010
Kernel Version: 2.6.36?
Contact: alan.cox@intel.com
Description: Reports the current heading from the compass as a floating
point value in degrees.
Where: /sys/bus/i2c/devices/.../power_state
Date: April 2010
Kernel Version: 2.6.36?
Contact: alan.cox@intel.com
Description: Sets the power state of the device. 0 sets the device into
sleep mode, 1 wakes it up.
Where: /sys/bus/i2c/devices/.../calibration
Date: April 2010
Kernel Version: 2.6.36?
Contact: alan.cox@intel.com
Description: Sets the calibration on or off (1 = on, 0 = off). See the
chip data sheet.

15
Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533 Normal file
View file

@ -0,0 +1,15 @@
What: /sys/bus/i2c/devices/.../output_hvled[n]
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the controlling backlight device for high-voltage current
sink HVLED[n] (n = 1, 2) (0, 1).
What: /sys/bus/i2c/devices/.../output_lvled[n]
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the controlling led device for low-voltage current sink
LVLED[n] (n = 1..5) (0..3).

1030
Documentation/ABI/testing/sysfs-bus-iio Normal file
View file

File diff suppressed because it is too large Load diff

7
Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150 Normal file
View file

@ -0,0 +1,7 @@
What: /sys/bus/iio/devices/triggerX/name = "bmc150_accel-any-motion-devX"
KernelVersion: 3.17
Contact: linux-iio@vger.kernel.org
Description:
The BMC150 accelerometer kernel module provides an additional trigger,
which sets driver in a mode, where data is pushed to the buffer
only when there is any motion.

29
Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 Normal file
View file

@ -0,0 +1,29 @@
What: /sys/bus/iio/devices/iio:deviceX/pll2_feedback_clk_present
What: /sys/bus/iio/devices/iio:deviceX/pll2_reference_clk_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_a_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_b_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_test_present
What: /sys/bus/iio/devices/iio:deviceX/vcxo_clk_present
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'.
'1' means that the clock in question is present.
'0' means that the clock is missing.
What: /sys/bus/iio/devices/iio:deviceX/pllY_locked
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'. '1' means that the
pllY is locked.
What: /sys/bus/iio/devices/iio:deviceX/sync_dividers
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Writing '1' triggers the clock distribution synchronization
functionality. All dividers are reset and the channels start
with their predefined phase offsets (out_altvoltageY_phase).
Writing this file has the effect as driving the external
/SYNC pin low.

21
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 Normal file
View file

@ -0,0 +1,21 @@
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_resolution
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Stores channel Y frequency resolution/channel spacing in Hz.
The value given directly influences the MODULUS used by
the fractional-N PLL. It is assumed that the algorithm
that is used to compute the various dividers, is able to
generate proper values for multiples of channel spacing.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_refin_frequency
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Sets channel Y REFin frequency in Hz. In some clock chained
applications, the reference frequency used by the PLL may
change during runtime. This attribute allows the user to
adjust the reference frequency accordingly.
The value written has no effect until out_altvoltageY_frequency
is updated. Consider to use out_altvoltageY_powerdown to power
down the PLL and its RFOut buffers during REFin changes.

7
Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160 Normal file
View file

@ -0,0 +1,7 @@
What: /sys/bus/iio/devices/triggerX/name = "bmg160-any-motion-devX"
KernelVersion: 3.17
Contact: linux-iio@vger.kernel.org
Description:
The BMG160 gyro kernel module provides an additional trigger,
which sets driver in a mode, where data is pushed to the buffer
only when there is any motion.

61
Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als Normal file
View file

@ -0,0 +1,61 @@
What: /sys/.../events/in_illuminance0_thresh_either_en
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Event generated when channel passes one of the four thresholds
in each direction (rising|falling) and a zone change occurs.
The corresponding light zone can be read from
in_illuminance0_zone.
What: /sys/.../events/in_illuminance0_threshY_hysteresis
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the hysteresis for thresholds Y, that is,
threshY_hysteresis = threshY_raising - threshY_falling
What: /sys/.../events/illuminance_threshY_falling_value
What: /sys/.../events/illuminance_threshY_raising_value
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Specifies the value of threshold that the device is comparing
against for the events enabled by
in_illuminance0_thresh_either_en (0..255), where Y in 0..3.
Note that threshY_falling must be less than or equal to
threshY_raising.
These thresholds correspond to the eight zone-boundary
registers (boundaryY_{low,high}) and define the five light
zones.
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_zone
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the current light zone (0..4) as defined by the
in_illuminance0_threshY_{falling,rising} thresholds.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get output current for channel Y (0..255), that is,
out_currentY_currentZ_raw, where Z is the current zone.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_currentZ_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the output current for channel out_currentY when in zone
Z (0..255), where Y in 0..2 and Z in 0..4.
These values correspond to the ALS-mapper target registers for
ALS-mapper Y + 1.

13
Documentation/ABI/testing/sysfs-bus-iio-mpu6050 Normal file
View file

@ -0,0 +1,13 @@
What: /sys/bus/iio/devices/iio:deviceX/in_gyro_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_accel_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_magn_matrix
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
This is mounting matrix for motion sensors. Mounting matrix
is a 3x3 unitary matrix. A typical mounting matrix would look like
[0, 1, 0; 1, 0, 0; 0, 0, -1]. Using this information, it would be
easy to tell the relative positions among sensors as well as their
positions relative to the board that holds these sensors. Identity matrix
[1, 0, 0; 0, 1, 0; 0, 0, 1] means sensor chip and device are perfectly
aligned with each other. All axes are exactly the same.

16
Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 Normal file
View file

@ -0,0 +1,16 @@
What /sys/bus/iio/devices/iio:deviceX/in_proximity_raw
Date: March 2014
KernelVersion: 3.15
Contact: Matt Ranostay <mranostay@gmail.com>
Description:
Get the current distance in meters of storm (1km steps)
1000-40000 = distance in meters
What /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
Date: March 2014
KernelVersion: 3.15
Contact: Matt Ranostay <mranostay@gmail.com>
Description:
Show or set the gain boost of the amp, from 0-31 range.
18 = indoors (default)
14 = outdoors

11
Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs Normal file
View file

@ -0,0 +1,11 @@
What: /sys/bus/iio/devices/triggerX/trigger_now
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
This file is provided by the iio-trig-sysfs stand-alone trigger
driver. Writing this file with any value triggers an event
driven driver, associated with this trigger, to capture data
into an in kernel buffer. This approach can be valuable during
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.

29
Documentation/ABI/testing/sysfs-bus-mdio Normal file
View file

@ -0,0 +1,29 @@
What: /sys/bus/mdio_bus/devices/.../phy_id
Date: November 2012
KernelVersion: 3.8
Contact: netdev@vger.kernel.org
Description:
This attribute contains the 32-bit PHY Identifier as reported
by the device during bus enumeration, encoded in hexadecimal.
This ID is used to match the device with the appropriate
driver.
What: /sys/bus/mdio_bus/devices/.../phy_interface
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the PHY interface as configured by the
Ethernet driver during bus enumeration, encoded in string.
This interface mode is used to configure the Ethernet MAC with the
appropriate mode for its data lines to the PHY hardware.
What: /sys/bus/mdio_bus/devices/.../phy_has_fixups
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the boolean value whether a given PHY
device has had any "fixup" workaround running on it, encoded as
a boolean. This information is provided to help troubleshooting
PHY configurations.

6
Documentation/ABI/testing/sysfs-bus-media Normal file
View file

@ -0,0 +1,6 @@
What: /sys/bus/media/devices/.../model
Date: January 2011
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
linux-media@vger.kernel.org
Description: Contains the device model name in UTF-8. The device version is
is not be appended to the model name.

7
Documentation/ABI/testing/sysfs-bus-mei Normal file
View file

@ -0,0 +1,7 @@
What: /sys/bus/mei/devices/.../modalias
Date: March 2013
KernelVersion: 3.10
Contact: Samuel Ortiz <sameo@linux.intel.com>
linux-mei@linux.intel.com
Description: Stores the same MODALIAS value emitted by uevent
Format: mei:<mei device name>

283
Documentation/ABI/testing/sysfs-bus-pci Normal file
View file

@ -0,0 +1,283 @@
What: /sys/bus/pci/drivers/.../bind
Date: December 2003
Contact: linux-pci@vger.kernel.org
Description:
Writing a device location to this file will cause
the driver to attempt to bind to the device found at
this location. This is useful for overriding default
bindings. The format for the location is: DDDD:BB:DD.F.
That is Domain:Bus:Device.Function and is the same as
found in /sys/bus/pci/devices/. For example:
# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
(Note: kernels before 2.6.28 may require echo -n).
What: /sys/bus/pci/drivers/.../unbind
Date: December 2003
Contact: linux-pci@vger.kernel.org
Description:
Writing a device location to this file will cause the
driver to attempt to unbind from the device found at
this location. This may be useful when overriding default
bindings. The format for the location is: DDDD:BB:DD.F.
That is Domain:Bus:Device.Function and is the same as
found in /sys/bus/pci/devices/. For example:
# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
(Note: kernels before 2.6.28 may require echo -n).
What: /sys/bus/pci/drivers/.../new_id
Date: December 2003
Contact: linux-pci@vger.kernel.org
Description:
Writing a device ID to this file will attempt to
dynamically add a new device ID to a PCI device driver.
This may allow the driver to support more hardware than
was included in the driver's static device ID support
table at compile time. The format for the device ID is:
VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID,
Device ID, Subsystem Vendor ID, Subsystem Device ID,
Class, Class Mask, and Private Driver Data. The Vendor ID
and Device ID fields are required, the rest are optional.
Upon successfully adding an ID, the driver will probe
for the device and attempt to bind to it. For example:
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
What: /sys/bus/pci/drivers/.../remove_id
Date: February 2009
Contact: Chris Wright <chrisw@sous-sol.org>
Description:
Writing a device ID to this file will remove an ID
that was dynamically added via the new_id sysfs entry.
The format for the device ID is:
VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
ID, Subsystem Vendor ID, Subsystem Device ID, Class,
and Class Mask. The Vendor ID and Device ID fields are
required, the rest are optional. After successfully
removing an ID, the driver will no longer support the
device. This is useful to ensure auto probing won't
match the driver to the device. For example:
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id
What: /sys/bus/pci/rescan
Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a non-zero value to this attribute will
force a rescan of all PCI buses in the system, and
re-discover previously removed devices.
What: /sys/bus/pci/devices/.../msi_bus
Date: September 2014
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a zero value to this attribute disallows MSI and
MSI-X for any future drivers of the device. If the device
is a bridge, MSI and MSI-X will be disallowed for future
drivers of all child devices under the bridge. Drivers
must be reloaded for the new setting to take effect.
What: /sys/bus/pci/devices/.../msi_irqs/
Date: September, 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
The /sys/devices/.../msi_irqs directory contains a variable set
of files, with each file being named after a corresponding msi
irq vector allocated to that device.
What: /sys/bus/pci/devices/.../msi_irqs/<N>
Date: September 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
This attribute indicates the mode that the irq vector named by
the file is in (msi vs. msix)
What: /sys/bus/pci/devices/.../remove
Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a non-zero value to this attribute will
hot-remove the PCI device and any of its children.
What: /sys/bus/pci/devices/.../pci_bus/.../rescan
Date: May 2011
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a non-zero value to this attribute will
force a rescan of the bus and all child buses,
and re-discover devices removed earlier from this
part of the device tree.
What: /sys/bus/pci/devices/.../rescan
Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a non-zero value to this attribute will
force a rescan of the device's parent bus and all
child buses, and re-discover devices removed earlier
from this part of the device tree.
What: /sys/bus/pci/devices/.../reset
Date: July 2009
Contact: Michael S. Tsirkin <mst@redhat.com>
Description:
Some devices allow an individual function to be reset
without affecting other functions in the same device.
For devices that have this support, a file named reset
will be present in sysfs. Writing 1 to this file
will perform reset.
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings <bwh@kernel.org>
Description:
A file named vpd in a device directory will be a
binary file containing the Vital Product Data for the
device. It should follow the VPD format defined in
PCI Specification 2.1 or 2.2, but users should consider
that some devices may have malformatted data. If the
underlying VPD has a writable section then the
corresponding section of this file will be writable.
What: /sys/bus/pci/devices/.../virtfnN
Date: March 2009
Contact: Yu Zhao <yu.zhao@intel.com>
Description:
This symbolic link appears when hardware supports the SR-IOV
capability and the Physical Function driver has enabled it.
The symbolic link points to the PCI device sysfs entry of the
Virtual Function whose index is N (0...MaxVFs-1).
What: /sys/bus/pci/devices/.../dep_link
Date: March 2009
Contact: Yu Zhao <yu.zhao@intel.com>
Description:
This symbolic link appears when hardware supports the SR-IOV
capability and the Physical Function driver has enabled it,
and this device has vendor specific dependencies with others.
The symbolic link points to the PCI device sysfs entry of
Physical Function this device depends on.
What: /sys/bus/pci/devices/.../physfn
Date: March 2009
Contact: Yu Zhao <yu.zhao@intel.com>
Description:
This symbolic link appears when a device is a Virtual Function.
The symbolic link points to the PCI device sysfs entry of the
Physical Function this device associates with.
What: /sys/bus/pci/slots/.../module
Date: June 2009
Contact: linux-pci@vger.kernel.org
Description:
This symbolic link points to the PCI hotplug controller driver
module that manages the hotplug slot.
What: /sys/bus/pci/devices/.../label
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given name (SMBIOS type 41 string or ACPI _DSM string) of
the PCI device. The attribute will be created only
if the firmware has given a name to the PCI device.
ACPI _DSM string name will be given priority if the
system firmware provides SMBIOS type 41 string also.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
What: /sys/bus/pci/devices/.../index
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance (SMBIOS type 41 device type instance) of the
PCI device. The attribute will be created only if the firmware
has given an instance number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
What: /sys/bus/pci/devices/.../acpi_index
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance (ACPI _DSM instance number) of the PCI device.
The attribute will be created only if the firmware has given
an instance number to the PCI device. ACPI _DSM instance number
will be given priority if the system firmware provides SMBIOS
type 41 device type instance also.
Users:
Userspace applications interested in knowing the
firmware assigned instance number of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
What: /sys/bus/pci/devices/.../d3cold_allowed
Date: July 2012
Contact: Huang Ying <ying.huang@intel.com>
Description:
d3cold_allowed is bit to control whether the corresponding PCI
device can be put into D3Cold state. If it is cleared, the
device will never be put into D3Cold state. If it is set, the
device may be put into D3Cold state if other requirements are
satisfied too. Reading this attribute will show the current
value of d3cold_allowed bit. Writing this attribute will set
the value of d3cold_allowed bit.
What: /sys/bus/pci/devices/.../sriov_totalvfs
Date: November 2012
Contact: Donald Dutile <ddutile@redhat.com>
Description:
This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read this file to determine the
maximum number of Virtual Functions (VFs) a PCIe physical
function (PF) can support. Typically, this is the value reported
in the PF's SR-IOV extended capability structure's TotalVFs
element. Drivers have the ability at probe time to reduce the
value read from this file via the pci_sriov_set_totalvfs()
function.
What: /sys/bus/pci/devices/.../sriov_numvfs
Date: November 2012
Contact: Donald Dutile <ddutile@redhat.com>
Description:
This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read and write to this file to
determine and control the enablement or disablement of Virtual
Functions (VFs) on the physical function (PF). A read of this
file will return the number of VFs that are enabled on this PF.
A number written to this file will enable the specified
number of VFs. A userspace application would typically read the
file and check that the value is zero, and then write the number
of VFs that should be enabled on the PF; the value written
should be less than or equal to the value in the sriov_totalvfs
file. A userspace application wanting to disable the VFs would
write a zero to this file. The core ensures that valid values
are written to this file, and returns errors when values are not
valid. For example, writing a 2 to this file when sriov_numvfs
is not 0 and not 2 already will return an error. Writing a 10
when the value of sriov_totalvfs is 8 will return an error.
What: /sys/bus/pci/devices/.../driver_override
Date: April 2014
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
This file allows the driver for a device to be specified which
will override standard static and dynamic ID matching. When
specified, only a driver with a name matching the value written
to driver_override will have an opportunity to bind to the
device. The override is specified by writing a string to the
driver_override file (echo pci-stub > 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.

80
Documentation/ABI/testing/sysfs-bus-pci-devices-cciss Normal file
View file

@ -0,0 +1,80 @@
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/model
Date: March 2009
Kernel Version: 2.6.30
Contact: iss_storagedev@hp.com
Description: Displays the SCSI INQUIRY page 0 model for logical drive
Y of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/rev
Date: March 2009
Kernel Version: 2.6.30
Contact: iss_storagedev@hp.com
Description: Displays the SCSI INQUIRY page 0 revision for logical
drive Y of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/unique_id
Date: March 2009
Kernel Version: 2.6.30
Contact: iss_storagedev@hp.com
Description: Displays the SCSI INQUIRY page 83 serial number for logical
drive Y of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/vendor
Date: March 2009
Kernel Version: 2.6.30
Contact: iss_storagedev@hp.com
Description: Displays the SCSI INQUIRY page 0 vendor for logical drive
Y of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/block:cciss!cXdY
Date: March 2009
Kernel Version: 2.6.30
Contact: iss_storagedev@hp.com
Description: A symbolic link to /sys/block/cciss!cXdY
Where: /sys/bus/pci/devices/<dev>/ccissX/rescan
Date: August 2009
Kernel Version: 2.6.31
Contact: iss_storagedev@hp.com
Description: Kicks of a rescan of the controller to discover logical
drive topology changes.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid
Date: August 2009
Kernel Version: 2.6.31
Contact: iss_storagedev@hp.com
Description: Displays the 8-byte LUN ID used to address logical
drive Y of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level
Date: August 2009
Kernel Version: 2.6.31
Contact: iss_storagedev@hp.com
Description: Displays the RAID level of logical drive Y of
controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count
Date: August 2009
Kernel Version: 2.6.31
Contact: iss_storagedev@hp.com
Description: Displays the usage count (number of opens) of logical drive Y
of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/resettable
Date: February 2011
Kernel Version: 2.6.38
Contact: iss_storagedev@hp.com
Description: Value of 1 indicates the controller can honor the reset_devices
kernel parameter. Value of 0 indicates reset_devices cannot be
honored. This is to allow, for example, kexec tools to be able
to warn the user if they designate an unresettable device as
a dump device, as kdump requires resetting the device in order
to work reliably.
Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
Date: July 2011
Kernel Version: 3.0
Contact: iss_storagedev@hp.com
Description: Value of "simple" indicates that the controller has been placed
in "simple mode". Value of "performant" indicates that the
controller has been placed in "performant mode".

46
Documentation/ABI/testing/sysfs-bus-pci-drivers-ehci_hcd Normal file
View file

@ -0,0 +1,46 @@
What: /sys/bus/pci/drivers/ehci_hcd/.../companion
/sys/bus/usb/devices/usbN/../companion
Date: January 2007
KernelVersion: 2.6.21
Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
PCI-based EHCI USB controllers (i.e., high-speed USB-2.0
controllers) are often implemented along with a set of
"companion" full/low-speed USB-1.1 controllers. When a
high-speed device is plugged in, the connection is routed
to the EHCI controller; when a full- or low-speed device
is plugged in, the connection is routed to the companion
controller.
Sometimes you want to force a high-speed device to connect
at full speed, which can be accomplished by forcing the
connection to be routed to the companion controller.
That's what this file does. Writing a port number to the
file causes connections on that port to be routed to the
companion controller, and writing the negative of a port
number returns the port to normal operation.
For example: To force the high-speed device attached to
port 4 on bus 2 to run at full speed:
echo 4 >/sys/bus/usb/devices/usb2/../companion
To return the port to high-speed operation:
echo -4 >/sys/bus/usb/devices/usb2/../companion
Reading the file gives the list of ports currently forced
to the companion controller.
Note: Some EHCI controllers do not have companions; they
may contain an internal "transaction translator" or they
may be attached directly to a "rate-matching hub". This
mechanism will not work with such controllers. Also, it
cannot be used to force a port on a high-speed hub to
connect at full speed.
Note: When this file was first added, it appeared in a
different sysfs directory. The location given above is
correct for 2.6.35 (and probably several earlier kernel
versions as well).

20
Documentation/ABI/testing/sysfs-bus-platform Normal file
View file

@ -0,0 +1,20 @@
What: /sys/bus/platform/devices/.../driver_override
Date: April 2014
Contact: Kim Phillips <kim.phillips@freescale.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-platform > \
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.

98
Documentation/ABI/testing/sysfs-bus-rbd Normal file
View file

@ -0,0 +1,98 @@
What: /sys/bus/rbd/
Date: November 2010
Contact: Yehuda Sadeh <yehuda@newdream.net>,
Sage Weil <sage@newdream.net>
Description:
Being used for adding and removing rbd block devices.
Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]
$ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add
The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
will be assigned for any registered block device. If snapshot is used, it will
be mapped read-only.
Removal of a device:
$ echo <dev-id> > /sys/bus/rbd/remove
What: /sys/bus/rbd/add_single_major
Date: December 2013
KernelVersion: 3.14
Contact: Sage Weil <sage@inktank.com>
Description: Available only if rbd module is inserted with single_major
parameter set to true.
Usage is the same as for /sys/bus/rbd/add. If present,
should be used instead of the latter: any attempts to use
/sys/bus/rbd/add if /sys/bus/rbd/add_single_major is
available will fail for backwards compatibility reasons.
What: /sys/bus/rbd/remove_single_major
Date: December 2013
KernelVersion: 3.14
Contact: Sage Weil <sage@inktank.com>
Description: Available only if rbd module is inserted with single_major
parameter set to true.
Usage is the same as for /sys/bus/rbd/remove. If present,
should be used instead of the latter: any attempts to use
/sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is
available will fail for backwards compatibility reasons.
Entries under /sys/bus/rbd/devices/<dev-id>/
--------------------------------------------
client_id
The ceph unique client id that was assigned for this specific session.
features
A hexadecimal encoding of the feature bits for this image.
major
The block device major number.
minor
The block device minor number. (December 2013, since 3.14.)
name
The name of the rbd image.
image_id
The unique id for the rbd image. (For rbd image format 1
this is empty.)
pool
The name of the storage pool where this rbd image resides.
An rbd image name is unique within its pool.
pool_id
The unique identifier for the rbd image's pool. This is
a permanent attribute of the pool. A pool's id will never
change.
size
The size (in bytes) of the mapped block device.
refresh
Writing to this file will reread the image header data and set
all relevant datastructures accordingly.
current_snap
The current snapshot for which the device is mapped.
parent
Information identifying the chain of parent images in a layered rbd
image. Entries are separated by empty lines.

75
Documentation/ABI/testing/sysfs-bus-rpmsg Normal file
View file

@ -0,0 +1,75 @@
What: /sys/bus/rpmsg/devices/.../name
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels are identified with a (textual) name,
which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in
rpmsg.h).
This sysfs entry contains the name of this channel.
What: /sys/bus/rpmsg/devices/.../src
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels have a local ("source") rpmsg address,
and remote ("destination") rpmsg address. When an entity
starts listening on one end of a channel, it assigns it with
a unique rpmsg address (a 32 bits integer). This way when
inbound messages arrive to this address, the rpmsg core
dispatches them to the listening entity (a kernel driver).
This sysfs entry contains the src (local) rpmsg address
of this channel. If it contains 0xffffffff, then an address
wasn't assigned (can happen if no driver exists for this
channel).
What: /sys/bus/rpmsg/devices/.../dst
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels have a local ("source") rpmsg address,
and remote ("destination") rpmsg address. When an entity
starts listening on one end of a channel, it assigns it with
a unique rpmsg address (a 32 bits integer). This way when
inbound messages arrive to this address, the rpmsg core
dispatches them to the listening entity.
This sysfs entry contains the dst (remote) rpmsg address
of this channel. If it contains 0xffffffff, then an address
wasn't assigned (can happen if the kernel driver that
is attached to this channel is exposing a service to the
remote processor. This make it a local rpmsg server,
and it is listening for inbound messages that may be sent
from any remote rpmsg client; it is not bound to a single
remote entity).
What: /sys/bus/rpmsg/devices/.../announce
Date: June 2011
KernelVersion: 3.3
Contact: Ohad Ben-Cohen <ohad@wizery.com>
Description:
Every rpmsg device is a communication channel with a remote
processor. Channels are identified by a textual name (see
/sys/bus/rpmsg/devices/.../name above) and have a local
("source") rpmsg address, and remote ("destination") rpmsg
address.
A channel is first created when an entity, whether local
or remote, starts listening on it for messages (and is thus
called an rpmsg server).
When that happens, a "name service" announcement is sent
to the other processor, in order to let it know about the
creation of the channel (this way remote clients know they
can start sending messages).
This sysfs entry tells us whether the channel is a local
server channel that is announced (values are either
true or false).

28
Documentation/ABI/testing/sysfs-bus-umc Normal file
View file

@ -0,0 +1,28 @@
What: /sys/bus/umc/
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The Wireless Host Controller Interface (WHCI)
specification describes a PCI-based device with
multiple capabilities; the UWB Multi-interface
Controller (UMC).
The umc bus presents each of the individual
capabilties as a device.
What: /sys/bus/umc/devices/.../capability_id
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The ID of this capability, with 0 being the radio
controller capability.
What: /sys/bus/umc/devices/.../version
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The specification version this capability's hardware
interface complies with.

182
Documentation/ABI/testing/sysfs-bus-usb Normal file
View file

@ -0,0 +1,182 @@
What: /sys/bus/usb/device/.../authorized
Date: July 2008
KernelVersion: 2.6.26
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Authorized devices are available for use by device
drivers, non-authorized one are not. By default, wired
USB devices are authorized.
Certified Wireless USB devices are not authorized
initially and should be (by writing 1) after the
device has been authenticated.
What: /sys/bus/usb/device/.../wusb_cdid
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
A devices's CDID, as 16 space-separated hex octets.
What: /sys/bus/usb/device/.../wusb_ck
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
Write the device's connection key (CK) to start the
authentication of the device. The CK is 16
space-separated hex octets.
What: /sys/bus/usb/device/.../wusb_disconnect
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).
What: /sys/bus/usb/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
Description:
Writing a device ID to this file will attempt to
dynamically add a new device ID to a USB device driver.
This may allow the driver to support more hardware than
was included in the driver's static device ID support
table at compile time. The format for the device ID is:
idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct
The vendor ID and device ID fields are required, the
rest is optional. The Ref* tuple can be used to tell the
driver to use the same driver_data for the new device as
it is used for the reference device.
Upon successfully adding an ID, the driver will probe
for the device and attempt to bind to it. For example:
# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
Here add a new device (0458:7045) using driver_data from
an already supported device (0458:704c):
# echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id
Reading from this file will list all dynamically added
device IDs in the same format, with one entry per
line. For example:
# cat /sys/bus/usb/drivers/foo/new_id
8086 10f5
dead beef 06
f00d cafe
The list will be truncated at PAGE_SIZE bytes due to
sysfs restrictions.
What: /sys/bus/usb-serial/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
Description:
For serial USB drivers, this attribute appears under the
extra bus folder "usb-serial" in sysfs; apart from that
difference, all descriptions from the entry
"/sys/bus/usb/drivers/.../new_id" apply.
What: /sys/bus/usb/drivers/.../remove_id
Date: November 2009
Contact: CHENG Renquan <rqcheng@smu.edu.sg>
Description:
Writing a device ID to this file will remove an ID
that was dynamically added via the new_id sysfs entry.
The format for the device ID is:
idVendor idProduct. After successfully
removing an ID, the driver will no longer support the
device. This is useful to ensure auto probing won't
match the driver to the device. For example:
# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
Reading from this file will list the dynamically added
device IDs, exactly like reading from the entry
"/sys/bus/usb/drivers/.../new_id"
What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
is plugged in to a xHCI host which support link PM, it will
perform a LPM test; if the test is passed and host supports
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
be enabled for the device and the USB device directory will
contain a file named power/usb2_hardware_lpm. The file holds
a string value (enable or disable) indicating whether or not
USB2 hardware LPM is enabled for the device. Developer can
write y/Y/1 or n/N/0 to the file to enable/disable the
feature.
What: /sys/bus/usb/devices/.../removable
Date: February 2012
Contact: Matthew Garrett <mjg@redhat.com>
Description:
Some information about whether a given USB device is
physically fixed to the platform can be inferred from a
combination of hub descriptor bits and platform-specific data
such as ACPI. This file will read either "removable" or
"fixed" if the information is available, and "unknown"
otherwise.
What: /sys/bus/usb/devices/.../ltm_capable
Date: July 2012
Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Description:
USB 3.0 devices may optionally support Latency Tolerance
Messaging (LTM). They indicate their support by setting a bit
in the bmAttributes field of their SuperSpeed BOS descriptors.
If that bit is set for the device, ltm_capable will read "yes".
If the device doesn't support LTM, the file will read "no".
The file will be present for all speeds of USB devices, and will
always read "no" for USB 1.1 and USB 2.0 devices.
What: /sys/bus/usb/devices/.../(hub interface)/portX
Date: August 2012
Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
The /sys/bus/usb/devices/.../(hub interface)/portX
is usb port device's sysfs directory.
What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type
Date: January 2013
Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
Some platforms provide usb port connect types through ACPI.
This attribute is to expose these information to user space.
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.
What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
Date: May 2013
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
USB 2.0 devices may support hardware link power management (LPM)
L1 sleep state. The usb2_lpm_l1_timeout attribute allows
tuning the timeout for L1 inactivity timer (LPM timer), e.g.
needed inactivity time before host requests the device to go to L1 sleep.
Useful for power management tuning.
Supported values are 0 - 65535 microseconds.
What: /sys/bus/usb/devices/.../power/usb2_lpm_besl
Date: May 2013
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
USB 2.0 devices that support hardware link power management (LPM)
L1 sleep state now use a best effort service latency value (BESL) to
indicate the best effort to resumption of service to the device after the
initiation of the resume event.
If the device does not have a preferred besl value then the host can select
one instead. This usb2_lpm_besl attribute allows to tune the host selected besl
value in order to tune power saving and service latency.
Supported values are 0 - 15.
More information on how besl values map to microseconds can be found in
USB 2.0 ECN Errata for Link Power Management, section 4.10)

43
Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg Normal file
View file

@ -0,0 +1,43 @@
Where: /sys/bus/usb/.../powered
Date: August 2008
Kernel Version: 2.6.26
Contact: Harrison Metzger <harrisonmetz@gmail.com>
Description: Controls whether the device's display will powered.
A value of 0 is off and a non-zero value is on.
Where: /sys/bus/usb/.../mode_msb
Where: /sys/bus/usb/.../mode_lsb
Date: August 2008
Kernel Version: 2.6.26
Contact: Harrison Metzger <harrisonmetz@gmail.com>
Description: Controls the devices display mode.
For a 6 character display the values are
MSB 0x06; LSB 0x3F, and
for an 8 character display the values are
MSB 0x08; LSB 0xFF.
Where: /sys/bus/usb/.../textmode
Date: August 2008
Kernel Version: 2.6.26
Contact: Harrison Metzger <harrisonmetz@gmail.com>
Description: Controls the way the device interprets its text buffer.
raw: each character controls its segment manually
hex: each character is between 0-15
ascii: each character is between '0'-'9' and 'A'-'F'.
Where: /sys/bus/usb/.../text
Date: August 2008
Kernel Version: 2.6.26
Contact: Harrison Metzger <harrisonmetz@gmail.com>
Description: The text (or data) for the device to display
Where: /sys/bus/usb/.../decimals
Date: August 2008
Kernel Version: 2.6.26
Contact: Harrison Metzger <harrisonmetz@gmail.com>
Description: Controls the decimal places on the device.
To set the nth decimal place, give this field
the value of 10 ** n. Assume this field has
the value k and has 1 or more decimal places set,
to set the mth place (where m is not already set),
change this fields value to k + 10 ** m.

47
Documentation/ABI/testing/sysfs-bus-usb-lvstest Normal file
View file

@ -0,0 +1,47 @@
Link Layer Validation Device is a standard device for testing of Super
Speed Link Layer tests. These nodes are available in sysfs only when lvs
driver is bound with root hub device.
What: /sys/bus/usb/devices/.../get_dev_desc
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "Get Device Descriptor"
for Link Layer Validation device. It is needed for TD.7.06.
What: /sys/bus/usb/devices/.../u1_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Set "U1 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.
What: /sys/bus/usb/devices/.../u2_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Set "U2 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.
What: /sys/bus/usb/devices/.../hot_reset
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "Reset" for Link Layer Validation
device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
What: /sys/bus/usb/devices/.../u3_entry
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "U3 entry" for Link Layer
Validation device. It is needed for TD.7.35 and TD.7.36.
What: /sys/bus/usb/devices/.../u3_exit
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "U3 exit" for Link Layer
Validation device. It is needed for TD.7.36.

88
Documentation/ABI/testing/sysfs-c2port Normal file
View file

@ -0,0 +1,88 @@
What: /sys/class/c2port/
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/ directory will contain files and
directories that will provide a unified interface to
the C2 port interface.
What: /sys/class/c2port/c2portX
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/ directory is related to X-th
C2 port into the system. Each directory will contain files to
manage and control its C2 port.
What: /sys/class/c2port/c2portX/access
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/access file enable the access
to the C2 port from the system. No commands can be sent
till this entry is set to 0.
What: /sys/class/c2port/c2portX/dev_id
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/dev_id file show the device ID
of the connected micro.
What: /sys/class/c2port/c2portX/flash_access
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_access file enable the
access to the on-board flash of the connected micro.
No commands can be sent till this entry is set to 0.
What: /sys/class/c2port/c2portX/flash_block_size
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_block_size file show
the on-board flash block size of the connected micro.
What: /sys/class/c2port/c2portX/flash_blocks_num
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_blocks_num file show
the on-board flash blocks number of the connected micro.
What: /sys/class/c2port/c2portX/flash_data
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_data file export
the content of the on-board flash of the connected micro.
What: /sys/class/c2port/c2portX/flash_erase
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_erase file execute
the "erase" command on the on-board flash of the connected
micro.
What: /sys/class/c2port/c2portX/flash_erase
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_erase file show the
on-board flash size of the connected micro.
What: /sys/class/c2port/c2portX/reset
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/reset file execute a "reset"
command on the connected micro.
What: /sys/class/c2port/c2portX/rev_id
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/rev_id file show the revision ID
of the connected micro.

8
Documentation/ABI/testing/sysfs-cfq-target-latency Normal file
View file

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

16
Documentation/ABI/testing/sysfs-class Normal file
View file

@ -0,0 +1,16 @@
What: /sys/class/
Date: Febuary 2006
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
The /sys/class directory will consist of a group of
subdirectories describing individual classes of devices
in the kernel. The individual directories will consist
of either subdirectories, or symlinks to other
directories.
All programs that use this directory tree must be able
to handle both subdirectories or symlinks in order to
work properly.
Users:
udev <linux-hotplug-devel@lists.sourceforge.net>

56
Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 Normal file
View file

@ -0,0 +1,56 @@
What: /sys/class/backlight/<backlight>/<ambient light zone>_max
What: /sys/class/backlight/<backlight>/l1_daylight_max
What: /sys/class/backlight/<backlight>/l2_bright_max
What: /sys/class/backlight/<backlight>/l3_office_max
What: /sys/class/backlight/<backlight>/l4_indoor_max
What: /sys/class/backlight/<backlight>/l5_dark_max
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the maximum brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127. This file
will also show the brightness level stored for this
<ambient light zone>.
What: /sys/class/backlight/<backlight>/<ambient light zone>_dim
What: /sys/class/backlight/<backlight>/l2_bright_dim
What: /sys/class/backlight/<backlight>/l3_office_dim
What: /sys/class/backlight/<backlight>/l4_indoor_dim
What: /sys/class/backlight/<backlight>/l5_dark_dim
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the dim brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127, typically
set to 0. Full off when the backlight is disabled.
This file will also show the dim brightness level stored for
this <ambient light zone>.
What: /sys/class/backlight/<backlight>/ambient_light_level
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Get conversion value of the light sensor.
This value is updated every 80 ms (when the light sensor
is enabled). Returns integer between 0 (dark) and
8000 (max ambient brightness)
What: /sys/class/backlight/<backlight>/ambient_light_zone
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Get/Set current ambient light zone. Reading returns
integer between 1..5 (1 = daylight, 2 = bright, ..., 5 = dark).
Writing a value between 1..5 forces the backlight controller
to enter the corresponding ambient light zone.
Writing 0 returns to normal/automatic ambient light level
operation. The ambient light sensing feature on these devices
is an extension to the API documented in
Documentation/ABI/stable/sysfs-class-backlight.
It can be enabled by writing the value stored in
/sys/class/backlight/<backlight>/max_brightness to
/sys/class/backlight/<backlight>/brightness.

48
Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 Normal file
View file

@ -0,0 +1,48 @@
What: /sys/class/backlight/<backlight>/als_channel
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the ALS output channel used as input in
ALS-current-control mode (0, 1), where
0 - out_current0 (backlight 0)
1 - out_current1 (backlight 1)
What: /sys/class/backlight/<backlight>/als_en
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Enable ALS-current-control mode (0, 1).
What: /sys/class/backlight/<backlight>/id
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the id of this backlight (0, 1).
What: /sys/class/backlight/<backlight>/linear
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the brightness-mapping mode (0, 1), where
0 - exponential mode
1 - linear mode
What: /sys/class/backlight/<backlight>/pwm
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the PWM-input control mask (5 bits), where
bit 5 - PWM-input enabled in Zone 4
bit 4 - PWM-input enabled in Zone 3
bit 3 - PWM-input enabled in Zone 2
bit 2 - PWM-input enabled in Zone 1
bit 1 - PWM-input enabled in Zone 0
bit 0 - PWM-input enabled

55
Documentation/ABI/testing/sysfs-class-bdi Normal file
View file

@ -0,0 +1,55 @@
What: /sys/class/bdi/<bdi>/
Date: January 2008
Contact: Peter Zijlstra <a.p.zijlstra@chello.nl>
Description:
Provide a place in sysfs for the backing_dev_info object. This allows
setting and retrieving various BDI specific variables.
The <bdi> identifier can be either of the following:
MAJOR:MINOR
Device number for block devices, or value of st_dev on
non-block filesystems which provide their own BDI, such as NFS
and FUSE.
MAJOR:MINOR-fuseblk
Value of st_dev on fuseblk filesystems.
default
The default backing dev, used for non-block device backed
filesystems which do not provide their own BDI.
Files under /sys/class/bdi/<bdi>/
---------------------------------
read_ahead_kb (read-write)
Size of the read-ahead window in kilobytes
min_ratio (read-write)
Under normal circumstances each device is given a part of the
total write-back cache that relates to its current average
writeout speed in relation to the other devices.
The 'min_ratio' parameter allows assigning a minimum
percentage of the write-back cache to a particular device.
For example, this is useful for providing a minimum QoS.
max_ratio (read-write)
Allows limiting a particular device to use not more than the
given percentage of the write-back cache. This is useful in
situations where we want to avoid one device taking all or
most of the write-back cache. For example in case of an NFS
mount that is prone to get stuck, or a FUSE mount which cannot
be trusted to play fair.
stable_pages_required (read-only)
If set, the backing device requires that all pages comprising a write
request must not be changed until writeout is complete.

129
Documentation/ABI/testing/sysfs-class-cxl Normal file
View file

@ -0,0 +1,129 @@
Slave contexts (eg. /sys/class/cxl/afu0.0s):
What: /sys/class/cxl/<afu>/irqs_max
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Decimal value of maximum number of interrupts that can be
requested by userspace. The default on probe is the maximum
that hardware can support (eg. 2037). Write values will limit
userspace applications to that many userspace interrupts. Must
be >= irqs_min.
What: /sys/class/cxl/<afu>/irqs_min
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the minimum number of interrupts that
userspace must request on a CXL_START_WORK ioctl. Userspace may
omit the num_interrupts field in the START_WORK IOCTL to get
this minimum automatically.
What: /sys/class/cxl/<afu>/mmio_size
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the size of the MMIO space that may be mmaped
by userspace.
What: /sys/class/cxl/<afu>/modes_supported
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
List of the modes this AFU supports. One per line.
Valid entries are: "dedicated_process" and "afu_directed"
What: /sys/class/cxl/<afu>/mode
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
The current mode the AFU is using. Will be one of the modes
given in modes_supported. Writing will change the mode
provided that no user contexts are attached.
What: /sys/class/cxl/<afu>/prefault_mode
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Set the mode for prefaulting in segments into the segment table
when performing the START_WORK ioctl. Possible values:
none: No prefaulting (default)
work_element_descriptor: Treat the work element
descriptor as an effective address and
prefault what it points to.
all: all segments process calling START_WORK maps.
What: /sys/class/cxl/<afu>/reset
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 here will reset the AFU provided there are not
contexts active on the AFU.
What: /sys/class/cxl/<afu>/api_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the current version of the kernel/user API.
What: /sys/class/cxl/<afu>/api_version_com
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the the lowest version of the userspace API
this this kernel supports.
Master contexts (eg. /sys/class/cxl/afu0.0m)
What: /sys/class/cxl/<afu>m/mmio_size
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the size of the MMIO space that may be mmaped
by userspace. This includes all slave contexts space also.
What: /sys/class/cxl/<afu>m/pp_mmio_len
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space length.
What: /sys/class/cxl/<afu>m/pp_mmio_off
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space offset.
Card info (eg. /sys/class/cxl/card0)
What: /sys/class/cxl/<card>/caia_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the CAIA Version the card implements.
What: /sys/class/cxl/<card>/psl_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the revision level of the PSL.
What: /sys/class/cxl/<card>/base_image
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the revision level of the base image for devices
that support loadable PSLs. For FPGAs this field identifies
the image contained in the on-adapter flash which is loaded
during the initial program load.
What: /sys/class/cxl/<card>/image_loaded
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Will return "user" or "factory" depending on the image loaded
onto the card.

100
Documentation/ABI/testing/sysfs-class-devfreq Normal file
View file

@ -0,0 +1,100 @@
What: /sys/class/devfreq/.../
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
Provide a place in sysfs for the devfreq objects.
This allows accessing various devfreq specific variables.
The name of devfreq object denoted as ... is same as the
name of device using devfreq.
What: /sys/class/devfreq/.../governor
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../governor show or set the name of the
governor used by the corresponding devfreq object.
What: /sys/class/devfreq/.../cur_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../cur_freq shows the current
frequency of the corresponding devfreq object. Same as
target_freq when get_cur_freq() is not implemented by
devfreq driver.
What: /sys/class/devfreq/.../target_freq
Date: September 2012
Contact: Rajagopal Venkat <rajagopal.venkat@linaro.org>
Description:
The /sys/class/devfreq/.../target_freq shows the next governor
predicted target frequency of the corresponding devfreq object.
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../polling_interval shows and sets
the requested polling interval of the corresponding devfreq
object. The values are represented in ms. If the value is
less than 1 jiffy, it is considered to be 0, which means
no polling. This value is meaningless if the governor is
not polling; thus. If the governor is not using
devfreq-provided central polling
(/sys/class/devfreq/.../central_polling is 0), this value
may be useless.
What: /sys/class/devfreq/.../trans_stat
Date: October 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Descrtiption:
This ABI shows the statistics of devfreq behavior on a
specific device. It shows the time spent in each state and
the number of transitions between states.
In order to activate this ABI, the devfreq target device
driver should provide the list of available frequencies
with its profile.
What: /sys/class/devfreq/.../userspace/set_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../userspace/set_freq shows and
sets the requested frequency for the devfreq object if
userspace governor is in effect.
What: /sys/class/devfreq/.../available_frequencies
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
Description:
The /sys/class/devfreq/.../available_frequencies shows
the available frequencies of the corresponding devfreq object.
This is a snapshot of available frequencies and not limited
by the min/max frequency restrictions.
What: /sys/class/devfreq/.../available_governors
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
Description:
The /sys/class/devfreq/.../available_governors shows
currently available governors in the system.
What: /sys/class/devfreq/.../min_freq
Date: January 2013
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../min_freq shows and stores
the minimum frequency requested by users. It is 0 if
the user does not care. min_freq overrides the
frequency requested by governors.
What: /sys/class/devfreq/.../max_freq
Date: January 2013
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../max_freq shows and stores
the maximum frequency requested by users. It is 0 if
the user does not care. max_freq overrides the
frequency requested by governors and min_freq.
The max_freq overrides min_freq because max_freq may be
used to throttle devices to avoid overheating.

97
Documentation/ABI/testing/sysfs-class-extcon Normal file
View file

@ -0,0 +1,97 @@
What: /sys/class/extcon/.../
Date: February 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
Provide a place in sysfs for the extcon objects.
This allows accessing extcon specific variables.
The name of extcon object denoted as ... is the name given
with extcon_dev_register.
One extcon device denotes a single external connector
port. An external connector may have multiple cables
attached simultaneously. Many of docks, cradles, and
accessory cables have such capability. For example,
the 30-pin port of Nuri board (/arch/arm/mach-exynos)
may have both HDMI and Charger attached, or analog audio,
video, and USB cables attached simultaneously.
If there are cables mutually exclusive with each other,
such binary relations may be expressed with extcon_dev's
mutually_exclusive array.
What: /sys/class/extcon/.../name
Date: February 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/extcon/.../name shows the name of the extcon
object. If the extcon object has an optional callback
"show_name" defined, the callback will provide the name with
this sysfs node.
What: /sys/class/extcon/.../state
Date: February 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/extcon/.../state shows and stores the cable
attach/detach information of the corresponding extcon object.
If the extcon object has an optional callback "show_state"
defined, the showing function is overridden with the optional
callback.
If the default callback for showing function is used, the
format is like this:
# cat state
USB_OTG=1
HDMI=0
TA=1
EAR_JACK=0
#
In this example, the extcon device has USB_OTG and TA
cables attached and HDMI and EAR_JACK cables detached.
In order to update the state of an extcon device, enter a hex
state number starting with 0x:
# echo 0xHEX > state
This updates the whole state of the extcon device.
Inputs of all the methods are required to meet the
mutually_exclusive conditions if they exist.
It is recommended to use this "global" state interface if
you need to set the value atomically. The later state
interface associated with each cable cannot update
multiple cable states of an extcon device simultaneously.
What: /sys/class/extcon/.../cable.x/name
Date: February 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/extcon/.../cable.x/name shows the name of cable
"x" (integer between 0 and 31) of an extcon device.
What: /sys/class/extcon/.../cable.x/state
Date: February 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/extcon/.../cable.x/state shows and stores the
state of cable "x" (integer between 0 and 31) of an extcon
device. The state value is either 0 (detached) or 1
(attached).
What: /sys/class/extcon/.../mutually_exclusive/...
Date: December 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
Shows the relations of mutually exclusiveness. For example,
if the mutually_exclusive array of extcon device is
{0x3, 0x5, 0xC, 0x0}, then the output is:
# ls mutually_exclusive/
0x3
0x5
0xc
#
Note that mutually_exclusive is a sub-directory of the extcon
device and the file names under the mutually_exclusive
directory show the mutually-exclusive sets, not the contents
of the files.

17
Documentation/ABI/testing/sysfs-class-iommu Normal file
View file

@ -0,0 +1,17 @@
What: /sys/class/iommu/<iommu>/devices/
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU drivers are able to link devices managed by a
given IOMMU here to allow association of IOMMU to
device.
What: /sys/devices/.../iommu
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU drivers are able to link the IOMMU for a
given device here to allow association of device to
IOMMU.

14
Documentation/ABI/testing/sysfs-class-iommu-amd-iommu Normal file
View file

@ -0,0 +1,14 @@
What: /sys/class/iommu/<iommu>/amd-iommu/cap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU capability header as documented in the AMD IOMMU
specification. Format: %x
What: /sys/class/iommu/<iommu>/amd-iommu/features
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
Extended features of the IOMMU. Format: %llx

32
Documentation/ABI/testing/sysfs-class-iommu-intel-iommu Normal file
View file

@ -0,0 +1,32 @@
What: /sys/class/iommu/<iommu>/intel-iommu/address
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
Physical address of the VT-d DRHD for this IOMMU.
Format: %llx. This allows association of a sysfs
intel-iommu with a DMAR DRHD table entry.
What: /sys/class/iommu/<iommu>/intel-iommu/cap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The cached hardware capability register value
of this DRHD unit. Format: %llx.
What: /sys/class/iommu/<iommu>/intel-iommu/ecap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The cached hardware extended capability register
value of this DRHD unit. Format: %llx.
What: /sys/class/iommu/<iommu>/intel-iommu/version
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The architecture version as reported from the
VT-d VER_REG. Format: %d:%d, major:minor

23
Documentation/ABI/testing/sysfs-class-lcd Normal file
View file

@ -0,0 +1,23 @@
What: /sys/class/lcd/<lcd>/lcd_power
Date: April 2005
KernelVersion: 2.6.12
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Control LCD power, values are FB_BLANK_* from fb.h
- FB_BLANK_UNBLANK (0) : power on.
- FB_BLANK_POWERDOWN (4) : power off
What: /sys/class/lcd/<lcd>/contrast
Date: April 2005
KernelVersion: 2.6.12
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Current contrast of this LCD device. Value is between 0 and
/sys/class/lcd/<lcd>/max_contrast.
What: /sys/class/lcd/<lcd>/max_contrast
Date: April 2005
KernelVersion: 2.6.12
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Maximum contrast for this LCD device.

37
Documentation/ABI/testing/sysfs-class-led Normal file
View file

@ -0,0 +1,37 @@
What: /sys/class/leds/<led>/brightness
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Set the brightness of the LED. Most LEDs don't
have hardware brightness support so will just be turned on for
non-zero brightness settings. The value is between 0 and
/sys/class/leds/<led>/max_brightness.
What: /sys/class/leds/<led>/max_brightness
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Maximum brightness level for this led, default is 255 (LED_FULL).
What: /sys/class/leds/<led>/trigger
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Set the trigger for this LED. A trigger is a kernel based source
of led events.
You can change triggers in a similar manner to the way an IO
scheduler is chosen. Trigger specific parameters can appear in
/sys/class/leds/<led> once a given trigger is selected.
What: /sys/class/leds/<led>/inverted
Date: January 2011
KernelVersion: 2.6.38
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Invert the LED on/off state. This parameter is specific to
gpio and backlight triggers. In case of the backlight trigger,
it is useful when driving a LED which is intended to indicate
a device in a standby like state.

65
Documentation/ABI/testing/sysfs-class-led-driver-lm3533 Normal file
View file

@ -0,0 +1,65 @@
What: /sys/class/leds/<led>/als_channel
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the ALS output channel to use as input in
ALS-current-control mode (1, 2), where
1 - out_current1
2 - out_current2
What: /sys/class/leds/<led>/als_en
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Enable ALS-current-control mode (0, 1).
What: /sys/class/leds/<led>/falltime
What: /sys/class/leds/<led>/risetime
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the pattern generator fall and rise times (0..7), where
0 - 2048 us
1 - 262 ms
2 - 524 ms
3 - 1.049 s
4 - 2.097 s
5 - 4.194 s
6 - 8.389 s
7 - 16.78 s
What: /sys/class/leds/<led>/id
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the id of this led (0..3).
What: /sys/class/leds/<led>/linear
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the brightness-mapping mode (0, 1), where
0 - exponential mode
1 - linear mode
What: /sys/class/leds/<led>/pwm
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the PWM-input control mask (5 bits), where
bit 5 - PWM-input enabled in Zone 4
bit 4 - PWM-input enabled in Zone 3
bit 3 - PWM-input enabled in Zone 2
bit 2 - PWM-input enabled in Zone 1
bit 1 - PWM-input enabled in Zone 0
bit 0 - PWM-input enabled

16
Documentation/ABI/testing/sysfs-class-leds-gt683r Normal file
View file

@ -0,0 +1,16 @@
What: /sys/class/leds/<led>/gt683r/mode
Date: Jun 2014
KernelVersion: 3.17
Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
Description:
Set the mode of LEDs. You should notice that changing the mode
of one LED will update the mode of its two sibling devices as
well.
0 - normal
1 - audio
2 - breathing
Normal: LEDs are fully on when enabled
Audio: LEDs brightness depends on sound level
Breathing: LEDs brightness varies at human breathing rate

16
Documentation/ABI/testing/sysfs-class-mei Normal file
View file

@ -0,0 +1,16 @@
What: /sys/class/mei/
Date: May 2014
KernelVersion: 3.17
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description:
The mei/ class sub-directory belongs to mei device class
What: /sys/class/mei/meiN/
Date: May 2014
KernelVersion: 3.17
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description:
The /sys/class/mei/meiN directory is created for
each probed mei device

157
Documentation/ABI/testing/sysfs-class-mic.txt Normal file
View file

@ -0,0 +1,157 @@
What: /sys/class/mic/
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
The mic class directory belongs to Intel MIC devices and
provides information per MIC device. An Intel MIC device is a
PCIe form factor add-in Coprocessor card based on the Intel Many
Integrated Core (MIC) architecture that runs a Linux OS.
What: /sys/class/mic/mic(x)
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
The directories /sys/class/mic/mic0, /sys/class/mic/mic1 etc.,
represent MIC devices (0,1,..etc). Each directory has
information specific to that MIC device.
What: /sys/class/mic/mic(x)/family
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
Provides information about the Coprocessor family for an Intel
MIC device. For example - "x100"
What: /sys/class/mic/mic(x)/stepping
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
Provides information about the silicon stepping for an Intel
MIC device. For example - "A0" or "B0"
What: /sys/class/mic/mic(x)/state
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this entry provides the current state of an Intel
MIC device in the context of the card OS. Possible values that
will be read are:
"offline" - The MIC device is ready to boot the card OS. On
reading this entry after an OSPM resume, a "boot" has to be
written to this entry if the card was previously shutdown
during OSPM suspend.
"online" - The MIC device has initiated booting a card OS.
"shutting_down" - The card OS is shutting down.
"reset_failed" - The MIC device has failed to reset.
"suspending" - The MIC device is currently being prepared for
suspend. On reading this entry, a "suspend" has to be written
to the state sysfs entry to ensure the card is shutdown during
OSPM suspend.
"suspended" - The MIC device has been suspended.
When written, this sysfs entry triggers different state change
operations depending upon the current state of the card OS.
Acceptable values are:
"boot" - Boot the card OS image specified by the combination
of firmware, ramdisk, cmdline and bootmode
sysfs entries.
"reset" - Initiates device reset.
"shutdown" - Initiates card OS shutdown.
"suspend" - Initiates card OS shutdown and also marks the card
as suspended.
What: /sys/class/mic/mic(x)/shutdown_status
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. This
OS can shutdown because of various reasons. When read, this
entry provides the status on why the card OS was shutdown.
Possible values are:
"nop" - shutdown status is not applicable, when the card OS is
"online"
"crashed" - Shutdown because of a HW or SW crash.
"halted" - Shutdown because of a halt command.
"poweroff" - Shutdown because of a poweroff command.
"restart" - Shutdown because of a restart command.
What: /sys/class/mic/mic(x)/cmdline
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. Before
booting this card OS, it is possible to pass kernel command line
options to configure various features in it, similar to
self-bootable machines. When read, this entry provides
information about the current kernel command line options set to
boot the card OS. This entry can be written to change the
existing kernel command line options. Typically, the user would
want to read the current command line options, append new ones
or modify existing ones and then write the whole kernel command
line back to this entry.
What: /sys/class/mic/mic(x)/firmware
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this sysfs entry provides the path name under
/lib/firmware/ where the firmware image to be booted on the
card can be found. The entry can be written to change the
firmware image location under /lib/firmware/.
What: /sys/class/mic/mic(x)/ramdisk
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this sysfs entry provides the path name under
/lib/firmware/ where the ramdisk image to be used during card
OS boot can be found. The entry can be written to change
the ramdisk image location under /lib/firmware/.
What: /sys/class/mic/mic(x)/bootmode
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this sysfs entry provides the current bootmode for
the card. This sysfs entry can be written with the following
valid strings:
a) linux - Boot a Linux image.
b) elf - Boot an elf image for flash updates.
What: /sys/class/mic/mic(x)/log_buf_addr
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. For
debugging purpose and early kernel boot messages, the user can
access the card OS log buffer via debugfs. When read, this entry
provides the kernel virtual address of the buffer where the card
OS log buffer can be read. This entry is written by the host
configuration daemon to set the log buffer address. The correct
log buffer address to be written can be found in the System.map
file of the card OS.
What: /sys/class/mic/mic(x)/log_buf_len
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. For
debugging purpose and early kernel boot messages, the user can
access the card OS log buffer via debugfs. When read, this entry
provides the kernel virtual address where the card OS log buffer
length can be read. This entry is written by host configuration
daemon to set the log buffer length address. The correct log
buffer length address to be written can be found in the
System.map file of the card OS.

224
Documentation/ABI/testing/sysfs-class-mtd Normal file
View file

@ -0,0 +1,224 @@
What: /sys/class/mtd/
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
The mtd/ class subdirectory belongs to the MTD subsystem
(MTD core).
What: /sys/class/mtd/mtdX/
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
to each /dev/mtdX character device. These may represent
physical/simulated flash devices, partitions on a flash
device, or concatenated flash devices.
What: /sys/class/mtd/mtdXro/
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
These directories provide the corresponding read-only device
nodes for /sys/class/mtd/mtdX/ .
What: /sys/class/mtd/mtdX/dev
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
Major and minor numbers of the character device corresponding
to this MTD device (in <major>:<minor> format). This is the
read-write device so <minor> will be even.
What: /sys/class/mtd/mtdXro/dev
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
Major and minor numbers of the character device corresponding
to the read-only variant of thie MTD device (in
<major>:<minor> format). In this case <minor> will be odd.
What: /sys/class/mtd/mtdX/erasesize
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
"Major" erase size for the device. If numeraseregions is
zero, this is the eraseblock size for the entire device.
Otherwise, the MEMGETREGIONCOUNT/MEMGETREGIONINFO ioctls
can be used to determine the actual eraseblock layout.
What: /sys/class/mtd/mtdX/flags
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
A hexadecimal value representing the device flags, ORed
together:
0x0400: MTD_WRITEABLE - device is writable
0x0800: MTD_BIT_WRITEABLE - single bits can be flipped
0x1000: MTD_NO_ERASE - no erase necessary
0x2000: MTD_POWERUP_LOCK - always locked after reset
What: /sys/class/mtd/mtdX/name
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
A human-readable ASCII name for the device or partition.
This will match the name in /proc/mtd .
What: /sys/class/mtd/mtdX/numeraseregions
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
For devices that have variable eraseblock sizes, this
provides the total number of erase regions. Otherwise,
it will read back as zero.
What: /sys/class/mtd/mtdX/oobsize
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
Number of OOB bytes per page.
What: /sys/class/mtd/mtdX/size
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
Total size of the device/partition, in bytes.
What: /sys/class/mtd/mtdX/type
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
One of the following ASCII strings, representing the device
type:
absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
What: /sys/class/mtd/mtdX/writesize
Date: April 2009
KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
Minimal writable flash unit size. This will always be
a positive integer.
In the case of NOR flash it is 1 (even though individual
bits can be cleared).
In the case of NAND flash it is one NAND page (or a
half page, or a quarter page).
In the case of ECC NOR, it is the ECC block size.
What: /sys/class/mtd/mtdX/ecc_strength
Date: April 2012
KernelVersion: 3.4
Contact: linux-mtd@lists.infradead.org
Description:
Maximum number of bit errors that the device is capable of
correcting within each region covering an ECC step (see
ecc_step_size). This will always be a non-negative integer.
In the case of devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/bitflip_threshold
Date: April 2012
KernelVersion: 3.4
Contact: linux-mtd@lists.infradead.org
Description:
This allows the user to examine and adjust the criteria by which
mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the
maximum number of bit errors that were corrected on any single
region comprising an ecc step (as reported by the driver) equals
or exceeds this value, -EUCLEAN is returned. Otherwise, absent
an error, 0 is returned. Higher layers (e.g., UBI) use this
return code as an indication that an erase block may be
degrading and should be scrutinized as a candidate for being
marked as bad.
The initial value may be specified by the flash device driver.
If not, then the default value is ecc_strength.
The introduction of this feature brings a subtle change to the
meaning of the -EUCLEAN return code. Previously, it was
interpreted to mean simply "one or more bit errors were
corrected". Its new interpretation can be phrased as "a
dangerously high number of bit errors were corrected on one or
more regions comprising an ecc step". The precise definition of
"dangerously high" can be adjusted by the user with
bitflip_threshold. Users are discouraged from doing this,
however, unless they know what they are doing and have intimate
knowledge of the properties of their device. Broadly speaking,
bitflip_threshold should be low enough to detect genuine erase
block degradation, but high enough to avoid the consequences of
a persistent return value of -EUCLEAN on devices where sticky
bitflips occur. Note that if bitflip_threshold exceeds
ecc_strength, -EUCLEAN is never returned by the read operations.
Conversely, if bitflip_threshold is zero, -EUCLEAN is always
returned, absent a hard error.
This is generally applicable only to NAND flash devices with ECC
capability. It is ignored on devices lacking ECC capability;
i.e., devices for which ecc_strength is zero.
What: /sys/class/mtd/mtdX/ecc_step_size
Date: May 2013
KernelVersion: 3.10
Contact: linux-mtd@lists.infradead.org
Description:
The size of a single region covered by ECC, known as the ECC
step. Devices may have several equally sized ECC steps within
each writesize region.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/ecc_failures
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of failures reported by this device's ECC. Typically,
these failures are associated with failed read operations.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/corrected_bits
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of bits that have been corrected by means of the
device's ECC.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/bad_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks marked as bad, if any, in this partition.
What: /sys/class/mtd/mtdX/bbt_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks that are marked as reserved, if any, in
this partition. These are typically used to store the in-flash
bad block table (BBT).

218
Documentation/ABI/testing/sysfs-class-net Normal file
View file

@ -0,0 +1,218 @@
What: /sys/class/net/<iface>/name_assign_type
Date: July 2014
KernelVersion: 3.17
Contact: netdev@vger.kernel.org
Description:
Indicates the name assignment type. Possible values are:
1: enumerated by the kernel, possibly in an unpredictable way
2: predictably named by the kernel
3: named by userspace
4: renamed
What: /sys/class/net/<iface>/addr_assign_type
Date: July 2010
KernelVersion: 3.2
Contact: netdev@vger.kernel.org
Description:
Indicates the address assignment type. Possible values are:
0: permanent address
1: randomly generated
2: stolen from another device
3: set using dev_set_mac_address
What: /sys/class/net/<iface>/addr_len
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the hardware address size in bytes.
Values vary based on the lower-level protocol used by the
interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See
include/uapi/linux/if_*.h for actual values.
What: /sys/class/net/<iface>/address
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Hardware address currently assigned to this interface.
Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
address.
What: /sys/class/net/<iface>/broadcast
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Hardware broadcast address for this interface. Format is a
string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC
address.
What: /sys/class/net/<iface>/carrier
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the current physical link state of the interface.
Posssible values are:
0: physical link is down
1: physical link is up
Note: some special devices, e.g: bonding and team drivers will
allow this attribute to be written to force a link state for
operating correctly and designating another fallback interface.
What: /sys/class/net/<iface>/dev_id
Date: April 2008
KernelVersion: 2.6.26
Contact: netdev@vger.kernel.org
Description:
Indicates the device unique identifier. Format is an hexadecimal
value. This is used to disambiguate interfaces which might be
stacked (e.g: VLAN interfaces) but still have the same MAC
address as their parent device.
What: /sys/class/net/<iface>/dormant
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates whether the interface is in dormant state. Possible
values are:
0: interface is not dormant
1: interface is dormant
This attribute can be used by supplicant software to signal that
the device is not usable unless some supplicant-based
authentication is performed (e.g: 802.1x). 'link_mode' attribute
will also reflect the dormant state.
What: /sys/clas/net/<iface>/duplex
Date: October 2009
KernelVersion: 2.6.33
Contact: netdev@vger.kernel.org
Description:
Indicates the interface latest or current duplex value. Possible
values are:
half: half duplex
full: full duplex
Note: This attribute is only valid for interfaces that implement
the ethtool get_settings method (mostly Ethernet).
What: /sys/class/net/<iface>/flags
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface flags as a bitmask in hexadecimal. See
include/uapi/linux/if.h for a list of all possible values and
the flags semantics.
What: /sys/class/net/<iface>/ifalias
Date: September 2008
KernelVersion: 2.6.28
Contact: netdev@vger.kernel.org
Description:
Indicates/stores an interface alias name as a string. This can
be used for system management purposes.
What: /sys/class/net/<iface>/ifindex
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the system-wide interface unique index identifier as a
decimal number. This attribute is used for mapping an interface
identifier to an interface name. It is used throughout the
networking stack for specifying the interface specific
requests/events.
What: /sys/class/net/<iface>/iflink
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the system-wide interface unique index identifier a
the interface is linked to. Format is decimal. This attribute is
used to resolve interfaces chaining, linking and stacking.
Physical interfaces have the same 'ifindex' and 'iflink' values.
What: /sys/class/net/<iface>/link_mode
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates the interface link mode, as a decimal number. This
attribute should be used in conjunction with 'dormant' attribute
to determine the interface usability. Possible values:
0: default link mode
1: dormant link mode
What: /sys/class/net/<iface>/mtu
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface currently configured MTU value, in
bytes, and in decimal format. Specific values depends on the
lower-level interface protocol used. Ethernet devices will show
a 'mtu' attribute value of 1500 unless changed.
What: /sys/class/net/<iface>/netdev_group
Date: January 2011
KernelVersion: 2.6.39
Contact: netdev@vger.kernel.org
Description:
Indicates the interface network device group, as a decimal
integer. Default value is 0 which corresponds to the initial
network devices group. The group can be changed to affect
routing decisions (see: net/ipv4/fib_rules and
net/ipv6/fib6_rules.c).
What: /sys/class/net/<iface>/operstate
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates the interface RFC2863 operational state as a string.
Possible values are:
"unknown", "notpresent", "down", "lowerlayerdown", "testing",
"dormant", "up".
What: /sys/class/net/<iface>/phys_port_id
Date: July 2013
KernelVersion: 3.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface unique physical port identifier within
the NIC, as a string.
What: /sys/class/net/<iface>/speed
Date: October 2009
KernelVersion: 2.6.33
Contact: netdev@vger.kernel.org
Description:
Indicates the interface latest or current speed value. Value is
an integer representing the link speed in Mbits/sec.
Note: this attribute is only valid for interfaces that implement
the ethtool get_settings method (mostly Ethernet ).
What: /sys/class/net/<iface>/tx_queue_len
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface transmit queue len in number of packets,
as an integer value. Value depend on the type of interface,
Ethernet network adapters have a default value of 1000 unless
configured otherwise
What: /sys/class/net/<iface>/type
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface protocol type as a decimal value. See
include/uapi/linux/if_arp.h for all possible values.

15
Documentation/ABI/testing/sysfs-class-net-batman-adv Normal file
View file

@ -0,0 +1,15 @@
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates the status of <iface> as it is seen by batman.
What: /sys/class/net/<iface>/batman-adv/mesh_iface
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>
currently is associated with.

149
Documentation/ABI/testing/sysfs-class-net-cdc_ncm Normal file
View file

@ -0,0 +1,149 @@
What: /sys/class/net/<iface>/cdc_ncm/min_tx_pkt
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
The driver will pad NCM Transfer Blocks (NTBs) longer
than this to tx_max, allowing the device to receive
tx_max sized frames with no terminating short
packet. NTBs shorter than this limit are transmitted
as-is, without any padding, and are terminated with a
short USB packet.
Padding to tx_max allows the driver to transmit NTBs
back-to-back without any interleaving short USB
packets. This reduces the number of short packet
interrupts in the device, and represents a tradeoff
between USB bus bandwidth and device DMA optimization.
Set to 0 to pad all frames. Set greater than tx_max to
disable all padding.
What: /sys/class/net/<iface>/cdc_ncm/rx_max
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
The maximum NTB size for RX. Cannot exceed the
maximum value supported by the device. Must allow at
least one max sized datagram plus headers.
The actual limits are device dependent. See
dwNtbInMaxSize.
Note: Some devices will silently ignore changes to
this value, resulting in oversized NTBs and
corresponding framing errors.
What: /sys/class/net/<iface>/cdc_ncm/tx_max
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
The maximum NTB size for TX. Cannot exceed the
maximum value supported by the device. Must allow at
least one max sized datagram plus headers.
The actual limits are device dependent. See
dwNtbOutMaxSize.
What: /sys/class/net/<iface>/cdc_ncm/tx_timer_usecs
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Datagram aggregation timeout in µs. The driver will
wait up to 3 times this timeout for more datagrams to
aggregate before transmitting an NTB frame.
Valid range: 5 to 4000000
Set to 0 to disable aggregation.
The following read-only attributes all represent fields of the
structure defined in section 6.2.1 "GetNtbParameters" of "Universal
Serial Bus Communications Class Subclass Specifications for Network
Control Model Devices" (CDC NCM), Revision 1.0 (Errata 1), November
24, 2010 from USB Implementers Forum, Inc. The descriptions are
quoted from table 6-3 of CDC NCM: "NTB Parameter Structure".
What: /sys/class/net/<iface>/cdc_ncm/bmNtbFormatsSupported
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Bit 0: 16-bit NTB supported (set to 1)
Bit 1: 32-bit NTB supported
Bits 2 – 15: reserved (reset to zero; must be ignored by host)
What: /sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
IN NTB Maximum Size in bytes
What: /sys/class/net/<iface>/cdc_ncm/wNdpInDivisor
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Divisor used for IN NTB Datagram payload alignment
What: /sys/class/net/<iface>/cdc_ncm/wNdpInPayloadRemainder
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Remainder used to align input datagram payload within
the NTB: (Payload Offset) mod (wNdpInDivisor) =
wNdpInPayloadRemainder
What: /sys/class/net/<iface>/cdc_ncm/wNdpInAlignment
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
NDP alignment modulus for NTBs on the IN pipe. Shall
be a power of 2, and shall be at least 4.
What: /sys/class/net/<iface>/cdc_ncm/dwNtbOutMaxSize
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
OUT NTB Maximum Size
What: /sys/class/net/<iface>/cdc_ncm/wNdpOutDivisor
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
OUT NTB Datagram alignment modulus
What: /sys/class/net/<iface>/cdc_ncm/wNdpOutPayloadRemainder
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Remainder used to align output datagram payload
offsets within the NTB: Padding, shall be transmitted
as zero by function, and ignored by host. (Payload
Offset) mod (wNdpOutDivisor) = wNdpOutPayloadRemainder
What: /sys/class/net/<iface>/cdc_ncm/wNdpOutAlignment
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
NDP alignment modulus for use in NTBs on the OUT
pipe. Shall be a power of 2, and shall be at least 4.
What: /sys/class/net/<iface>/cdc_ncm/wNtbOutMaxDatagrams
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Maximum number of datagrams that the host may pack
into a single OUT NTB. Zero means that the device
imposes no limit.

35
Documentation/ABI/testing/sysfs-class-net-grcan Normal file
View file

@ -0,0 +1,35 @@
What: /sys/class/net/<iface>/grcan/enable0
Date: October 2012
KernelVersion: 3.8
Contact: Andreas Larsson <andreas@gaisler.com>
Description:
Hardware configuration of physical interface 0. This file reads
and writes the "Enable 0" bit of the configuration register.
Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP
core library documentation for details. The default value is 0
or set by the module parameter grcan.enable0 and can be read at
/sys/module/grcan/parameters/enable0.
What: /sys/class/net/<iface>/grcan/enable1
Date: October 2012
KernelVersion: 3.8
Contact: Andreas Larsson <andreas@gaisler.com>
Description:
Hardware configuration of physical interface 1. This file reads
and writes the "Enable 1" bit of the configuration register.
Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP
core library documentation for details. The default value is 0
or set by the module parameter grcan.enable1 and can be read at
/sys/module/grcan/parameters/enable1.
What: /sys/class/net/<iface>/grcan/select
Date: October 2012
KernelVersion: 3.8
Contact: Andreas Larsson <andreas@gaisler.com>
Description:
Configuration of which physical interface to be used. Possible
values: 0 or 1. See the GRCAN chapter of the GRLIB IP core
library documentation for details. The default value is 0 or is
set by the module parameter grcan.select and can be read at
/sys/module/grcan/parameters/select.

108
Documentation/ABI/testing/sysfs-class-net-mesh Normal file
View file

@ -0,0 +1,108 @@
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates whether the batman protocol messages of the
mesh <mesh_iface> shall be aggregated or not.
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <antonio@meshcoding.com>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped. <vlan_subdir> is empty when referring
to the untagged lan.
What: /sys/class/net/<mesh_iface>/mesh/bonding
Date: June 2010
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the data traffic going through the
mesh will be sent using multiple interfaces at the
same time (if available).
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
Date: November 2011
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the bridge loop avoidance feature
is enabled. This feature detects and avoids loops
between the mesh and devices bridged with the soft
interface <mesh_iface>.
What: /sys/class/net/<mesh_iface>/mesh/fragmentation
Date: October 2010
Contact: Andreas Langer <an.langer@gmx.de>
Description:
Indicates whether the data traffic going through the
mesh will be fragmented or silently discarded if the
packet size exceeds the outgoing interface MTU.
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
Date: October 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the bandwidth which is propagated by this
node if gw_mode was set to 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
Date: October 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the state of the gateway features. Can be
either 'off', 'client' or 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
Date: October 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the selection criteria this node will use
to choose a gateway if gw_mode was set to 'client'.
What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
Date: Oct 2010
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
What: /sys/class/net/<mesh_iface>/mesh/isolation_mark
Date: Nov 2013
Contact: Antonio Quartulli <antonio@meshcoding.com>
Description:
Defines the isolation mark (and its bitmask) which
is used to classify clients as "isolated" by the
Extended Isolation feature.
What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Indicates whether multicast optimizations are enabled
or disabled. If set to zero then all nodes in the
mesh are going to use classic flooding for any
multicast packet with no optimizations.
What: /sys/class/net/<mesh_iface>/mesh/network_coding
Date: Nov 2012
Contact: Martin Hundeboll <martin@hundeboll.net>
Description:
Controls whether Network Coding (using some magic
to send fewer wifi packets but still the same
content) is enabled or not.
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the interval in milliseconds in which batman
sends its protocol messages.
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
Date: Dec 2011
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the routing procotol this mesh instance
uses to find the optimal paths through the mesh.

79
Documentation/ABI/testing/sysfs-class-net-queues Normal file
View file

@ -0,0 +1,79 @@
What: /sys/class/<iface>/queues/rx-<queue>/rps_cpus
Date: March 2010
KernelVersion: 2.6.35
Contact: netdev@vger.kernel.org
Description:
Mask of the CPU(s) currently enabled to participate into the
Receive Packet Steering packet processing flow for this
network device queue. Possible values depend on the number
of available CPU(s) in the system.
What: /sys/class/<iface>/queues/rx-<queue>/rps_flow_cnt
Date: April 2010
KernelVersion: 2.6.35
Contact: netdev@vger.kernel.org
Description:
Number of Receive Packet Steering flows being currently
processed by this particular network device receive queue.
What: /sys/class/<iface>/queues/tx-<queue>/tx_timeout
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the number of transmit timeout events seen by this
network interface transmit queue.
What: /sys/class/<iface>/queues/tx-<queue>/xps_cpus
Date: November 2010
KernelVersion: 2.6.38
Contact: netdev@vger.kernel.org
Description:
Mask of the CPU(s) currently enabled to participate into the
Transmit Packet Steering packet processing flow for this
network device transmit queue. Possible vaules depend on the
number of available CPU(s) in the system.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the hold time in milliseconds to measure the slack
of this particular network device transmit queue.
Default value is 1000.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the number of bytes (objects) in flight on this
network device transmit queue.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the current limit of bytes allowed to be queued
on this network device transmit queue. This value is clamped
to be within the bounds defined by limit_max and limit_min.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the absolute maximum limit of bytes allowed to be
queued on this network device transmit queue. See
include/linux/dynamic_queue_limits.h for the default value.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the absolute minimum limit of bytes allowed to be
queued on this network device transmit queue. Default value is
0.

201
Documentation/ABI/testing/sysfs-class-net-statistics Normal file
View file

@ -0,0 +1,201 @@
What: /sys/class/<iface>/statistics/collisions
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of collisions seen by this network device.
This value might not be relevant with all MAC layers.
What: /sys/class/<iface>/statistics/multicast
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of multicast packets received by this
network device.
What: /sys/class/<iface>/statistics/rx_bytes
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of bytes received by this network device.
See the network driver for the exact meaning of when this
value is incremented.
What: /sys/class/<iface>/statistics/rx_compressed
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of compressed packets received by this
network device. This value might only be relevant for interfaces
that support packet compression (e.g: PPP).
What: /sys/class/<iface>/statistics/rx_crc_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets received with a CRC (FCS) error
by this network device. Note that the specific meaning might
depend on the MAC layer used by the interface.
What: /sys/class/<iface>/statistics/rx_dropped
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets received by the network device
but dropped, that are not forwarded to the upper layers for
packet processing. See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/rx_fifo_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of receive FIFO errors seen by this
network device. See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/rx_frame_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received frames with error, such as
alignment errors. Note that the specific meaning depends on
on the MAC layer protocol used. See the network driver for
the exact meaning of this value.
What: /sys/class/<iface>/statistics/rx_length_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received error packet with a length
error, oversized or undersized. See the network driver for the
exact meaning of this value.
What: /sys/class/<iface>/statistics/rx_missed_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received packets that have been missed
due to lack of capacity in the receive side. See the network
driver for the exact meaning of this value.
What: /sys/class/<iface>/statistics/rx_over_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received packets that are oversized
compared to what the network device is configured to accept
(e.g: larger than MTU). See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/rx_packets
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the total number of good packets received by this
network device.
What: /sys/class/<iface>/statistics/tx_aborted_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets that have been aborted
during transmission by a network device (e.g: because of
a medium collision). See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/tx_bytes
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of bytes transmitted by a network
device. See the network driver for the exact meaning of this
value, in particular whether this accounts for all successfully
transmitted packets or all packets that have been queued for
transmission.
What: /sys/class/<iface>/statistics/tx_carrier_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets that could not be transmitted
because of carrier errors (e.g: physical link down). See the
network driver for the exact meaning of this value.
What: /sys/class/<iface>/statistics/tx_compressed
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of transmitted compressed packets. Note
this might only be relevant for devices that support
compression (e.g: PPP).
What: /sys/class/<iface>/statistics/tx_dropped
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets dropped during transmission.
See the driver for the exact reasons as to why the packets were
dropped.
What: /sys/class/<iface>/statistics/tx_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets in error during transmission by
a network device. See the driver for the exact reasons as to
why the packets were dropped.
What: /sys/class/<iface>/statistics/tx_fifo_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets having caused a transmit
FIFO error. See the driver for the exact reasons as to why the
packets were dropped.
What: /sys/class/<iface>/statistics/tx_heartbeat_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets transmitted that have been
reported as heartbeat errors. See the driver for the exact
reasons as to why the packets were dropped.
What: /sys/class/<iface>/statistics/tx_packets
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets transmitted by a network
device. See the driver for whether this reports the number of all
attempted or successful transmissions.
What: /sys/class/<iface>/statistics/tx_window_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets not successfully transmitted
due to a window collision. The specific meaning depends on the
MAC layer used. On Ethernet this is usually used to report
late collisions errors.

72
Documentation/ABI/testing/sysfs-class-pktcdvd Normal file
View file

@ -0,0 +1,72 @@
What: /sys/class/pktcdvd/
Date: Oct. 2006
KernelVersion: 2.6.20
Contact: Thomas Maier <balagi@justmail.de>
Description:
sysfs interface
---------------
The pktcdvd module (packet writing driver) creates
these files in the sysfs:
(<devid> is in format major:minor )
/sys/class/pktcdvd/
add (0200) Write a block device id (major:minor)
to create a new pktcdvd device and map
it to the block device.
remove (0200) Write the pktcdvd device id (major:minor)
to it to remove the pktcdvd device.
device_map (0444) Shows the device mapping in format:
pktcdvd[0-7] <pktdevid> <blkdevid>
/sys/class/pktcdvd/pktcdvd[0-7]/
dev (0444) Device id
uevent (0200) To send an uevent.
/sys/class/pktcdvd/pktcdvd[0-7]/stat/
packets_started (0444) Number of started packets.
packets_finished (0444) Number of finished packets.
kb_written (0444) kBytes written.
kb_read (0444) kBytes read.
kb_read_gather (0444) kBytes read to fill write packets.
reset (0200) Write any value to it to reset
pktcdvd device statistic values, like
bytes read/written.
/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/
size (0444) Contains the size of the bio write
queue.
congestion_off (0644) If bio write queue size is below
this mark, accept new bio requests
from the block layer.
congestion_on (0644) If bio write queue size is higher
as this mark, do no longer accept
bio write requests from the block
layer and wait till the pktcdvd
device has processed enough bio's
so that bio write queue size is
below congestion off mark.
A value of <= 0 disables congestion
control.
Example:
--------
To use the pktcdvd sysfs interface directly, you can do:
# create a new pktcdvd device mapped to /dev/hdc
echo "22:0" >/sys/class/pktcdvd/add
cat /sys/class/pktcdvd/device_map
# assuming device pktcdvd0 was created, look at stat's
cat /sys/class/pktcdvd/pktcdvd0/stat/kb_written
# print the device id of the mapped block device
fgrep pktcdvd0 /sys/class/pktcdvd/device_map
# remove device, using pktcdvd0 device id 253:0
echo "253:0" >/sys/class/pktcdvd/remove

34
Documentation/ABI/testing/sysfs-class-power Normal file
View file

@ -0,0 +1,34 @@
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 <k.kozlowski@samsung.com>
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.

152
Documentation/ABI/testing/sysfs-class-powercap Normal file
View file

@ -0,0 +1,152 @@
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.txt 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.

79
Documentation/ABI/testing/sysfs-class-pwm Normal file
View file

@ -0,0 +1,79 @@
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/pwmchipN/
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/pwmchipN/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/pwmchipN/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/pwmchipN/unexport
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Unexports a PWM channel.
What: /sys/class/pwm/pwmchipN/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/pwmchipN/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/pwmchipN/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/pwmchipN/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/pwmchipN/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

111
Documentation/ABI/testing/sysfs-class-rc Normal file
View file

@ -0,0 +1,111 @@
What: /sys/class/rc/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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/rcN/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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/rcN/protocols
Date: Jun 2010
KernelVersion: 2.6.36
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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/rcN/filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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/rcN/filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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/rcN/wakeup_protocols
Date: Feb 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns a list of available protocols to use
for the wakeup filter, something like:
"rc5 rc6 nec jvc [sony]"
The enabled wakeup protocol is shown in [] brackets.
Writing "+proto" will add a protocol to the list of enabled
wakeup protocols.
Writing "-proto" will remove a protocol from the list of enabled
wakeup protocols.
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/rcN/wakeup_filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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/rcN/wakeup_filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
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.

372
Documentation/ABI/testing/sysfs-class-regulator Normal file
View file

@ -0,0 +1,372 @@
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.

Some files were not shown because too many files have changed in this diff Show more