Merge commit 'v2.6.27-rc8' into oprofile (59293c8a) · Commits · e / devices / android_kernel_sony_msm8998

.mailmap

+2 −0

Original line number	Diff line number	Diff line
		@@ -96,4 +96,6 @@ Tejun Heo <htejun@gmail.com>
		Thomas Graf <tgraf@suug.ch>
		Tony Luck <tony.luck@intel.com>
		Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
		Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
		Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
		Valdis Kletnieks <Valdis.Kletnieks@vt.edu>

Documentation/ABI/testing/sysfs-firmware-sgi_uv

0 → 100644

+27 −0

Original line number	Diff line number	Diff line
		What: /sys/firmware/sgi_uv/
		Date: August 2008
		Contact: Russ Anderson <rja@sgi.com>
		Description:
		The /sys/firmware/sgi_uv directory contains information
		about the SGI UV platform.

		Under that directory are a number of files:

		partition_id
		coherence_id

		The partition_id entry contains the partition id.
		SGI UV systems can be partitioned into multiple physical
		machines, which each partition running a unique copy
		of the operating system. Each partition will have a unique
		partition id. To display the partition id, use the command:

		cat /sys/firmware/sgi_uv/partition_id

		The coherence_id entry contains the coherence id.
		A partitioned SGI UV system can have one or more coherence
		domain. The coherence id indicates which coherence domain
		this partition is in. To display the coherence id, use the
		command:

		cat /sys/firmware/sgi_uv/coherence_id

Documentation/ABI/testing/sysfs-gpio

0 → 100644

+26 −0

Original line number	Diff line number	Diff line
		What: /sys/class/gpio/
		Date: July 2008
		KernelVersion: 2.6.27
		Contact: David Brownell <dbrownell@users.sourceforge.net>
		Description:

		As a Kconfig option, individual GPIO signals may be accessed from
		userspace. GPIOs are only made available to userspace by an explicit
		"export" operation. If a given GPIO is not claimed for use by
		kernel code, it may be exported by userspace (and unexported later).
		Kernel code may export it for complete or partial access.

		GPIOs are identified as they are inside the kernel, using integers in
		the range 0..INT_MAX. See Documentation/gpio.txt for more information.

		/sys/class/gpio
		/export ... asks the kernel to export a GPIO to userspace
		/unexport ... to return a GPIO to the kernel
		/gpioN ... for each exported GPIO #N
		/value ... always readable, writes fail for input GPIOs
		/direction ... r/w as: in, out (default low); write: high, low
		/gpiochipN ... for each gpiochip; #N is its first GPIO
		/base ... (r/o) same as N
		/label ... (r/o) descriptive, not necessarily unique
		/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)

Documentation/DMA-mapping.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -740,7 +740,7 @@ failure can be determined by:
		dma_addr_t dma_handle;

		dma_handle = pci_map_single(pdev, addr, size, direction);
		if (pci_dma_mapping_error(dma_handle)) {
		if (pci_dma_mapping_error(pdev, dma_handle)) {
		/*
		* reduce current DMA mapping usage,
		* delay and try again later or

Documentation/cpusets.txt

+10 −8

Original line number	Diff line number	Diff line
		@@ -635,14 +635,16 @@ prior 'mems' setting, will not be moved.

		There is an exception to the above. If hotplug functionality is used
		to remove all the CPUs that are currently assigned to a cpuset,
		then the kernel will automatically update the cpus_allowed of all
		tasks attached to CPUs in that cpuset to allow all CPUs. When memory
		hotplug functionality for removing Memory Nodes is available, a
		similar exception is expected to apply there as well. In general,
		the kernel prefers to violate cpuset placement, over starving a task
		that has had all its allowed CPUs or Memory Nodes taken offline. User
		code should reconfigure cpusets to only refer to online CPUs and Memory
		Nodes when using hotplug to add or remove such resources.
		then all the tasks in that cpuset will be moved to the nearest ancestor
		with non-empty cpus. But the moving of some (or all) tasks might fail if
		cpuset is bound with another cgroup subsystem which has some restrictions
		on task attaching. In this failing case, those tasks will stay
		in the original cpuset, and the kernel will automatically update
		their cpus_allowed to allow all online CPUs. When memory hotplug
		functionality for removing Memory Nodes is available, a similar exception
		is expected to apply there as well. In general, the kernel prefers to
		violate cpuset placement, over starving a task that has had all
		its allowed CPUs or Memory Nodes taken offline.

		There is a second exception to the above. GFP_ATOMIC requests are
		kernel internal allocations that must be satisfied, immediately.