Merge branch 'linus' into release (02e24078) · Commits · e / devices / android_kernel_xiaomi_markw

Documentation/00-INDEX

+0 −4

Original line number	Diff line number	Diff line
		@@ -328,8 +328,6 @@ sysrq.txt
		- info on the magic SysRq key.
		telephony/
		- directory with info on telephony (e.g. voice over IP) support.
		time_interpolators.txt
		- info on time interpolators.
		uml/
		- directory with information about User Mode Linux.
		unicode.txt
		@@ -346,8 +344,6 @@ vm/
		- directory with info on the Linux vm code.
		volatile-considered-harmful.txt
		- Why the "volatile" type class should not be used
		voyager.txt
		- guide to running Linux on the Voyager architecture.
		w1/
		- directory with documents regarding the 1-wire (w1) subsystem.
		watchdog/

Documentation/ABI/stable/sysfs-class-backlight

+20 −0

Original line number	Diff line number	Diff line
		@@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
		Description:
		Maximum brightness for <backlight>.
		Users: HAL

		What: /sys/class/backlight/<backlight>/type
		Date: September 2010
		KernelVersion: 2.6.37
		Contact: Matthew Garrett <mjg@redhat.com>
		Description:
		The type of interface controlled by <backlight>.
		"firmware": The driver uses a standard firmware interface
		"platform": The driver uses a platform-specific interface
		"raw": The driver controls hardware registers directly

		In the general case, when multiple backlight
		interfaces are available for a single device, firmware
		control should be preferred to platform control should
		be preferred to raw control. Using a firmware
		interface reduces the probability of confusion with
		the hardware and the OS independently updating the
		backlight state. Platform interfaces are mostly a
		holdover from pre-standardisation of firmware
		interfaces.

Documentation/ABI/stable/sysfs-firmware-efi-vars

0 → 100644

+75 −0

Original line number	Diff line number	Diff line
		What: /sys/firmware/efi/vars
		Date: April 2004
		Contact: Matt Domsch <Matt_Domsch@dell.com>
		Description:
		This directory exposes interfaces for interactive with
		EFI variables. For more information on EFI variables,
		see 'Variable Services' in the UEFI specification
		(section 7.2 in specification version 2.3 Errata D).

		In summary, EFI variables are named, and are classified
		into separate namespaces through the use of a vendor
		GUID. They also have an arbitrary binary value
		associated with them.

		The efivars module enumerates these variables and
		creates a separate directory for each one found. Each
		directory has a name of the form "<key>-<vendor guid>"
		and contains the following files:

		attributes: A read-only text file enumerating the
		EFI variable flags. Potential values
		include:

		EFI_VARIABLE_NON_VOLATILE
		EFI_VARIABLE_BOOTSERVICE_ACCESS
		EFI_VARIABLE_RUNTIME_ACCESS
		EFI_VARIABLE_HARDWARE_ERROR_RECORD
		EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS

		See the EFI documentation for an
		explanation of each of these variables.

		data: A read-only binary file that can be read
		to attain the value of the EFI variable

		guid: The vendor GUID of the variable. This
		should always match the GUID in the
		variable's name.

		raw_var: A binary file that can be read to obtain
		a structure that contains everything
		there is to know about the variable.
		For structure definition see "struct
		efi_variable" in the kernel sources.

		This file can also be written to in
		order to update the value of a variable.
		For this to work however, all fields of
		the "struct efi_variable" passed must
		match byte for byte with the structure
		read out of the file, save for the value
		portion.

		Note the efi_variable structure
		read/written with this file contains a
		'long' type that may change widths
		depending on your underlying
		architecture.

		size: As ASCII representation of the size of
		the variable's value.


		In addition, two other magic binary files are provided
		in the top-level directory and are used for adding and
		removing variables:

		new_var: Takes a "struct efi_variable" and
		instructs the EFI firmware to create a
		new variable.

		del_var: Takes a "struct efi_variable" and
		instructs the EFI firmware to remove any
		variable that has a matching vendor GUID
		and variable key name.

Documentation/ABI/testing/configfs-spear-pcie-gadget

0 → 100644

+31 −0

Original line number	Diff line number	Diff line
		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.

Documentation/ABI/testing/pstore

0 → 100644

+41 −0

Original line number	Diff line number	Diff line
		Where: /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 - /dev/pstore

		$ ls -l /dev/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 /dev/pstore/dmesg-erst-1

		The expectation is that all files in /dev/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.