Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

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

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

                        enabled previously with setsockopt() and 

                        the PACKET_COPY_THRESH option. 

                        The number of frames than can be buffered to 

                        The number of frames that can be buffered to

                        be read with recvfrom is limited like a normal socket.

                        See the SO_RCVBUF option in the socket (7) man page.

SO_TIMESTAMPING:

Instructs the socket layer which kind of information is wanted. The

parameter is an integer with some of the following bits set. Setting

other bits is an error and doesn't change the current state.

SOF_TIMESTAMPING_TX_HARDWARE:  try to obtain send time stamp in hardware

SOF_TIMESTAMPING_TX_SOFTWARE:  if SOF_TIMESTAMPING_TX_HARDWARE is off or

                               fails, then do it in software

SOF_TIMESTAMPING_RX_HARDWARE:  return the original, unmodified time stamp

                               as generated by the hardware

SOF_TIMESTAMPING_RX_SOFTWARE:  if SOF_TIMESTAMPING_RX_HARDWARE is off or

                               fails, then do it in software

SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp

SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to

                               the system time base

SOF_TIMESTAMPING_SOFTWARE:     return system time stamp generated in

                               software

SOF_TIMESTAMPING_TX/RX determine how time stamps are generated.

SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the

following control message:

Instructs the socket layer which kind of information should be collected

and/or reported.  The parameter is an integer with some of the following

bits set. Setting other bits is an error and doesn't change the current

state.

Four of the bits are requests to the stack to try to generate

timestamps.  Any combination of them is valid.

SOF_TIMESTAMPING_TX_HARDWARE:  try to obtain send time stamps in hardware

SOF_TIMESTAMPING_TX_SOFTWARE:  try to obtain send time stamps in software

SOF_TIMESTAMPING_RX_HARDWARE:  try to obtain receive time stamps in hardware

SOF_TIMESTAMPING_RX_SOFTWARE:  try to obtain receive time stamps in software

The other three bits control which timestamps will be reported in a

generated control message.  If none of these bits are set or if none of

the set bits correspond to data that is available, then the control

message will not be generated:

SOF_TIMESTAMPING_SOFTWARE:     report systime if available

SOF_TIMESTAMPING_SYS_HARDWARE: report hwtimetrans if available

SOF_TIMESTAMPING_RAW_HARDWARE: report hwtimeraw if available

It is worth noting that timestamps may be collected for reasons other

than being requested by a particular socket with

SOF_TIMESTAMPING_[TR]X_(HARD|SOFT)WARE.  For example, most drivers that

can generate hardware receive timestamps ignore

SOF_TIMESTAMPING_RX_HARDWARE.  It is still a good idea to set that flag

in case future drivers pay attention.

If timestamps are reported, they will appear in a control message with

cmsg_level==SOL_SOCKET, cmsg_type==SO_TIMESTAMPING, and a payload like

this:

struct scm_timestamping {

	struct timespec systime;