Merge branch 'master' into for-linus

Date:		May 2009

Contact:	Martin K. Petersen <martin.petersen@oracle.com>

Description:

		This is the smallest unit the storage device can write

		without resorting to read-modify-write operation.  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.

		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 preferred minimum I/O size,

		which is the smallest request the device can perform

		without incurring a read-modify-write penalty.  For disk

		drives this is often the physical block size.  For RAID

		arrays it is often the stripe chunk size.

		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 of receiving I/O.  This is

		rarely reported for disk drives.  For RAID devices it is

		usually the stripe width or the internal block size.

		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.

   </para>

   <programlisting>

__u32 ipaddress;

printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));

__be32 ipaddress;

printk(KERN_INFO "my ip: %pI4\n", &ipaddress);

   </programlisting>

   <para>

	- Bluetooth enable and disable

	- video output switching, expansion control

	- ThinkLight on and off

	- limited docking and undocking

	- UltraBay eject

	- CMOS/UCMS control

	- LED control

	- ACPI sounds

It is impossible to know if the status returned through sysfs is valid.

Docking / undocking -- /proc/acpi/ibm/dock

------------------------------------------

Docking and undocking (e.g. with the X4 UltraBase) requires some

actions to be taken by the operating system to safely make or break

the electrical connections with the dock.

The docking feature of this driver generates the following ACPI events:

	ibm/dock GDCK 00000003 00000001 -- eject request

	ibm/dock GDCK 00000003 00000002 -- undocked

	ibm/dock GDCK 00000000 00000003 -- docked

NOTE: These events will only be generated if the laptop was docked

when originally booted. This is due to the current lack of support for

hot plugging of devices in the Linux ACPI framework. If the laptop was

booted while not in the dock, the following message is shown in the

logs:

	Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present

In this case, no dock-related events are generated but the dock and

undock commands described below still work. They can be executed

manually or triggered by Fn key combinations (see the example acpid

configuration files included in the driver tarball package available

on the web site).

When the eject request button on the dock is pressed, the first event

above is generated. The handler for this event should issue the

following command:

	echo undock > /proc/acpi/ibm/dock

After the LED on the dock goes off, it is safe to eject the laptop.

Note: if you pressed this key by mistake, go ahead and eject the

laptop, then dock it back in. Otherwise, the dock may not function as

expected.

When the laptop is docked, the third event above is generated. The

handler for this event should issue the following command to fully

enable the dock:

	echo dock > /proc/acpi/ibm/dock

The contents of the /proc/acpi/ibm/dock file shows the current status

of the dock, as provided by the ACPI framework.

The docking support in this driver does not take care of enabling or

disabling any other devices you may have attached to the dock. For

example, a CD drive plugged into the UltraBase needs to be disabled or

enabled separately. See the provided example acpid configuration files

for how this can be accomplished.

There is no support yet for PCI devices that may be attached to a

docking station, e.g. in the ThinkPad Dock II. The driver currently

does not recognize, enable or disable such devices. This means that

the only docking stations currently supported are the X-series

UltraBase docks and "dumb" port replicators like the Mini Dock (the

latter don't need any ACPI support, actually).

UltraBay eject -- /proc/acpi/ibm/bay

------------------------------------

Inserting or ejecting an UltraBay device requires some actions to be

taken by the operating system to safely make or break the electrical

connections with the device.

This feature generates the following ACPI events:

	ibm/bay MSTR 00000003 00000000 -- eject request

	ibm/bay MSTR 00000001 00000000 -- eject lever inserted

NOTE: These events will only be generated if the UltraBay was present

when the laptop was originally booted (on the X series, the UltraBay

is in the dock, so it may not be present if the laptop was undocked).

This is due to the current lack of support for hot plugging of devices

in the Linux ACPI framework. If the laptop was booted without the

UltraBay, the following message is shown in the logs:

	Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present

In this case, no bay-related events are generated but the eject

command described below still works. It can be executed manually or

triggered by a hot key combination.

Sliding the eject lever generates the first event shown above. The

handler for this event should take whatever actions are necessary to

shut down the device in the UltraBay (e.g. call idectl), then issue

the following command:

	echo eject > /proc/acpi/ibm/bay

After the LED on the UltraBay goes off, it is safe to pull out the

device.

When the eject lever is inserted, the second event above is

generated. The handler for this event should take whatever actions are

necessary to enable the UltraBay device (e.g. call idectl).

The contents of the /proc/acpi/ibm/bay file shows the current status

of the UltraBay, as provided by the ACPI framework.

EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use

this feature, you need to supply the experimental=1 parameter when

loading the module):

These models do not have a button near the UltraBay device to request

a hot eject but rather require the laptop to be put to sleep

(suspend-to-ram) before the bay device is ejected or inserted).

The sequence of steps to eject the device is as follows:

	echo eject > /proc/acpi/ibm/bay

	put the ThinkPad to sleep

	remove the drive

	resume from sleep

	cat /proc/acpi/ibm/bay should show that the drive was removed

On the A3x, both the UltraBay 2000 and UltraBay Plus devices are

supported. Use "eject2" instead of "eject" for the second bay.

Note: the UltraBay eject support on the 600e/x, A22p and A3x is

EXPERIMENTAL and may not work as expected. USE WITH CAUTION!

CMOS/UCMS control

-----------------

F:	drivers/net/r8169.c

8250/16?50 (AND CLONE UARTS) SERIAL DRIVER

M:	Alan Cox <alan@lxorguk.ukuu.org.uk>

L:	linux-serial@vger.kernel.org

W:	http://serial.sourceforge.net

S:	Odd Fixes

S:	Orphan

F:	drivers/serial/8250*

F:	include/linux/serial_8250.h

F:	drivers/mfd/

MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM

M:	Pierre Ossman <pierre@ossman.eu>

S:	Maintained

S:	Orphan

F:	drivers/mmc/

F:	include/linux/mmc/

S:	Maintained

TTY LAYER

M:	Alan Cox <alan@lxorguk.ukuu.org.uk>

M:	Greg Kroah-Hartman <gregkh@suse.de>

S:	Maintained

T:	stgit http://zeniv.linux.org.uk/~alan/ttydev/

T:	quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

F:	drivers/char/tty_*

F:	drivers/serial/serial_core.c

F:	include/linux/serial_core.h