Merge tag 'v4.0-rc5' into linux-next

Code of Conflict

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

The Linux kernel development effort is a very personal process compared

to "traditional" ways of developing software.  Your code and ideas

behind it will be carefully reviewed, often resulting in critique and

criticism.  The review will almost always require improvements to the

code before it can be included in the kernel.  Know that this happens

because everyone involved wants to see the best possible solution for

the overall success of Linux.  This development process has been proven

to create the most robust operating system kernel ever, and we do not

want to do anything to cause the quality of submission and eventual

result to ever decrease.

If however, anyone feels personally abused, threatened, or otherwise

uncomfortable due to this process, that is not acceptable.  If so,

please contact the Linux Foundation's Technical Advisory Board at

<tab@lists.linux-foundation.org>, or the individual members, and they

will work to resolve the issue to the best of their ability.  For more

information on who is on the Technical Advisory Board and what their

role is, please see:

	http://www.linuxfoundation.org/programs/advisory-councils/tab

As a reviewer of code, please strive to keep things civil and focused on

the technical issues involved.  We are all humans, and frustrations can

be high on both sides of the process.  Try to keep in mind the immortal

words of Bill and Ted, "Be excellent to each other."

   may be configured as a kernel built-in or a kernel loadable module.

   You can only make use of <constant>kgdbwait</constant> and early

   debugging if you build kgdboc into the kernel as a built-in.

   </para>

   <para>Optionally you can elect to activate kms (Kernel Mode

   Setting) integration.  When you use kms with kgdboc and you have a

   video driver that has atomic mode setting hooks, it is possible to

   crashes or doing analysis of memory with kdb while allowing the

   full graphics console applications to run.

   </para>

   </para>

   <sect2 id="kgdbocArgs">

   <title>kgdboc arguments</title>

   <para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>

   </listitem>

   </orderedlist>

   </para>

   </sect3>

   <para>NOTE: Kgdboc does not support interrupting the target via the

   gdb remote protocol.  You must manually send a sysrq-g unless you

   have a proxy that splits console output to a terminal program.

    as well as on the initial connect, or to use a debugger proxy that

    allows an unmodified gdb to do the debugging.

   </para>

   </sect3>

   </sect2>

   </sect1>

   <sect1 id="kgdbwait">

   </para>

   </listitem>

   </orderedlist>

  </para>

   <para>IMPORTANT NOTE: You cannot use kgdboc + kgdbcon on a tty that is an

   active system console.  An example of incorrect usage is <constant>console=ttyS0,115200 kgdboc=ttyS0 kgdbcon</constant>

   </para>

   <para>It is possible to use this option with kgdboc on a tty that is not a system console.

   </para>

  </para>

  </sect1>

   <sect1 id="kgdbreboot">

   <title>Run time parameter: kgdbreboot</title>

  be understood as an underflow into the highest possible value, -2 or

  -10M etc. do not work, so it's not consistent.

  memory.low, memory.high, and memory.max will use the string

  "infinity" to indicate and set the highest possible value.

  memory.low, memory.high, and memory.max will use the string "max" to

  indicate and set the highest possible value.

5. Planned Changes

						unsigned long *parent_rate);

		long		(*determine_rate)(struct clk_hw *hw,

						unsigned long rate,

						unsigned long min_rate,

						unsigned long max_rate,

						unsigned long *best_parent_rate,

						struct clk_hw **best_parent_clk);

		int		(*set_parent)(struct clk_hw *hw, u8 index);

    Otherwise #opt_params is the number of following arguments.

    Example of optional parameters section:

        1 allow_discards

        3 allow_discards same_cpu_crypt submit_from_crypt_cpus

allow_discards

    Block discard requests (a.k.a. TRIM) are passed through the crypt device.

    used space etc.) if the discarded blocks can be located easily on the

    device later.

same_cpu_crypt

    Perform encryption using the same cpu that IO was submitted on.

    The default is to use an unbound workqueue so that encryption work

    is automatically balanced between available CPUs.

submit_from_crypt_cpus

    Disable offloading writes to a separate thread after encryption.

    There are some situations where offloading write bios from the

    encryption threads to a single thread degrades performance

    significantly.  The default is to offload write bios to the same

    thread because it benefits CFQ to have writes submitted using the

    same context.

Example scripts

===============

LUKS (Linux Unified Key Setup) is now the preferred way to set up disk