Merge branch 'linux-linaro-lsk-v3.18' into linux-linaro-lsk-v3.18-android

using the kernel crypto API.

For a more detailed description of supported parameters see:

http://code.google.com/p/cryptsetup/wiki/DMCrypt

https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt

Parameters: <cipher> <key> <iv_offset> <device path> \

	      <offset> [<#opt_params> <opt_params>]

    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

encryption with dm-crypt using the 'cryptsetup' utility, see

http://code.google.com/p/cryptsetup/

https://gitlab.com/cryptsetup/cryptsetup

[[

#!/bin/sh

The full specification of kernel parameters and on-disk metadata format

is available at the cryptsetup project's wiki page

  http://code.google.com/p/cryptsetup/wiki/DMVerity

  https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity

Status

======

A command line tool veritysetup is available to compute or verify

the hash tree or activate the kernel device. This is available from

the cryptsetup upstream repository http://code.google.com/p/cryptsetup/

the cryptsetup upstream repository https://gitlab.com/cryptsetup/cryptsetup/

(as a libcryptsetup extension).

Create hash on the device:

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

  AF_RDS, PF_RDS, SOL_RDS

        These constants haven't been assigned yet, because RDS isn't in

        mainline yet. Currently, the kernel module assigns some constant

        and publishes it to user space through two sysctl files

                /proc/sys/net/rds/pf_rds

                /proc/sys/net/rds/sol_rds

	AF_RDS and PF_RDS are the domain type to be used with socket(2)

	to create RDS sockets. SOL_RDS is the socket-level to be used

	with setsockopt(2) and getsockopt(2) for RDS specific socket

	options.

  fd = socket(PF_RDS, SOCK_SEQPACKET, 0);

        This creates a new, unbound RDS socket.

	.name = "foo",

	.pins = foo_pins,

	.npins = ARRAY_SIZE(foo_pins),

	.maxpin = 63,

	.owner = THIS_MODULE,

};

}

static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,

			       unsigned ** const pins,

			       unsigned * const num_pins)

			       const unsigned **pins,

			       unsigned *num_pins)

{

	*pins = (unsigned *) foo_groups[selector].pins;

	*num_pins = foo_groups[selector].num_pins;

this happens.

Pinmux drivers are required to supply a few callback functions, some are

optional. Usually the enable() and disable() functions are implemented,

writing values into some certain registers to activate a certain mux setting

for a certain pin.

optional. Usually the set_mux() function is implemented, writing values into

some certain registers to activate a certain mux setting for a certain pin.

A simple driver for the above example will work by setting bits 0, 1, 2, 3 or 4

into some register named MUX to select a certain function with a certain

Usually the pin control core handled the get/put pair and call out to the

device drivers bookkeeping operations, like checking available functions and

the associated pins, whereas the enable/disable pass on to the pin controller

the associated pins, whereas select_state pass on to the pin controller

driver which takes care of activating and/or deactivating the mux setting by

quickly poking some registers.

"Advanced mapping" above. So that for an SPI device, we have two states named

"pos-A" and "pos-B".

This snippet first muxes the function in the pins defined by group A, enables

it, disables and releases it, and muxes it in on the pins defined by group B:

This snippet first initializes a state object for both groups (in foo_probe()),

then muxes the function in the pins defined by group A, and finally muxes it in

on the pins defined by group B:

#include <linux/pinctrl/consumer.h>

     git cherry-pick fd21073

     git cherry-pick <this commit>

Also, some patches may have kernel version prerequisites.  This can be

specified in the following format in the sign-off area:

     Cc:  <stable@vger.kernel.org> # 3.3.x-

   The tag has the meaning of:

     git cherry-pick <this commit>

   For each "-stable" tree starting with the specified version.

Following the submission:

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