Instead of requiring the map to unregister, simply unregister all map entries
associated with the given iio device. This simplifies map removal and also works
for maps generated through devicetree.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

For chips with more than 8 bit ADC resolution, received data was always
masked against 0xfff, ie with a 12 bit mask. This can result in bad data
for chips with 10 bit resolution if those chips have higher bits set
(seen with MAX1139).

The receive buffer was defined as char array. This could result in
unintentional sign extensions if the upper bit in a received byte
was set. Since the chip is configured for unipolar mode, we never
have to handle negative values, and sign extensions are never needed.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, and __devexit
from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

use iio_triggered_buffer_setup(), iio_triggered_buffer_cleanup()
Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Instantiating the driver with no available regulator results in:

[39711.686393] i2c i2c-7: new_device: Instantiated device max1139 at 0x35
[39711.688687] BUG: unable to handle kernel paging request at fffffffffffffe13
[39711.688734] IP: [<ffffffff813e835b>] regulator_disable+0x1b/0x80
[39711.688788] PGD 1c0e067 PUD 1c0f067 PMD 0
[39711.688835] Oops: 0000 [#1] SMP

Caused by bad probe error path. Fix it.

Driver should also not attempt to free the interrupt in its error path if
none was allocated. Fix that problem as well.

Finally, testing if the regulator was allocated is not necessary in the
remove function, since the probe function bails out if this is the case.
Remove that check.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Now this driver is using kfifo we can move it out of staging.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

For historical reasons the regulator handling was a little clunky. This
patch brings it inline with a more standard ordering wrt to allocation
of the iio_device.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Seems worth clearing the old naming out to avoid any confusion in the future.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

For a long while now the max1363 core has selected the
buffer anyway. For a while I meant to make the separation
work again, but given how long it has been it is probably
time to conclude it will never happen and settle for tidying
up what we have.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Autogenerated using the following coccinelle semantic patch:

// <smpl>
@r1@
identifier driver;
identifier fn;
position p;
type T;
@@
T driver = {
 .remove =
(
 fn@p
|
 __devexit_p(fn@p)
)
};

@r2@
identifier r1.fn;
position p != r1.p;
@@
fn@p

@r3@
identifier r1.fn;
position r1.p;
@@
(
 __devexit_p(fn@p)
|
-fn@p
+__devexit_p(fn)
)

@depends on !r2@
identifier r1.fn;
@@
 static
-int fn
+int __devexit fn
 (...) { ... }

@r11@
identifier driver;
identifier fn;
position p;
type T;
@@
T driver = {
	.probe = fn@p
};

@r12@
identifier r11.fn;
position p != r11.p;
@@
fn@p

@depends on !r12@
identifier r11.fn;
@@
 static
-int fn
+int __devinit fn
 (...) { ... }
// </smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The per driver iio_chan_spec arrays are usually shared between multiple device
instances. So a single device instance may not modify the iio_chan_spec array
since this would also affect the other device instances. To make this restriction
explicit mark the per driver iio_chan_spec arrays as const.

Conversion was done automatically using the following coccinelle semantic patch:

// <smpl>
@disable optional_qualifier@
identifier channels;
@@
static
+const
struct iio_chan_spec channels[] = ...;
// </smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Replace open-coded instances of getting a iio_dev struct from a device struct
with dev_to_iio_dev().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently we use two different naming schemes in the IIO API, iio_verb_object
and iio_object_verb. E.g iio_device_register and iio_allocate_device. This
patches renames instances of the later to the former. The patch also renames allocate to
alloc as this seems to be the preferred form throughout the kernel.

In particular the following renames are performed by the patch:
	iio_put_device -> iio_device_put
	iio_allocate_device -> iio_device_alloc
	iio_free_device -> iio_device_free
	iio_get_trigger -> iio_trigger_get
	iio_put_trigger -> iio_trigger_put
	iio_allocate_trigger -> iio_trigger_alloc
	iio_free_trigger -> iio_trigger_free

The conversion was done with the following coccinelle patch with manual fixes to
comments and documentation.

<smpl>
@@
@@
-iio_put_device
+iio_device_put
@@
@@
-iio_allocate_device
+iio_device_alloc
@@
@@
-iio_free_device
+iio_device_free
@@
@@
-iio_get_trigger
+iio_trigger_get
@@
@@
-iio_put_trigger
+iio_trigger_put
@@
@@
-iio_allocate_trigger
+iio_trigger_alloc
@@
@@
-iio_free_trigger
+iio_trigger_free
</smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Step 1 in moving the IIO core out of staging.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Precursor to making value read / write attribute optional.
No processed values for adc's.

Updated to include the spear adc driver (hence introducing a
dependency on the patch that adds that driver).
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When moving over to the new sw_ring_preenable I managed to add
this callback to only one of the two iio_info structures. As
such only some devices will currently work.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The below patch fixes some comments and some typos that I have found
while reading drivers/staging/iio/*
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The core must not modify available_scan_mask, because it causes problems
with drivers where multiple instances of the driver share the same mask set.
So make this explicit by marking available scan masks as const.

The max1363 driver needs some minor adjustment to accommodate this change.
Pull scan mask allocation into a separate function.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We name this field "chan" throughout IIO with the exception of this one macro.
Rename it to be more consistent.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

No known use case and makes in kernel interface work more complex.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Kind of obvious for this device but useful
for testing purposes.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Also, the differential channels should always have been signed.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Internally the fact that say scale is shared across channels is
actually of remarkably little interest.  Hence lets not store it.
Numerous devices have weird combinations of channels sharing
scale anyway so it is not as though this was really telling
us much. Note however that we do still use the shared sysfs
attrs thus massively reducing the number of attrs in complex
drivers.

Side effect is that certain drivers that were abusing this
(mostly my work) needed to do a few more checks on what the
channel they are being queried on actually is.

This is also helpful for in kernel interfaces where we
just want to query the scale and don't care whether it
is shared with other channels or not.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently the iio framework uses bitmasks for the address field of channel info
attributes. This is for historical reasons and no longer required since it will
only ever query a single info attribute at once. This patch changes the code to
use the non-shifted iio_chan_info_enum values for the info attribute address.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Issue brought up by Lars-Peter Clausen. This is a varient of what
he suggested.

io/iio.h for driver stuff (has to include types.h)
	Sub files for the bits drivers may or may not use
	iio/sysfs.h
	iio/buffer.h (contents of current buffer_generic.h)
	(obviously anything offering events will need events.h as well)
iio/types.h for the enums that matter to both
	iio_chan_type, iio_modifier
iio/events.h for the event code stuff
	IIO_EVENT_CODE and friends.  + everything in chrdev.h  So this
	is the stuff that userspace cares about.
	Also include iio_event_type, iio_event_direction

Thus iio drivers include iio.h + as required
events.h
sysfs.h
buffer.h

in kernel users (once that interface is merged) will need inkern.h
which will pull in types.h

Userspace will need just events.h (which pulls in types.h) to get
everything they need to know about.  Buffer userspace access doesn't
currently need any core defines. All information about the data
format is passed through sysfs.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the newly introduced module_i2c_driver macro for registering I2C drivers.
This allows us to remove a few lines of boilerplate code.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Longs are not known for being 8 bits.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix a dumb lack of consideration of the effect of combining
the iio_device_unregister and iio_free_device calls into
one.  There is no valid place to free some of the sysfs
array elements.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This was originally there to avoid churn during a complex change.
Now everything is stable lets get rid of this as it is missleading
and confusing.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

They aren't always ring buffers, so just use buffer for all naming.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Nothing in this file is specific to RING buffers so rename it.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Straight forward change in the core, but required some drivers to not use
the IIO_CHAN macro as that doesn't allow setting this bit (and is
going away anyway). Hence the churn.

Tested on max1363 with a couple of supported parts.

V2: differential bit in code got 7 bits and direction 1. Reversed that.
Issue spotted by Michael - thanks!
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Acked-by: NMichael Hennerich <Michael.Hennerich@analog.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>