History log of /drivers/staging/iio/accel/kxsd9.c
Revision Date Author Comments
55e4390cb04e8b0fbae8983c3494c9e24132db1b 16-Nov-2011 Lars-Peter Clausen <lars@metafoo.de> staging:iio: Add missing MODULE_DEVICE_TABLE and MODULE_ALIAS

Quite a few iio drivers provide no MODULE_DEVICE_TABLE or MODULE_ALIAS or only
provide a MODULE_ALIAS while they have support for multiple device ids. This
prevents auto module loading from working correctly.

This patch fixes it by adding the missing MODULE_DEVICE_TABLEs and
MODULE_ALIAS'.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c8a9f8056f40f6201b84fdddb49a1c62630902c5 26-Oct-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio:treewide only use shared to decide on interfaces

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: Jonathan Cameron <jic23@cam.ac.uk>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
924f8a21dd13223cc1493a916c6769cf73e0d45e 26-Oct-2011 Lars-Peter Clausen <lars@metafoo.de> staging:iio: Do not use bitmasks for channel info addresses

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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ae6ae6fec3f7d6919e0146996df37b665c75f662 16-Nov-2011 Lars-Peter Clausen <lars@metafoo.de> staging:iio: Use module_spi_driver to register SPI driver

Use the newly introduced module_spi_driver macro for registering SPI drivers.
This allows us to remove a few lines of boilerplate code.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
d2fffd6c2fd60fe9ab63ef30758d9d43a5057549 14-Oct-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio: fix removal path to allow correct freeing.

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: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6835cb6b438b77ba82ad5a23944bbfb12128f5db 27-Sep-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio: unwind the IIO_IN -> IIO_VOLTAGE define

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: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
99c978529a40132a6f7a5f136b4362b56fc88d8c 03-Jul-2011 Paul Gortmaker <paul.gortmaker@windriver.com> staging: Add module.h to drivers/staging users

Lots of people expect module.h to just "be there" without
any #include effort. But we are crushing that. So fix those
files in staging relying on implicit module.h presence.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
d34dbee8ac8e953eb7115804bf406990f976b942 12-Aug-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.

Lots of minor bits and pieces.

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
3fd47d44860aaac5b6f55bb3522e32f32e1be9e6 27-Jun-2011 anish kumar <anish198519851985@gmail.com> staging:iio:accel:kxsd9 replace kmallocs in power_up with use of already allocated buffer.

Signed-off-by: anish kumar <anish198519851985@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ed0c012b855f6f73431b62c8db70ed5a1b0c8a25 27-Jun-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio:accel:kxsd9: allocate state with iio_dev and use iio_priv to access.

V2: Actually allocate the storage.

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6fe8135fccd66aedcc55ded70824342587fd2499 18-May-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio: implement an iio_info structure to take some of the constant elements out of iio_dev.

This was suggested by Arnd Bergmann, Other elements may well
move in here in future, but it definitely makes sense for these.

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6f7c8ee585e9db54cb29af1bdb93f29837824933 15-Apr-2011 Jonathan Cameron <jic23@cam.ac.uk> staging:iio: Add ability to allocate private data space to iio_allocate_device

Suggested by Arnd Bergmann. Note this will break ALL drivers that
are out of mainline. The fix is trivial change of
iio_allocate_device() -> iio_allocate_device(0)
Sorry if this causes issues for any one!

V2: Include new drivers in the update

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
44b759b7f0e9a493f0dbf1e273eaeaf3924338af 26-Jun-2010 Jonathan Cameron <jic23@cam.ac.uk> staging:iio:kxsd9 remove unnecessary includes

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
f3fb001191a38a81bbc3cb363af2c279609ecc7c 04-May-2010 Jonathan Cameron <jic23@cam.ac.uk> iio:staging:accelerometers move towards the new abi

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
5a0e3ad6af8660be21ca98a971cd00f331318c05 24-Mar-2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
e435bc191f6a224192b548bed8cb1893b64e7df2 18-Aug-2009 Jonathan Cameron <jic23@cam.ac.uk> Staging: IIO: kxsd9 accelerometer minimal support

This provides only very minimal support for this device.
Note that an alternate driver has been posted to the input
mailing list.

When the original LMKL discussion that led to the descision
to develop IIO occured, the question on whether the differing
requirements of IIO and input drivers made it a good idea
to have unified drivers was left as an open question.
It still is. All opinions on this question welcome.

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