Merge branch 'tmp-bab15641' into msm-4.4

	- Switching I/O schedulers at runtime

writeback_cache_control.txt

	- Control of volatile write back caches

mmc-max-speed.txt

	- eMMC layer speed simulation, related to /sys/block/mmcblk*/

          attributes:

            max_read_speed

            max_write_speed

            cache_size

eMMC Block layer simulation speed controls in /sys/block/mmcblk*/

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

Turned on with CONFIG_MMC_SIMULATE_MAX_SPEED which enables MMC device speed

limiting. Used to test and simulate the behavior of the system when

confronted with a slow MMC.

Enables max_read_speed, max_write_speed and cache_size attributes and module

default parameters to control the write or read maximum KB/second speed

behaviors.

NB: There is room for improving the algorithm for aspects tied directly to

eMMC specific behavior. For instance, wear leveling and stalls from an

exhausted erase pool. We would expect that if there was a need to provide

similar speed simulation controls to other types of block devices, aspects of

their behavior are modelled separately (e.g. head seek times, heat assist,

shingling and rotational latency).

/sys/block/mmcblk0/max_read_speed:

Number of KB/second reads allowed to the block device. Used to test and

simulate the behavior of the system when confronted with a slow reading MMC.

Set to 0 or "off" to place no speed limit.

/sys/block/mmcblk0/max_write_speed:

Number of KB/second writes allowed to the block device. Used to test and

simulate the behavior of the system when confronted with a slow writing MMC.

Set to 0 or "off" to place no speed limit.

/sys/block/mmcblk0/cache_size:

Number of MB of high speed memory or high speed SLC cache expected on the

eMMC device being simulated. Used to help simulate the write-back behavior

more accurately. The assumption is the cache has no delay, but draws down

in the background to the MLC/TLC primary store at the max_write_speed rate.

Any write speed delays will show up when the cache is full, or when an I/O

request to flush is issued.

    0 is the original format used in the Chromium OS.

      The salt is appended when hashing, digests are stored continuously and

      the rest of the block is padded with zeros.

      the rest of the block is padded with zeroes.

    1 is the current format that should be used for new devices.

      The salt is prepended when hashing and each digest is

      padded with zeros to the power of two.

      padded with zeroes to the power of two.

<dev>

    This is the device containing data, the integrity of which needs to be

    not compatible with ignore_corruption and requires user space support to

    avoid restart loops.

ignore_zero_blocks

    Do not verify blocks that are expected to contain zeroes and always return

    zeroes instead. This may be useful if the partition contains unused blocks

    that are not guaranteed to contain zeroes.

use_fec_from_device <fec_dev>

    Use forward error correction (FEC) to recover from corruption if hash

    verification fails. Use encoding data from the specified device. This

    may be the same device where data and hash blocks reside, in which case

    fec_start must be outside data and hash areas.

    If the encoding data covers additional metadata, it must be accessible

    on the hash device after the hash blocks.

    Note: block sizes for data and hash devices must match. Also, if the

    verity <dev> is encrypted the <fec_dev> should be too.

fec_roots <num>

    Number of generator roots. This equals to the number of parity bytes in

    the encoding data. For example, in RS(M, N) encoding, the number of roots

    is M-N.

fec_blocks <num>

    The number of encoding data blocks on the FEC device. The block size for

    the FEC device is <data_block_size>.

fec_start <offset>

    This is the offset, in <data_block_size> blocks, from the start of the

    FEC device to the beginning of the encoding data.

Theory of operation

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

into the page cache. Block hashes are stored linearly, aligned to the nearest

block size.

If forward error correction (FEC) support is enabled any recovery of

corrupted data will be verified using the cryptographic hash of the

corresponding data. This is why combining error correction with

integrity checking is essential.

Hash Tree

---------

CONFIG_CP15_BARRIER_EMULATION=y

CONFIG_DM_CRYPT=y

CONFIG_DM_VERITY=y

CONFIG_DM_VERITY_FEC=y

CONFIG_EMBEDDED=y

CONFIG_FB=y

CONFIG_HIGH_RES_TIMERS=y

CONFIG_INET6_ESP=y

CONFIG_INET6_IPCOMP=y

CONFIG_INET=y

CONFIG_INET_DIAG_DESTROY=y

CONFIG_INET_ESP=y

CONFIG_INET_XFRM_MODE_TUNNEL=y

CONFIG_IP6_NF_FILTER=y

{

	unsigned long rnd;

	rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);

	rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);

	return rnd << PAGE_SHIFT;

}