Merge 3.14-rc7 into staging-next

Updating on-disk metadata

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

On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is

written.  If no such requests are made then commits will occur every

second.  This means the cache behaves like a physical disk that has a

write cache (the same is true of the thin-provisioning target).  If

power is lost you may lose some recent writes.  The metadata should

always be consistent in spite of any crash.

On-disk metadata is committed every time a FLUSH or FUA bio is written.

If no such requests are made then commits will occur every second.  This

means the cache behaves like a physical disk that has a volatile write

cache.  If power is lost you may lose some recent writes.  The metadata

should always be consistent in spite of any crash.

The 'dirty' state for a cache block changes far too frequently for us

to keep updating it on the fly.  So we treat it as a hint.  In normal

userspace daemon can use this to detect a situation where a new table

already exceeds the threshold.

A low water mark for the metadata device is maintained in the kernel and

will trigger a dm event if free space on the metadata device drops below

it.

Updating on-disk metadata

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

On-disk metadata is committed every time a FLUSH or FUA bio is written.

If no such requests are made then commits will occur every second.  This

means the thin-provisioning target behaves like a physical disk that has

a volatile write cache.  If power is lost you may lose some recent

writes.  The metadata should always be consistent in spite of any crash.

If data space is exhausted the pool will either error or queue IO

according to the configuration (see: error_if_no_space).  If metadata

space is exhausted or a metadata operation fails: the pool will error IO

until the pool is taken offline and repair is performed to 1) fix any

potential inconsistencies and 2) clear the flag that imposes repair.

Once the pool's metadata device is repaired it may be resized, which

will allow the pool to return to normal operation.  Note that if a pool

is flagged as needing repair, the pool's data and metadata devices

cannot be resized until repair is performed.  It should also be noted

that when the pool's metadata space is exhausted the current metadata

transaction is aborted.  Given that the pool will cache IO whose

completion may have already been acknowledged to upper IO layers

(e.g. filesystem) it is strongly suggested that consistency checks

(e.g. fsck) be performed on those layers when repair of the pool is

required.

Thin provisioning

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

	should register for the event and then check the target's status.

    held metadata root:

	The location, in sectors, of the metadata root that has been

	The location, in blocks, of the metadata root that has been

	'held' for userspace read access.  '-' indicates there is no

	held root.  This feature is not yet implemented so '-' is

	always returned.

	held root.

    discard_passdown|no_discard_passdown

	Whether or not discards are actually being passed down to the

    must appear in the same order as the output clocks.

  - #clock-cells: Must be 1

  - clock-output-names: The name of the clocks as free-form strings

  - renesas,indices: Indices of the gate clocks into the group (0 to 31)

  - renesas,clock-indices: Indices of the gate clocks into the group (0 to 31)

The clocks, clock-output-names and renesas,indices properties contain one

The clocks, clock-output-names and renesas,clock-indices properties contain one

entry per gate clock. The MSTP groups are sparsely populated. Unimplemented

gate clocks must not be declared.

* OpenCores MAC 10/100 Mbps

Required properties:

- compatible: Should be "opencores,ethoc".

- reg: two memory regions (address and length),

  first region is for the device registers and descriptor rings,

  second is for the device packet memory.

- interrupts: interrupt for the device.

Optional properties:

- clocks: phandle to refer to the clk used as per

  Documentation/devicetree/bindings/clock/clock-bindings.txt

Examples:

	enet0: ethoc@fd030000 {

		compatible = "opencores,ethoc";

		reg = <0xfd030000 0x4000 0xfd800000 0x4000>;

		interrupts = <1>;

		local-mac-address = [00 50 c2 13 6f 00];

		clocks = <&osc>;

        };

Broadcom Capri Pin Controller

Broadcom BCM281xx Pin Controller

This is a pin controller for the Broadcom BCM281xx SoC family, which includes

BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs.

Required Properties:

- compatible:	Must be "brcm,capri-pinctrl".

- compatible:	Must be "brcm,bcm11351-pinctrl"

- reg:		Base address of the PAD Controller register block and the size

		of the block.

For example, the following is the bare minimum node:

	pinctrl@35004800 {

		compatible = "brcm,capri-pinctrl";

		compatible = "brcm,bcm11351-pinctrl";

		reg = <0x35004800 0x430>;

	};

Example:

// pin controller node

pinctrl@35004800 {

	compatible = "brcm,capri-pinctrl";

	compatible = "brcmbcm11351-pinctrl";

	reg = <0x35004800 0x430>;

	// pin configuration node