Merge branch 'linux-3.18.y' of...

 - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.

   This option is only supported in hardware blocks version 1.11a or newer.

 - i2c-scl-falling-time : should contain the SCL falling time in nanoseconds.

 - i2c-scl-falling-time-ns : should contain the SCL falling time in nanoseconds.

   This value which is by default 300ns is used to compute the tLOW period.

 - i2c-sda-falling-time : should contain the SDA falling time in nanoseconds.

 - i2c-sda-falling-time-ns : should contain the SDA falling time in nanoseconds.

   This value which is by default 300ns is used to compute the tHIGH period.

Example :

	i8042.notimeout	[HW] Ignore timeout condition signalled by controller

	i8042.reset	[HW] Reset the controller during init and cleanup

	i8042.unlock	[HW] Unlock (ignore) the keylock

	i8042.kbdreset  [HW] Reset device connected to KBD port

	i810=		[HW,DRM]

1. Ramoops concepts

Ramoops uses a predefined memory area to store the dump. The start and size of

the memory area are set using two variables:

Ramoops uses a predefined memory area to store the dump. The start and size

and type of the memory area are set using three variables:

  * "mem_address" for the start

  * "mem_size" for the size. The memory size will be rounded down to a

  power of two.

  * "mem_type" to specifiy if the memory type (default is pgprot_writecombine).

Typically the default value of mem_type=0 should be used as that sets the pstore

mapping to pgprot_writecombine. Setting mem_type=1 attempts to use

pgprot_noncached, which only works on some platforms. This is because pstore

depends on atomic operations. At least on ARM, pgprot_noncached causes the

memory to be mapped strongly ordered, and atomic operations on strongly ordered

memory are implementation defined, and won't work on many ARMs such as omaps.

The memory area is divided into "record_size" chunks (also rounded down to

power of two) and each oops/panic writes a "record_size" chunk of

static struct ramoops_platform_data ramoops_data = {

        .mem_size               = <...>,

        .mem_address            = <...>,

        .mem_type               = <...>,

        .record_size            = <...>,

        .dump_oops              = <...>,

        .ecc                    = <...>,

 - If the patch covers files in net/ or drivers/net please follow netdev stable

   submission guidelines as described in

   Documentation/networking/netdev-FAQ.txt

 - Send the patch, after verifying that it follows the above rules, to

   stable@vger.kernel.org.  You must note the upstream commit ID in the

   changelog of your submission, as well as the kernel version you wish

   it to be applied to.

 - To have the patch automatically included in the stable tree, add the tag

 - Security patches should not be handled (solely) by the -stable review

   process but should follow the procedures in Documentation/SecurityBugs.

For all other submissions, choose one of the following procedures:

   --- Option 1 ---

   To have the patch automatically included in the stable tree, add the tag

     Cc: stable@vger.kernel.org

   in the sign-off area. Once the patch is merged it will be applied to

   the stable tree without anything else needing to be done by the author

   or subsystem maintainer.

 - If the patch requires other patches as prerequisites which can be

   cherry-picked, then this can be specified in the following format in

   the sign-off area:

   --- Option 2 ---

   After the patch has been merged to Linus' tree, send an email to

   stable@vger.kernel.org containing the subject of the patch, the commit ID,

   why you think it should be applied, and what kernel version you wish it to

   be applied to.

   --- Option 3 ---

   Send the patch, after verifying that it follows the above rules, to

   stable@vger.kernel.org.  You must note the upstream commit ID in the

   changelog of your submission, as well as the kernel version you wish

   it to be applied to.

Option 1 is probably the easiest and most common. Options 2 and 3 are more

useful if the patch isn't deemed worthy at the time it is applied to a public

git tree (for instance, because it deserves more regression testing first).

Option 3 is especially useful if the patch needs some special handling to apply

to an older kernel (e.g., if API's have changed in the meantime).

Additionally, some patches submitted via Option 1 may have additional patch

prerequisites which can be cherry-picked. This can be specified in the following

format in the sign-off area:

     Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle

     Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle

     git cherry-pick fd21073

     git cherry-pick <this commit>

Following the submission:

 - The sender will receive an ACK when the patch has been accepted into the

   queue, or a NAK if the patch is rejected.  This response might take a few

   days, according to the developer's schedules.

 - If accepted, the patch will be added to the -stable queue, for review by

   other developers and by the relevant subsystem maintainer.

 - Security patches should not be sent to this alias, but instead to the

   documented security@kernel.org address.

Review cycle:

VERSION = 3

PATCHLEVEL = 18

SUBLEVEL = 0

SUBLEVEL = 11

EXTRAVERSION =

NAME = Diseased Newt