* [PATCH 1/6] staging:iio:core set the iio_dev.info pointer to null on unregister under lock.
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
@ 2012-02-15 19:48 ` Jonathan Cameron
2012-02-15 19:48 ` [PATCH 2/6] staging:iio:core add in kernel interface mapping and getting IIO channels Jonathan Cameron
` (6 subsequent siblings)
7 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 19:48 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron
This prevents use of provider callbacks after it has been unregistered.
Note that all code using this that can be called from a consumer *must*
check the pointer before using and hold the info_exist_lock throughout
the usage of the callbacks in info.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/iio.h | 2 ++
drivers/staging/iio/industrialio-core.c | 4 ++++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/iio.h b/drivers/staging/iio/iio.h
index be6ced3..478dbe5 100644
--- a/drivers/staging/iio/iio.h
+++ b/drivers/staging/iio/iio.h
@@ -310,6 +310,7 @@ struct iio_buffer_setup_ops {
* @chan_attr_group: [INTERN] group for all attrs in base directory
* @name: [DRIVER] name of the device.
* @info: [DRIVER] callbacks and constant info from driver
+ * @info_exist_lock: [INTERN] lock to prevent use during removal
* @chrdev: [INTERN] associated character device
* @groups: [INTERN] attribute groups
* @groupcounter: [INTERN] index of next attribute group
@@ -340,6 +341,7 @@ struct iio_dev {
struct attribute_group chan_attr_group;
const char *name;
const struct iio_info *info;
+ struct mutex info_exist_lock;
const struct iio_buffer_setup_ops *setup_ops;
struct cdev chrdev;
#define IIO_MAX_GROUPS 6
diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c
index e4824fe..3a2d080 100644
--- a/drivers/staging/iio/industrialio-core.c
+++ b/drivers/staging/iio/industrialio-core.c
@@ -594,6 +594,7 @@ struct iio_dev *iio_allocate_device(int sizeof_priv)
device_initialize(&dev->dev);
dev_set_drvdata(&dev->dev, (void *)dev);
mutex_init(&dev->mlock);
+ mutex_init(&dev->info_exist_lock);
dev->id = ida_simple_get(&iio_ida, 0, 0, GFP_KERNEL);
if (dev->id < 0) {
@@ -718,6 +719,9 @@ EXPORT_SYMBOL(iio_device_register);
void iio_device_unregister(struct iio_dev *indio_dev)
{
+ mutex_lock(&indio_dev->info_exist_lock);
+ indio_dev->info = NULL;
+ mutex_unlock(&indio_dev->info_exist_lock);
device_unregister(&indio_dev->dev);
}
EXPORT_SYMBOL(iio_device_unregister);
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* [PATCH 2/6] staging:iio:core add in kernel interface mapping and getting IIO channels.
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
2012-02-15 19:48 ` [PATCH 1/6] staging:iio:core set the iio_dev.info pointer to null on unregister under lock Jonathan Cameron
@ 2012-02-15 19:48 ` Jonathan Cameron
2012-02-15 19:48 ` [PATCH 3/6] staging:iio: move iio data return types into types.h for use by inkern Jonathan Cameron
` (5 subsequent siblings)
7 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 19:48 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron, Jonathan Cameron
From: Jonathan Cameron <jic23@cam.ac.uk>
Lifted from proposal for in kernel interface built on the out of staging
branch.
Two elements here:
* Map as defined in "inkern.h"
* Matching code to actually get the iio_dev and channel
that we want from the global list of IIO devices.
V4: Everything now built if iio is built (rather than being optional)
Removal race condition prevented by using info pointer as a check
of removal under a lock.
V3: Drop the option of registering / getting channels using dev pointer.
Stick to name only as suggested by Mark Brown (this has caused user
confusion in the regulator framework.)
V2: As per Greg KH suggestion, move over to registration by passing
the tables into the provider drivers (how regulator does it).
This does not prevent us using the original more flexible approach
if at a later date there is a usecase that demands it.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/Makefile | 2 +-
drivers/staging/iio/consumer.h | 96 +++++++++++++
drivers/staging/iio/driver.h | 34 +++++
drivers/staging/iio/inkern.c | 292 ++++++++++++++++++++++++++++++++++++++++
drivers/staging/iio/machine.h | 24 ++++
5 files changed, 447 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/iio/Makefile b/drivers/staging/iio/Makefile
index 657710b..ff059d4 100644
--- a/drivers/staging/iio/Makefile
+++ b/drivers/staging/iio/Makefile
@@ -3,7 +3,7 @@
#
obj-$(CONFIG_IIO) += industrialio.o
-industrialio-y := industrialio-core.o industrialio-event.o
+industrialio-y := industrialio-core.o industrialio-event.o inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
diff --git a/drivers/staging/iio/consumer.h b/drivers/staging/iio/consumer.h
new file mode 100644
index 0000000..36a060c
--- /dev/null
+++ b/drivers/staging/iio/consumer.h
@@ -0,0 +1,96 @@
+/*
+ * Industrial I/O in kernel consumer interface
+ *
+ * Copyright (c) 2011 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#ifndef _IIO_INKERN_CONSUMER_H_
+#define _IIO_INKERN_CONSUMER_H
+#include "types.h"
+
+struct iio_dev;
+struct iio_chan_spec;
+
+/**
+ * struct iio_channel - everything needed for a consumer to use a channel
+ * @indio_dev: Device on which the channel exists.
+ * @channel: Full description of the channel.
+ */
+struct iio_channel {
+ struct iio_dev *indio_dev;
+ const struct iio_chan_spec *channel;
+};
+
+/**
+ * iio_channel_get() - get description of all that is needed to access channel.
+ * @name: Unique name of the device as provided in the iio_map
+ * with which the desired provider to consumer mapping
+ * was registered.
+ * @consumer_channel: Unique name to identify the channel on the consumer
+ * side. This typically describes the channels use within
+ * the consumer. E.g. 'battery_voltage'
+ */
+struct iio_channel *iio_st_channel_get(const char *name,
+ const char *consumer_channel);
+
+/**
+ * iio_st_channel_release() - release channels obtained via iio_st_channel_get
+ * @chan: The channel to be released.
+ */
+void iio_st_channel_release(struct iio_channel *chan);
+
+/**
+ * iio_st_channel_get_all() - get all channels associated with a client
+ * @name: name of consumer device.
+ *
+ * Returns an array of iio_channel structures terminated with one with
+ * null iio_dev pointer.
+ * This function is used by fairly generic consumers to get all the
+ * channels registered as having this consumer.
+ */
+struct iio_channel *iio_st_channel_get_all(const char *name);
+
+/**
+ * iio_st_channel_release_all() - reverse iio_st_get_all
+ * @chan: Array of channels to be released.
+ */
+void iio_st_channel_release_all(struct iio_channel *chan);
+
+/**
+ * iio_st_read_channel_raw() - read from a given channel
+ * @channel: The channel being queried.
+ * @val: Value read back.
+ *
+ * Note raw reads from iio channels are in adc counts and hence
+ * scale will need to be applied if standard units required.
+ */
+int iio_st_read_channel_raw(struct iio_channel *chan,
+ int *val);
+
+/**
+ * iio_st_get_channel_type() - get the type of a channel
+ * @channel: The channel being queried.
+ * @type: The type of the channel.
+ *
+ * returns the enum iio_chan_type of the channel
+ */
+int iio_st_get_channel_type(struct iio_channel *channel,
+ enum iio_chan_type *type);
+
+/**
+ * iio_st_read_channel_scale() - read the scale value for a channel
+ * @channel: The channel being queried.
+ * @val: First part of value read back.
+ * @val2: Second part of value read back.
+ *
+ * Note returns a description of what is in val and val2, such
+ * as IIO_VAL_INT_PLUS_MICRO telling us we have a value of val
+ * + val2/1e6
+ */
+int iio_st_read_channel_scale(struct iio_channel *chan, int *val,
+ int *val2);
+
+#endif
diff --git a/drivers/staging/iio/driver.h b/drivers/staging/iio/driver.h
new file mode 100644
index 0000000..a4f8b2e
--- /dev/null
+++ b/drivers/staging/iio/driver.h
@@ -0,0 +1,34 @@
+/*
+ * Industrial I/O in kernel access map interface.
+ *
+ * Copyright (c) 2011 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#ifndef _IIO_INKERN_H_
+#define _IIO_INKERN_H_
+
+struct iio_map;
+
+/**
+ * iio_map_array_register() - tell the core about inkernel consumers
+ * @indio_dev: provider device
+ * @map: array of mappings specifying association of channel with client
+ */
+int iio_map_array_register(struct iio_dev *indio_dev,
+ struct iio_map *map);
+
+/**
+ * iio_map_array_unregister() - tell the core to remove consumer mappings
+ * @indio_dev: provider device
+ * @map: array of mappings to remove. Note these must have same memory
+ * addresses as those originally added not just equal parameter
+ * values.
+ */
+int iio_map_array_unregister(struct iio_dev *indio_dev,
+ struct iio_map *map);
+
+#endif
diff --git a/drivers/staging/iio/inkern.c b/drivers/staging/iio/inkern.c
new file mode 100644
index 0000000..de2c8ea
--- /dev/null
+++ b/drivers/staging/iio/inkern.c
@@ -0,0 +1,292 @@
+/* The industrial I/O core in kernel channel mapping
+ *
+ * Copyright (c) 2011 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+
+#include "iio.h"
+#include "iio_core.h"
+#include "machine.h"
+#include "driver.h"
+#include "consumer.h"
+
+struct iio_map_internal {
+ struct iio_dev *indio_dev;
+ struct iio_map *map;
+ struct list_head l;
+};
+
+static LIST_HEAD(iio_map_list);
+static DEFINE_MUTEX(iio_map_list_lock);
+
+int iio_map_array_register(struct iio_dev *indio_dev, struct iio_map *maps)
+{
+ int i = 0, ret = 0;
+ struct iio_map_internal *mapi;
+
+ if (maps == NULL)
+ return 0;
+
+ mutex_lock(&iio_map_list_lock);
+ while (maps[i].consumer_dev_name != NULL) {
+ mapi = kzalloc(sizeof(*mapi), GFP_KERNEL);
+ if (mapi == NULL) {
+ ret = -ENOMEM;
+ goto error_ret;
+ }
+ mapi->map = &maps[i];
+ mapi->indio_dev = indio_dev;
+ list_add(&mapi->l, &iio_map_list);
+ i++;
+ }
+error_ret:
+ mutex_unlock(&iio_map_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_map_array_register);
+
+
+/* Assumes the exact same array (e.g. memory locations)
+ * used at unregistration as used at registration rather than
+ * more complex checking of contents.
+ */
+int iio_map_array_unregister(struct iio_dev *indio_dev,
+ struct iio_map *maps)
+{
+ int i = 0, ret = 0;
+ bool found_it;
+ struct iio_map_internal *mapi;
+
+ if (maps == NULL)
+ return 0;
+
+ mutex_lock(&iio_map_list_lock);
+ while (maps[i].consumer_dev_name != NULL) {
+ found_it = false;
+ list_for_each_entry(mapi, &iio_map_list, l)
+ if (&maps[i] == mapi->map) {
+ list_del(&mapi->l);
+ kfree(mapi);
+ found_it = true;
+ break;
+ }
+ if (found_it == false) {
+ ret = -ENODEV;
+ goto error_ret;
+ }
+ }
+error_ret:
+ mutex_unlock(&iio_map_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_map_array_unregister);
+
+static const struct iio_chan_spec
+*iio_chan_spec_from_name(const struct iio_dev *indio_dev,
+ const char *name)
+{
+ int i;
+ const struct iio_chan_spec *chan = NULL;
+
+ for (i = 0; i < indio_dev->num_channels; i++)
+ if (indio_dev->channels[i].datasheet_name &&
+ strcmp(name, indio_dev->channels[i].datasheet_name) == 0) {
+ chan = &indio_dev->channels[i];
+ break;
+ }
+ return chan;
+}
+
+
+struct iio_channel *iio_st_channel_get(const char *name,
+ const char *channel_name)
+{
+ struct iio_map_internal *c_i = NULL, *c = NULL;
+ struct iio_channel *channel;
+
+ if (name == NULL && channel_name == NULL)
+ return ERR_PTR(-ENODEV);
+
+ /* first find matching entry the channel map */
+ mutex_lock(&iio_map_list_lock);
+ list_for_each_entry(c_i, &iio_map_list, l) {
+ if ((name && strcmp(name, c_i->map->consumer_dev_name) != 0) ||
+ (channel_name &&
+ strcmp(channel_name, c_i->map->consumer_channel) != 0))
+ continue;
+ c = c_i;
+ get_device(&c->indio_dev->dev);
+ break;
+ }
+ mutex_unlock(&iio_map_list_lock);
+ if (c == NULL)
+ return ERR_PTR(-ENODEV);
+
+ channel = kmalloc(sizeof(*channel), GFP_KERNEL);
+ if (channel == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ channel->indio_dev = c->indio_dev;
+
+ if (c->map->adc_channel_label)
+ channel->channel =
+ iio_chan_spec_from_name(channel->indio_dev,
+ c->map->adc_channel_label);
+
+ return channel;
+}
+EXPORT_SYMBOL_GPL(iio_st_channel_get);
+
+void iio_st_channel_release(struct iio_channel *channel)
+{
+ put_device(&channel->indio_dev->dev);
+ kfree(channel);
+}
+EXPORT_SYMBOL_GPL(iio_st_channel_release);
+
+struct iio_channel *iio_st_channel_get_all(const char *name)
+{
+ struct iio_channel *chans;
+ struct iio_map_internal *c = NULL;
+ int nummaps = 0;
+ int mapind = 0;
+ int i, ret;
+
+ if (name == NULL)
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(&iio_map_list_lock);
+ /* first count the matching maps */
+ list_for_each_entry(c, &iio_map_list, l)
+ if (name && strcmp(name, c->map->consumer_dev_name) != 0)
+ continue;
+ else
+ nummaps++;
+
+ if (nummaps == 0) {
+ ret = -ENODEV;
+ goto error_ret;
+ }
+
+ /* NULL terminated array to save passing size */
+ chans = kzalloc(sizeof(*chans)*(nummaps + 1), GFP_KERNEL);
+ if (chans == NULL) {
+ ret = -ENOMEM;
+ goto error_ret;
+ }
+
+ /* for each map fill in the chans element */
+ list_for_each_entry(c, &iio_map_list, l) {
+ if (name && strcmp(name, c->map->consumer_dev_name) != 0)
+ continue;
+ chans[mapind].indio_dev = c->indio_dev;
+ chans[mapind].channel =
+ iio_chan_spec_from_name(chans[mapind].indio_dev,
+ c->map->adc_channel_label);
+ if (chans[mapind].channel == NULL) {
+ ret = -EINVAL;
+ put_device(&chans[mapind].indio_dev->dev);
+ goto error_free_chans;
+ }
+ get_device(&chans[mapind].indio_dev->dev);
+ mapind++;
+ }
+ mutex_unlock(&iio_map_list_lock);
+ if (mapind == 0) {
+ ret = -ENODEV;
+ goto error_free_chans;
+ }
+ return chans;
+
+error_free_chans:
+ for (i = 0; i < nummaps; i++)
+ if (chans[i].indio_dev)
+ put_device(&chans[i].indio_dev->dev);
+ kfree(chans);
+error_ret:
+ mutex_unlock(&iio_map_list_lock);
+
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(iio_st_channel_get_all);
+
+void iio_st_channel_release_all(struct iio_channel *channels)
+{
+ struct iio_channel *chan = &channels[0];
+
+ while (chan->indio_dev) {
+ put_device(&chan->indio_dev->dev);
+ chan++;
+ }
+ kfree(channels);
+}
+EXPORT_SYMBOL_GPL(iio_st_channel_release_all);
+
+int iio_st_read_channel_raw(struct iio_channel *chan, int *val)
+{
+ int val2, ret;
+
+ mutex_lock(&chan->indio_dev->info_exist_lock);
+ if (chan->indio_dev->info == NULL) {
+ ret = -ENODEV;
+ goto err_unlock;
+ }
+
+ ret = chan->indio_dev->info->read_raw(chan->indio_dev, chan->channel,
+ val, &val2, 0);
+err_unlock:
+ mutex_unlock(&chan->indio_dev->info_exist_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_st_read_channel_raw);
+
+int iio_st_read_channel_scale(struct iio_channel *chan, int *val, int *val2)
+{
+ int ret;
+
+ mutex_lock(&chan->indio_dev->info_exist_lock);
+ if (chan->indio_dev->info == NULL) {
+ ret = -ENODEV;
+ goto err_unlock;
+ }
+
+ ret = chan->indio_dev->info->read_raw(chan->indio_dev,
+ chan->channel,
+ val, val2,
+ IIO_CHAN_INFO_SCALE);
+err_unlock:
+ mutex_unlock(&chan->indio_dev->info_exist_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_st_read_channel_scale);
+
+int iio_st_get_channel_type(struct iio_channel *chan,
+ enum iio_chan_type *type)
+{
+ int ret = 0;
+ /* Need to verify underlying driver has not gone away */
+
+ mutex_lock(&chan->indio_dev->info_exist_lock);
+ if (chan->indio_dev->info == NULL) {
+ ret = -ENODEV;
+ goto err_unlock;
+ }
+
+ *type = chan->channel->type;
+err_unlock:
+ mutex_unlock(&chan->indio_dev->info_exist_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_st_get_channel_type);
diff --git a/drivers/staging/iio/machine.h b/drivers/staging/iio/machine.h
new file mode 100644
index 0000000..0b1f19b
--- /dev/null
+++ b/drivers/staging/iio/machine.h
@@ -0,0 +1,24 @@
+/*
+ * Industrial I/O in kernel access map definitions for board files.
+ *
+ * Copyright (c) 2011 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+/**
+ * struct iio_map - description of link between consumer and device channels
+ * @adc_channel_label: Label used to identify the channel on the provider.
+ * This is matched against the datasheet_name element
+ * of struct iio_chan_spec.
+ * @consumer_dev_name: Name to uniquely identify the consumer device.
+ * @consumer_channel: Unique name used to idenitify the channel on the
+ * consumer side.
+ */
+struct iio_map {
+ const char *adc_channel_label;
+ const char *consumer_dev_name;
+ const char *consumer_channel;
+};
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* [PATCH 3/6] staging:iio: move iio data return types into types.h for use by inkern
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
2012-02-15 19:48 ` [PATCH 1/6] staging:iio:core set the iio_dev.info pointer to null on unregister under lock Jonathan Cameron
2012-02-15 19:48 ` [PATCH 2/6] staging:iio:core add in kernel interface mapping and getting IIO channels Jonathan Cameron
@ 2012-02-15 19:48 ` Jonathan Cameron
2012-02-15 19:48 ` [PATCH 4/6] staging:iio::hwmon interface client driver Jonathan Cameron
` (4 subsequent siblings)
7 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 19:48 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron, Jonathan Cameron
From: Jonathan Cameron <jic23@cam.ac.uk>
In kernel interfaces need these, so make them available.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/iio.h | 6 ------
drivers/staging/iio/types.h | 4 ++++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/iio/iio.h b/drivers/staging/iio/iio.h
index 478dbe5..9459c17 100644
--- a/drivers/staging/iio/iio.h
+++ b/drivers/staging/iio/iio.h
@@ -197,12 +197,6 @@ static inline s64 iio_get_time_ns(void)
#define INDIO_ALL_BUFFER_MODES \
(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE)
-/* Vast majority of this is set by the industrialio subsystem on a
- * call to iio_device_register. */
-#define IIO_VAL_INT 1
-#define IIO_VAL_INT_PLUS_MICRO 2
-#define IIO_VAL_INT_PLUS_NANO 3
-
struct iio_trigger; /* forward declaration */
struct iio_dev;
diff --git a/drivers/staging/iio/types.h b/drivers/staging/iio/types.h
index b7d2647..0c32136 100644
--- a/drivers/staging/iio/types.h
+++ b/drivers/staging/iio/types.h
@@ -46,4 +46,8 @@ enum iio_modifier {
IIO_MOD_LIGHT_IR,
};
+#define IIO_VAL_INT 1
+#define IIO_VAL_INT_PLUS_MICRO 2
+#define IIO_VAL_INT_PLUS_NANO 3
+
#endif /* _IIO_TYPES_H_ */
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* [PATCH 4/6] staging:iio::hwmon interface client driver.
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
` (2 preceding siblings ...)
2012-02-15 19:48 ` [PATCH 3/6] staging:iio: move iio data return types into types.h for use by inkern Jonathan Cameron
@ 2012-02-15 19:48 ` Jonathan Cameron
2012-02-15 19:48 ` [PATCH 5/6] staging:iio:Documentation in kernel pull description Jonathan Cameron
` (3 subsequent siblings)
7 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 19:48 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron, Jonathan Cameron
From: Jonathan Cameron <jic23@cam.ac.uk>
Direct copy of version proposed for the non staging branch.
Needed here to allow testing of more advanced inkernel
interface code.
Minimal support of simple in, curr and temp attributes
so far.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/Kconfig | 7 +
drivers/staging/iio/Makefile | 2 +
drivers/staging/iio/iio_hwmon.c | 232 +++++++++++++++++++++++++++++++++++++++
3 files changed, 241 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/Kconfig b/drivers/staging/iio/Kconfig
index 90162aa..24c6ed9 100644
--- a/drivers/staging/iio/Kconfig
+++ b/drivers/staging/iio/Kconfig
@@ -11,6 +11,13 @@ menuconfig IIO
number of different physical interfaces (i2c, spi, etc). See
drivers/staging/iio/Documentation for more information.
if IIO
+config IIO_ST_HWMON
+ tristate "Hwmon driver that uses channels specified via iio maps"
+ depends on HWMON
+ 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.
config IIO_BUFFER
bool "Enable buffer support within IIO"
diff --git a/drivers/staging/iio/Makefile b/drivers/staging/iio/Makefile
index ff059d4..5075291 100644
--- a/drivers/staging/iio/Makefile
+++ b/drivers/staging/iio/Makefile
@@ -17,6 +17,8 @@ iio_dummy-$(CONFIG_IIO_SIMPLE_DUMMY_BUFFER) += iio_simple_dummy_buffer.o
obj-$(CONFIG_IIO_DUMMY_EVGEN) += iio_dummy_evgen.o
+obj-$(CONFIG_IIO_ST_HWMON) += iio_hwmon.o
+
obj-y += accel/
obj-y += adc/
obj-y += addac/
diff --git a/drivers/staging/iio/iio_hwmon.c b/drivers/staging/iio/iio_hwmon.c
new file mode 100644
index 0000000..a603a5f
--- /dev/null
+++ b/drivers/staging/iio/iio_hwmon.c
@@ -0,0 +1,232 @@
+/* Hwmon client for industrial I/O devices
+ *
+ * Copyright (c) 2011 Jonathan Cameron
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include "consumer.h"
+#include "types.h"
+
+/**
+ * struct iio_hwmon_state - device instance state
+ * @channels: filled with array of channels from iio
+ * @num_channels: number of channels in channels (saves counting twice)
+ * @hwmon_dev: associated hwmon device
+ * @attr_group: the group of attributes
+ * @attrs: null terminated array of attribute pointers.
+ */
+struct iio_hwmon_state {
+ struct iio_channel *channels;
+ int num_channels;
+ struct device *hwmon_dev;
+ struct attribute_group attr_group;
+ struct attribute **attrs;
+};
+
+/*
+ * Assumes that IIO and hwmon operate in the same base units.
+ * This is supposed to be true, but needs verification for
+ * new channel types.
+ */
+static ssize_t iio_hwmon_read_val(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ long result;
+ int val, ret, scaleint, scalepart;
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ struct iio_hwmon_state *state = dev_get_drvdata(dev);
+
+ /*
+ * No locking between this pair, so theoretically possible
+ * the scale has changed.
+ */
+ ret = iio_st_read_channel_raw(&state->channels[sattr->index],
+ &val);
+ if (ret < 0)
+ return ret;
+
+ ret = iio_st_read_channel_scale(&state->channels[sattr->index],
+ &scaleint, &scalepart);
+ if (ret < 0)
+ return ret;
+ switch (ret) {
+ case IIO_VAL_INT:
+ result = val * scaleint;
+ break;
+ case IIO_VAL_INT_PLUS_MICRO:
+ result = (s64)val * (s64)scaleint +
+ div_s64((s64)val * (s64)scalepart, 1000000LL);
+ break;
+ case IIO_VAL_INT_PLUS_NANO:
+ result = (s64)val * (s64)scaleint +
+ div_s64((s64)val * (s64)scalepart, 1000000000LL);
+ break;
+ default:
+ return -EINVAL;
+ }
+ return sprintf(buf, "%ld\n", result);
+}
+
+static void iio_hwmon_free_attrs(struct iio_hwmon_state *st)
+{
+ int i;
+ struct sensor_device_attribute *a;
+ for (i = 0; i < st->num_channels; i++)
+ if (st->attrs[i]) {
+ a = to_sensor_dev_attr(
+ container_of(st->attrs[i],
+ struct device_attribute,
+ attr));
+ kfree(a);
+ }
+}
+
+static int __devinit iio_hwmon_probe(struct platform_device *pdev)
+{
+ struct iio_hwmon_state *st;
+ struct sensor_device_attribute *a;
+ int ret, i;
+ int in_i = 1, temp_i = 1, curr_i = 1;
+ enum iio_chan_type type;
+
+ st = kzalloc(sizeof(*st), GFP_KERNEL);
+ if (st == NULL) {
+ ret = -ENOMEM;
+ goto error_ret;
+ }
+
+ st->channels = iio_st_channel_get_all(dev_name(&pdev->dev));
+ if (IS_ERR(st->channels)) {
+ ret = PTR_ERR(st->channels);
+ goto error_free_state;
+ }
+
+ /* count how many attributes we have */
+ while (st->channels[st->num_channels].indio_dev)
+ st->num_channels++;
+
+ st->attrs = kzalloc(sizeof(st->attrs) * (st->num_channels + 1),
+ GFP_KERNEL);
+ if (st->attrs == NULL) {
+ ret = -ENOMEM;
+ goto error_release_channels;
+ }
+ for (i = 0; i < st->num_channels; i++) {
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (a == NULL) {
+ ret = -ENOMEM;
+ goto error_free_attrs;
+ }
+
+ sysfs_attr_init(&a->dev_attr.attr);
+ ret = iio_st_get_channel_type(&st->channels[i], &type);
+ if (ret < 0) {
+ kfree(a);
+ goto error_free_attrs;
+ }
+ switch (type) {
+ case IIO_VOLTAGE:
+ a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
+ "in%d_input",
+ in_i++);
+ break;
+ case IIO_TEMP:
+ a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
+ "temp%d_input",
+ temp_i++);
+ break;
+ case IIO_CURRENT:
+ a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
+ "curr%d_input",
+ curr_i++);
+ break;
+ default:
+ ret = -EINVAL;
+ kfree(a);
+ goto error_free_attrs;
+ }
+ if (a->dev_attr.attr.name == NULL) {
+ kfree(a);
+ ret = -ENOMEM;
+ goto error_free_attrs;
+ }
+ a->dev_attr.show = iio_hwmon_read_val;
+ a->dev_attr.attr.mode = S_IRUGO;
+ a->index = i;
+ st->attrs[i] = &a->dev_attr.attr;
+ }
+
+ st->attr_group.attrs = st->attrs;
+ platform_set_drvdata(pdev, st);
+ ret = sysfs_create_group(&pdev->dev.kobj, &st->attr_group);
+ if (ret < 0)
+ goto error_free_attrs;
+
+ st->hwmon_dev = hwmon_device_register(&pdev->dev);
+ if (IS_ERR(st->hwmon_dev)) {
+ ret = PTR_ERR(st->hwmon_dev);
+ goto error_remove_group;
+ }
+ return 0;
+
+error_remove_group:
+ sysfs_remove_group(&pdev->dev.kobj, &st->attr_group);
+error_free_attrs:
+ iio_hwmon_free_attrs(st);
+ kfree(st->attrs);
+error_release_channels:
+ iio_st_channel_release_all(st->channels);
+error_free_state:
+ kfree(st);
+error_ret:
+ return ret;
+}
+
+static int __devexit iio_hwmon_remove(struct platform_device *pdev)
+{
+ struct iio_hwmon_state *st = platform_get_drvdata(pdev);
+
+ hwmon_device_unregister(st->hwmon_dev);
+ sysfs_remove_group(&pdev->dev.kobj, &st->attr_group);
+ iio_hwmon_free_attrs(st);
+ kfree(st->attrs);
+ iio_st_channel_release_all(st->channels);
+
+ return 0;
+}
+
+static struct platform_driver __refdata iio_hwmon_driver = {
+ .driver = {
+ .name = "iio_hwmon",
+ .owner = THIS_MODULE,
+ },
+ .probe = iio_hwmon_probe,
+ .remove = __devexit_p(iio_hwmon_remove),
+};
+
+static int iio_inkern_init(void)
+{
+ return platform_driver_register(&iio_hwmon_driver);
+}
+module_init(iio_inkern_init);
+
+static void iio_inkern_exit(void)
+{
+ platform_driver_unregister(&iio_hwmon_driver);
+}
+module_exit(iio_inkern_exit);
+
+MODULE_AUTHOR("Jonathan Cameron <jic23@cam.ac.uk>");
+MODULE_DESCRIPTION("IIO to hwmon driver");
+MODULE_LICENSE("GPL v2");
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* [PATCH 5/6] staging:iio:Documentation in kernel pull description.
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
` (3 preceding siblings ...)
2012-02-15 19:48 ` [PATCH 4/6] staging:iio::hwmon interface client driver Jonathan Cameron
@ 2012-02-15 19:48 ` Jonathan Cameron
2012-02-15 19:48 ` [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example Jonathan Cameron
` (2 subsequent siblings)
7 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 19:48 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron
Very basic description of the way iio consumers work and how to use
this functionality.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/Documentation/inkernel.txt | 58 ++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/Documentation/inkernel.txt b/drivers/staging/iio/Documentation/inkernel.txt
new file mode 100644
index 0000000..a05823e
--- /dev/null
+++ b/drivers/staging/iio/Documentation/inkernel.txt
@@ -0,0 +1,58 @@
+Industrial I/O Subsystem in kernel consumers.
+
+The IIO subsystem can act as a layer under other elements of the kernel
+providing a means of obtaining ADC type readings or of driving DAC type
+signals. The functionality supported will grow as use cases arise.
+
+Describing the channel mapping (iio/machine.h)
+
+Channel associations are described using:
+
+struct iio_map {
+ const char *adc_channel_label;
+ const char *consumer_dev_name;
+ const char *consumer_channel;
+};
+
+adc_channel_label identifies the channel on the IIO device by being
+matched against the datasheet_name field of the iio_chan_spec.
+
+consumer_dev_name allows identification of the consumer device.
+This are then used to find the channel mapping from the consumer device (see
+below).
+
+Finally consumer_channel is a string identifying the channel to the consumer.
+(Perhaps 'battery_voltage' or similar).
+
+An array of these structures is then passed to the IIO driver.
+
+Supporting in kernel interfaces in the driver (driver.h)
+
+The driver must provide datasheet_name values for its channels and
+must pass the iio_map structures and a pointer to its own iio_dev structure
+ on to the core via a call to iio_map_array_register. On removal,
+iio_map_array_unregister reverses this process.
+
+The result of this is that the IIO core now has all the information needed
+to associate a given channel with the consumer requesting it.
+
+Acting as an IIO consumer (consumer.h)
+
+The consumer first has to obtain an iio_channel structure from the core
+by calling iio_channel_get(). The correct channel is identified by:
+
+* matching dev or dev_name against consumer_dev and consumer_dev_name
+* matching consumer_channel against consumer_channel in the map
+
+There are then a number of functions that can be used to get information
+about this channel such as it's current reading.
+
+e.g.
+iio_st_read_channel_raw() - get a reading
+iio_st_read_channel_type() - get the type of channel
+
+There is also provision for retrieving all of the channels associated
+with a given consumer. This is useful for generic drivers such as
+iio_hwmon where the number and naming of channels is not known by the
+consumer driver. To do this, use iio_st_channel_get_all.
+
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
` (4 preceding siblings ...)
2012-02-15 19:48 ` [PATCH 5/6] staging:iio:Documentation in kernel pull description Jonathan Cameron
@ 2012-02-15 19:48 ` Jonathan Cameron
2012-02-15 21:07 ` Jonathan Cameron
2012-02-15 21:11 ` [PATCH 5.5/6] staging:iio:max1363 enable use with inkernel interfaces Jonathan Cameron
2012-02-15 21:50 ` [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Linus Walleij
7 siblings, 1 reply; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 19:48 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron
From: Jonathan Cameron <jic23@cam.ac.uk>
Do not commit.
---
arch/arm/mach-pxa/stargate2.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-pxa/stargate2.c b/arch/arm/mach-pxa/stargate2.c
index b0656e15..ce7f0a3 100644
--- a/arch/arm/mach-pxa/stargate2.c
+++ b/arch/arm/mach-pxa/stargate2.c
@@ -54,6 +54,8 @@
#include <linux/mfd/da903x.h>
#include <linux/sht15.h>
+#include "../../../drivers/staging/iio/machine.h"
+
#include "devices.h"
#include "generic.h"
@@ -406,6 +408,25 @@ static struct i2c_pxa_platform_data i2c_pdata = {
.fast_mode = 1,
};
+static struct iio_map max1363_consumer_map[] = {
+ {
+ .adc_channel_label = "AIN1",
+ .consumer_dev_name = "iio_hwmon.0",
+ .consumer_channel = "testchan1",
+ }, {
+ .adc_channel_label = "AIN2",
+ .consumer_dev_name = "iio_hwmon.0",
+ .consumer_channel = "testchan2",
+ },
+ {}
+};
+
+static struct platform_device iio_hwmon_test = {
+ .name = "iio_hwmon",
+};
+
+
+
static void __init imote2_stargate2_init(void)
{
@@ -561,6 +582,7 @@ static struct i2c_board_info __initdata imote2_i2c_board_info[] = {
* pull up resistors are missing.
*/
.irq = PXA_GPIO_TO_IRQ(99),
+ .platform_data = max1363_consumer_map,
}, { /* ITS400 Sensor board only */
.type = "tsl2561",
.addr = 0x49,
@@ -945,6 +967,7 @@ static struct i2c_board_info __initdata stargate2_i2c_board_info[] = {
* pull up resistors are missing.
*/
.irq = PXA_GPIO_TO_IRQ(99),
+ .platform_data = max1363_consumer_map,
}, { /* ITS400 Sensor board only */
.type = "tsl2561",
.addr = 0x49,
@@ -977,6 +1000,7 @@ static struct platform_device *stargate2_devices[] = {
&stargate2_sram,
&smc91x_device,
&sht15,
+ &iio_hwmon_test,
};
static void __init stargate2_init(void)
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.
2012-02-15 19:48 ` [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example Jonathan Cameron
@ 2012-02-15 21:07 ` Jonathan Cameron
2012-02-24 20:07 ` Greg KH
0 siblings, 1 reply; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 21:07 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron
On 02/15/2012 07:48 PM, Jonathan Cameron wrote:
> From: Jonathan Cameron <jic23@cam.ac.uk>
>
> Do not commit.
Whilst this example was never meant to be committed, the obvious flaw
is that max1363 doesn't actually support these interfaces because
I left one patch out. Lets call it 5.5 and stick it before this one.
Sorry about that.
> ---
> arch/arm/mach-pxa/stargate2.c | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/stargate2.c b/arch/arm/mach-pxa/stargate2.c
> index b0656e15..ce7f0a3 100644
> --- a/arch/arm/mach-pxa/stargate2.c
> +++ b/arch/arm/mach-pxa/stargate2.c
> @@ -54,6 +54,8 @@
> #include <linux/mfd/da903x.h>
> #include <linux/sht15.h>
>
> +#include "../../../drivers/staging/iio/machine.h"
> +
> #include "devices.h"
> #include "generic.h"
>
> @@ -406,6 +408,25 @@ static struct i2c_pxa_platform_data i2c_pdata = {
> .fast_mode = 1,
> };
>
> +static struct iio_map max1363_consumer_map[] = {
> + {
> + .adc_channel_label = "AIN1",
> + .consumer_dev_name = "iio_hwmon.0",
> + .consumer_channel = "testchan1",
> + }, {
> + .adc_channel_label = "AIN2",
> + .consumer_dev_name = "iio_hwmon.0",
> + .consumer_channel = "testchan2",
> + },
> + {}
> +};
> +
> +static struct platform_device iio_hwmon_test = {
> + .name = "iio_hwmon",
> +};
> +
> +
> +
> static void __init imote2_stargate2_init(void)
> {
>
> @@ -561,6 +582,7 @@ static struct i2c_board_info __initdata imote2_i2c_board_info[] = {
> * pull up resistors are missing.
> */
> .irq = PXA_GPIO_TO_IRQ(99),
> + .platform_data = max1363_consumer_map,
> }, { /* ITS400 Sensor board only */
> .type = "tsl2561",
> .addr = 0x49,
> @@ -945,6 +967,7 @@ static struct i2c_board_info __initdata stargate2_i2c_board_info[] = {
> * pull up resistors are missing.
> */
> .irq = PXA_GPIO_TO_IRQ(99),
> + .platform_data = max1363_consumer_map,
> }, { /* ITS400 Sensor board only */
> .type = "tsl2561",
> .addr = 0x49,
> @@ -977,6 +1000,7 @@ static struct platform_device *stargate2_devices[] = {
> &stargate2_sram,
> &smc91x_device,
> &sht15,
> + &iio_hwmon_test,
> };
>
> static void __init stargate2_init(void)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.
2012-02-15 21:07 ` Jonathan Cameron
@ 2012-02-24 20:07 ` Greg KH
2012-02-25 11:19 ` Jonathan Cameron
0 siblings, 1 reply; 16+ messages in thread
From: Greg KH @ 2012-02-24 20:07 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio, guenter.roeck, khali, dmitry.torokhov, broonie, alan,
arnd, linus.walleij, maxime.ripard, thomas.petazzoni, zdevai,
w.sang, marek.vasut, Jonathan Cameron
On Wed, Feb 15, 2012 at 09:07:56PM +0000, Jonathan Cameron wrote:
> On 02/15/2012 07:48 PM, Jonathan Cameron wrote:
> > From: Jonathan Cameron <jic23@cam.ac.uk>
> >
> > Do not commit.
> Whilst this example was never meant to be committed, the obvious flaw
> is that max1363 doesn't actually support these interfaces because
> I left one patch out. Lets call it 5.5 and stick it before this one.
Huh? I don't understand what you mean here, should I not apply this
one?
confused,
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.
2012-02-24 20:07 ` Greg KH
@ 2012-02-25 11:19 ` Jonathan Cameron
0 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-25 11:19 UTC (permalink / raw)
To: Greg KH
Cc: Jonathan Cameron, linux-iio, guenter.roeck, khali,
dmitry.torokhov, broonie, alan, arnd, linus.walleij,
maxime.ripard, thomas.petazzoni, zdevai, w.sang, marek.vasut
On 02/24/2012 08:07 PM, Greg KH wrote:
> On Wed, Feb 15, 2012 at 09:07:56PM +0000, Jonathan Cameron wrote:
>> On 02/15/2012 07:48 PM, Jonathan Cameron wrote:
>>> From: Jonathan Cameron <jic23@cam.ac.uk>
>>>
>>> Do not commit.
>> Whilst this example was never meant to be committed, the obvious flaw
>> is that max1363 doesn't actually support these interfaces because
>> I left one patch out. Lets call it 5.5 and stick it before this one.
>
> Huh? I don't understand what you mean here, should I not apply this
> one?
Sorry, the confusion here comes from the fact that this set was not
yet meant to be a merge request but rather had been sent out for review.
You were explicitly cc'd because of the issues you had raised with the
previous version (that were hopefully fixed to your satisfaction here).
This final patch was there to show how things worked, but should
obvously not merge as it uses headers in staging from outside (under
arch). The board isn't actually wired like this anyway!
Having said that, the only reason I hadn't sent a new version was a
nasty cold so thanks for merging the first 5. The 5.5 one was only
really required to support this example, so whilst harmless it wasn't
important and I'll tack it on the next set I send out.
Thanks again for pulling these. I guess that means you are happy
with the new version!
Jonathan
>
> confused,
>
> greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 5.5/6] staging:iio:max1363 enable use with inkernel interfaces.
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
` (5 preceding siblings ...)
2012-02-15 19:48 ` [PATCH 6/6] stargate2: example of map configuration for iio to hwmon example Jonathan Cameron
@ 2012-02-15 21:11 ` Jonathan Cameron
2012-02-15 21:50 ` [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Linus Walleij
7 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2012-02-15 21:11 UTC (permalink / raw)
To: linux-iio
Cc: greg, guenter.roeck, khali, dmitry.torokhov, broonie, alan, arnd,
linus.walleij, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut, Jonathan Cameron
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
Oops patch 6 doesn't make much sense without this driver support.
drivers/staging/iio/adc/max1363_core.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/iio/adc/max1363_core.c b/drivers/staging/iio/adc/max1363_core.c
index 3a5bd20..29ab0aa 100644
--- a/drivers/staging/iio/adc/max1363_core.c
+++ b/drivers/staging/iio/adc/max1363_core.c
@@ -36,6 +36,7 @@
#include "../sysfs.h"
#include "../events.h"
#include "../buffer.h"
+#include "../driver.h"
#include "max1363.h"
@@ -1268,6 +1269,9 @@ static int __devinit max1363_probe(struct i2c_client *client,
ret = -ENOMEM;
goto error_disable_reg;
}
+ ret = iio_map_array_register(indio_dev, client->dev.platform_data);
+ if (ret < 0)
+ goto error_free_device;
st = iio_priv(indio_dev);
st->reg = reg;
/* this is only used for device removal purposes */
@@ -1281,7 +1285,7 @@ static int __devinit max1363_probe(struct i2c_client *client,
(st->chip_info->num_modes + 1), GFP_KERNEL);
if (!indio_dev->available_scan_masks) {
ret = -ENOMEM;
- goto error_free_device;
+ goto error_unregister_map;
}
for (i = 0; i < st->chip_info->num_modes; i++)
@@ -1337,6 +1341,8 @@ error_cleanup_ring:
max1363_ring_cleanup(indio_dev);
error_free_available_scan_masks:
kfree(indio_dev->available_scan_masks);
+error_unregister_map:
+ iio_map_array_unregister(indio_dev, client->dev.platform_data);
error_free_device:
iio_free_device(indio_dev);
error_disable_reg:
@@ -1363,6 +1369,7 @@ static int max1363_remove(struct i2c_client *client)
regulator_disable(reg);
regulator_put(reg);
}
+ iio_map_array_unregister(indio_dev, client->dev.platform_data);
iio_free_device(indio_dev);
return 0;
--
1.7.8.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers
2012-02-15 19:47 [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Jonathan Cameron
` (6 preceding siblings ...)
2012-02-15 21:11 ` [PATCH 5.5/6] staging:iio:max1363 enable use with inkernel interfaces Jonathan Cameron
@ 2012-02-15 21:50 ` Linus Walleij
2012-02-24 20:10 ` Greg KH
7 siblings, 1 reply; 16+ messages in thread
From: Linus Walleij @ 2012-02-15 21:50 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio, greg, guenter.roeck, khali, dmitry.torokhov, broonie,
alan, arnd, maxime.ripard, thomas.petazzoni, zdevai, w.sang,
marek.vasut
On Wed, Feb 15, 2012 at 8:47 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> Any comments?
Just this:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers
2012-02-15 21:50 ` [PATCH 0/6 V6] IIO: in kernel (as opposed to userspace) pull consumers Linus Walleij
@ 2012-02-24 20:10 ` Greg KH
0 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2012-02-24 20:10 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio, guenter.roeck, khali,
dmitry.torokhov, broonie, alan, arnd, maxime.ripard,
thomas.petazzoni, zdevai, w.sang, marek.vasut
On Wed, Feb 15, 2012 at 10:50:08PM +0100, Linus Walleij wrote:
> On Wed, Feb 15, 2012 at 8:47 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>
> > Any comments?
>
> Just this:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
I've applied the first 5, and then I got confused, care to resend the
rest if they are needed/wanted?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread