Merge tag 'iio-for-3.10a' of...

Samsung Exynos Analog to Digital Converter bindings

This devicetree binding are for the new adc driver written fori

Exynos4 and upward SoCs from Samsung.

New driver handles the following

1. Supports ADC IF found on EXYNOS4412/EXYNOS5250

   and future SoCs from Samsung

2. Add ADC driver under iio/adc framework

3. Also adds the Documentation for device tree bindings

Required properties:

- compatible:		Must be "samsung,exynos-adc-v1"

				for exynos4412/5250 controllers.

			Must be "samsung,exynos-adc-v2" for

				future controllers.

- reg:			Contains ADC register address range (base address and

			length) and the address of the phy enable register.

- interrupts: 		Contains the interrupt information for the timer. The

			format is being dependent on which interrupt controller

			the Samsung device uses.

- #io-channel-cells = <1>; As ADC has multiple outputs

Note: child nodes can be added for auto probing from device tree.

Example: adding device info in dtsi file

adc: adc@12D10000 {

	compatible = "samsung,exynos-adc-v1";

	reg = <0x12D10000 0x100>, <0x10040718 0x4>;

	interrupts = <0 106 0>;

	#io-channel-cells = <1>;

	io-channel-ranges;

};

Example: Adding child nodes in dts file

adc@12D10000 {

	/* NTC thermistor is a hwmon device */

	ncp15wb473@0 {

		compatible = "ntc,ncp15wb473";

		pullup-uV = <1800000>;

		pullup-ohm = <47000>;

		pulldown-ohm = <0>;

		io-channels = <&adc 4>;

	};

};

Note: Does not apply to ADC driver under arch/arm/plat-samsung/

Note: The child node can be added under the adc node or seperately.

This binding is derived from clock bindings, and based on suggestions

from Lars-Peter Clausen [1].

Sources of IIO channels can be represented by any node in the device

tree. Those nodes are designated as IIO providers. IIO consumer

nodes use a phandle and IIO specifier pair to connect IIO provider

outputs to IIO inputs. Similar to the gpio specifiers, an IIO

specifier is an array of one or more cells identifying the IIO

output on a device. The length of an IIO specifier is defined by the

value of a #io-channel-cells property in the IIO provider node.

[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2

==IIO providers==

Required properties:

#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes

		   with a single IIO output and 1 for nodes with multiple

		   IIO outputs.

Example for a simple configuration with no trigger:

	adc: voltage-sensor@35 {

		compatible = "maxim,max1139";

		reg = <0x35>;

		#io-channel-cells = <1>;

	};

Example for a configuration with trigger:

	adc@35 {

		compatible = "some-vendor,some-adc";

		reg = <0x35>;

		adc1: iio-device@0 {

			#io-channel-cells = <1>;

			/* other properties */

		};

		adc2: iio-device@1 {

			#io-channel-cells = <1>;

			/* other properties */

		};

	};

==IIO consumers==

Required properties:

io-channels:	List of phandle and IIO specifier pairs, one pair

		for each IIO input to the device. Note: if the

		IIO provider specifies '0' for #io-channel-cells,

		then only the phandle portion of the pair will appear.

Optional properties:

io-channel-names:

		List of IIO input name strings sorted in the same

		order as the io-channels property. Consumers drivers

		will use io-channel-names to match IIO input names

		with IIO specifiers.

io-channel-ranges:

		Empty property indicating that child nodes can inherit named

		IIO channels from this node. Useful for bus nodes to provide

		and IIO channel to their children.

For example:

	device {

		io-channels = <&adc 1>, <&ref 0>;

		io-channel-names = "vcc", "vdd";

	};

This represents a device with two IIO inputs, named "vcc" and "vdd".

The vcc channel is connected to output 1 of the &adc device, and the

vdd channel is connected to output 0 of the &ref device.

==Example==

	adc: max1139@35 {

		compatible = "maxim,max1139";

		reg = <0x35>;

		#io-channel-cells = <1>;

	};

	...

	iio_hwmon {

		compatible = "iio-hwmon";

		io-channels = <&adc 0>, <&adc 1>, <&adc 2>,

			<&adc 3>, <&adc 4>, <&adc 5>,

			<&adc 6>, <&adc 7>, <&adc 8>,

			<&adc 9>;

	};

	some_consumer {

		compatible = "some-consumer";

		io-channels = <&adc 10>, <&adc 11>;

		io-channel-names = "adc1", "adc2";

	};

	  This driver can also be built as a module.  If so, the module

	  will be called ibmpex.

config SENSORS_IIO_HWMON

	tristate "Hwmon driver that uses channels specified via iio maps"

	depends on IIO

	help

	  This is a platform driver that in combination with a suitable

	  map allows IIO devices to provide basic hwmon functionality

	  for those channels specified in the map.  This map can be provided

	  either via platform data or the device tree bindings.

config SENSORS_IT87

	tristate "ITE IT87xx and compatibles"

	depends on !PPC

obj-$(CONFIG_SENSORS_I5K_AMB)	+= i5k_amb.o

obj-$(CONFIG_SENSORS_IBMAEM)	+= ibmaem.o

obj-$(CONFIG_SENSORS_IBMPEX)	+= ibmpex.o

obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o

obj-$(CONFIG_SENSORS_INA209)	+= ina209.o

obj-$(CONFIG_SENSORS_INA2XX)	+= ina2xx.o

obj-$(CONFIG_SENSORS_IT87)	+= it87.o

#include <linux/err.h>

#include <linux/platform_device.h>

#include <linux/hwmon.h>

#include <linux/of.h>

#include <linux/hwmon-sysfs.h>

#include <linux/iio/consumer.h>

#include <linux/iio/types.h>

static ssize_t show_name(struct device *dev, struct device_attribute *attr,

			 char *buf)

{

	return sprintf(buf, "iio_hwmon\n");

	const char *name = "iio_hwmon";

	if (dev->of_node && dev->of_node->name)

		name = dev->of_node->name;

	return sprintf(buf, "%s\n", name);

}

static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);