Merge branches 'acpica', 'aml-custom', 'bugzilla-16548', 'bugzilla-20242',...

Andrew Morton <akpm@osdl.org>

Andrew Vasquez <andrew.vasquez@qlogic.com>

Andy Adamson <andros@citi.umich.edu>

Archit Taneja <archit@ti.com>

Arnaud Patard <arnaud.patard@rtp-net.org>

Arnd Bergmann <arnd@arndb.de>

Axel Dyks <xl@xlsigned.net>

Linas Vepstas <linas@austin.ibm.com>

Mark Brown <broonie@sirena.org.uk>

Matthieu CASTET <castet.matthieu@free.fr>

Mayuresh Janorkar <mayur@ti.com>

Michael Buesch <mb@bu3sch.de>

Michael Buesch <mbuesch@freenet.de>

Michel Dänzer <michel@tungstengraphics.com>

Morten Welinder <welinder@anemone.rentec.com>

Morten Welinder <welinder@darter.rentec.com>

Morten Welinder <welinder@troll.com>

Mythri P K <mythripk@ti.com>

Nguyen Anh Quynh <aquynh@gmail.com>

Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

Patrick Mochel <mochel@digitalimplant.org>

Simon Kelley <simon@thekelleys.org.uk>

Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>

Stephen Hemminger <shemminger@osdl.org>

Sumit Semwal <sumit.semwal@ti.com>

Tejun Heo <htejun@gmail.com>

Thomas Graf <tgraf@suug.ch>

Tony Luck <tony.luck@intel.com>

D: Assorted VIA x86 support.

D: 2.5 AGPGART overhaul.

D: CPUFREQ maintenance.

D: Fedora kernel maintainence.

D: Fedora kernel maintenance.

D: Misc/Other.

S: 314 Littleton Rd, Westford, MA 01886, USA

E: jsimmons@infradead.org

E: jsimmons@users.sf.net 

D: Frame buffer device maintainer

D: input layer developement 

D: input layer development

D: tty/console layer

D: various mipsel devices 

S: 115 Carmel Avenue 

N: Manfred Spraul

E: manfred@colorfullife.com

W: http://www.colorfullife.com/~manfred

D: Lots of tiny hacks. Larger improvments to SysV IPC msg,

D: Lots of tiny hacks. Larger improvements to SysV IPC msg,

D: slab, pipe, select.

S: 71701 Schwieberdingen

S: Germany

	- directory with laptop related info and laptop driver documentation.

ldm.txt

	- a brief description of LDM (Windows Dynamic Disks).

leds-class.txt

	- documents LED handling under Linux.

leds/

	- directory with info about LED handling under Linux.

local_ops.txt

	- semantics and behavior of local atomic operations.

lockdep-design.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

	- 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/

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.

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.