We want the fixes in there, and it resolves a merge issue with
drivers/iio/accel/bma180.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Value from st_sensors_set_drdy_int_pin() is assigned to err here,
but that stored value is not used before it is overwritten. To fix
this we're enforcing a check on st_sensors_set_drdy_int_pin()'s
return value and if it's an error, we're returning right away.
Cc: jic23@kernel.org
Cc: linux-iio@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This can result in wrong reference count for trigger device, call
iio_trigger_get to increment reference.
Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
with Jonathan.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
This can result in wrong reference count for trigger device, call
iio_trigger_get to increment reference.
Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
with Jonathan.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
The I2C devices that make up the STMicroelectronics MEMS sensors
may be sneakily enabled by cleverly giving the device node the same
name as a string match from the platform device ID table. However
the right method is to use the compatible string.
On detection, the ST sensors use the ID string to probe and
instatiate the right sensor driver, so pass the kernel-internal ID
string in the .data field of the OF match table, and set the I2C
client name to this name when a compatible match is used.
This avoids having misc Linux-specific strings floating around in
the device tree.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This fixes the following sparse warning:
CHECK drivers/iio/common/hid-sensors/hid-sensor-attributes.c
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:346:5: warning:
symbol 'hid_sensor_get_reporting_interval' was not declared. Should it be static?
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently the STMicroelectronics sensors only support one single
platform data item: configuration of the DRDY (data ready) pin
for a particular design. Augment the core to prioritize and take
this information from the device tree if the parent device has an
assigned device node, else fall back to passed in platform data
(usually the default data).
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This allows in kernel client drivers to access this
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reviewed-by: Hartmut Knaack <knaack.h@gmx.de>
Move the 'static' keyword to beginning of definition to silence the
following compilation warning:
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:34:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
A mixed bag of fixes, many of which feel just to late for 3.15.
* hid sensors - some devices need a feature report request in order to
change power state. This isn't part of the spec, but has been observed
on several devices and does no harm to others.
* mpl3115 has had two errors in the buffer description fixed. The presure is
signed, not unsigned and the temperature has 12 bits rather than 16.
These could lead to incorrect interpretation of the data in userspace.
* tsl2x7x - the high byte of the proximity thresholds should be written along
with the low byte (which was). This could lead to interesting results
with large thresholds.
* twl4030 - a flag to specify processed values were required was not set
when initializing a reading. As such values returned were in an unknown
state. Fixed by simply initializing it appropriately.
* IIO_SIMPLE_DUMMY_BUFFER did not select IIO_BUFFER leading to randconfig
build errors.
* ak8975 was applying an unwanted le16_to_cpu conversion as the i2c framework
already performs one. As such for big endian systems, the bytes would be
in the wrong order in the magnetic field measurements reported.
* mxs-lradc - the controllable voltage dividers were not enabled / disabled for
later channels than the first one during conversion.
* at91_adc error handling returned -ENOMEM in a u8. Return value of
at91_adc_get_trigger_value_by_name changed to int thus allowing -ENOMEM and
also original values to be returned.
* mcb - mcb_request_mem returns and ERR_PTR but the caller was checking for
NULL to detect an error.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJTnLYyAAoJEFSFNJnE9BaI6r4QAK22hjl1J3xoWwOPUJhfJ5Hh
VTjwO1OxwQ1XtUN5WneeJM73eu6moXD/avG2NbX4orAkNjSXKL6+/3WAds/rYMj2
0vPiJsKsGBBlhu2w2RU80xVOPT2/XXIH3bYWDiUlr/i6DLEh8mU3kKX/yZzF+cIn
hheYnOHZzLqGH8JircScEJv+B06svZtlfoDeLYaKY03HupTvEH95mvCSZk71PxZb
A+7Qb3nDlZrpLBFKj4L5x15MIoEgopID2pX0kHLNY2DE1sopr2Z+FgSa3u/wtSEx
k/ViyHPRk1mjTrQ92RMmTF5lMts6JFCmMgpPCNmcSyRKt6Fe6KcCMiWIlSs9I69i
6KAIes5XpP7Qti5Yd4gi70uiq7fL1hR18Yhzv6IdmNdS8iJhk53YiWDYiYBgXwWS
rcOva4NsaoeLYUdNJZRtap3RLsQRKAxg7HNhL+G88rr3wCsA0P7rb6BMdFK+3MiS
BDcYe8mHIzX9tJZa4EU8kOdr+aphQeDt1nH4aZDWT3J7fo6RWrWcPMWFAcx+1jp3
VVDL6Jn8WIuxYIDFznSQ6T6tvsvuqPgCqOA0ygfzvruo3m/oWvTT/+i2YFotGH3Y
7Mlw7TACAmcuZStBLg6R0R1fD39zpfp4/+GNRxFaaB8otMPyrbizb0HBcaksQCp0
0MTbFSjuAlXZ3NhVIm2O
=RuB2
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.16a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First set of IIO fixes for the 3.16 cycle.
A mixed bag of fixes, many of which feel just to late for 3.15.
* hid sensors - some devices need a feature report request in order to
change power state. This isn't part of the spec, but has been observed
on several devices and does no harm to others.
* mpl3115 has had two errors in the buffer description fixed. The presure is
signed, not unsigned and the temperature has 12 bits rather than 16.
These could lead to incorrect interpretation of the data in userspace.
* tsl2x7x - the high byte of the proximity thresholds should be written along
with the low byte (which was). This could lead to interesting results
with large thresholds.
* twl4030 - a flag to specify processed values were required was not set
when initializing a reading. As such values returned were in an unknown
state. Fixed by simply initializing it appropriately.
* IIO_SIMPLE_DUMMY_BUFFER did not select IIO_BUFFER leading to randconfig
build errors.
* ak8975 was applying an unwanted le16_to_cpu conversion as the i2c framework
already performs one. As such for big endian systems, the bytes would be
in the wrong order in the magnetic field measurements reported.
* mxs-lradc - the controllable voltage dividers were not enabled / disabled for
later channels than the first one during conversion.
* at91_adc error handling returned -ENOMEM in a u8. Return value of
at91_adc_get_trigger_value_by_name changed to int thus allowing -ENOMEM and
also original values to be returned.
* mcb - mcb_request_mem returns and ERR_PTR but the caller was checking for
NULL to detect an error.
Some sensor hubs require a get feature report call to be issued soon after
changing the power state of the sensor. Without this, the sensor remains in
the current state. This patch adds a call soon after the power state.
This is retained as a generic call across all sensor hubs since the behavior
has been noticed on more than one implementation.
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For PROP_REPORT_INTERVAL, the spec does not mandate the presence
of the report interval unit in the feature report and expects the
default unit of measure to be used as milliseconds.
Currently, when the unit is not present, it gets set as zero leading
to issues in sampling frequency.
This patch sets the unit of measure to the default unit if it
is not defined by firmware.
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The "i < " was missing in this condition.
Fixes: 5d02edfc39 ('iio: hid-sensors: Convert units and exponent')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added an API to allow client drivers to turn ON and OFF sensors for
quick read. Added data_read as counting varaible instead of boolean,
so that sensor is powered off only when last user released it.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added interface to get poll value in milli-seconds. This value is
changed by changing sampling frequency. This API allows clients
to wait for at least some poll milli seconds before reading a new sample.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
HID sensor hub specify a default unit and alternative units. This
along with unit exponent can be used adjust scale. This change
change HID sensor data units to IIO defined units for each
sensor type. So in this way user space can use a simply use:
"(data + offset) * scale" to get final result.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
New device support
* AS3935 Lightning Sensor
* MCP3426/7/8 support added to the existing MCP3422 ADC driver
* AK8963 support in the AK8975 driver
* MPU6500 support in the MPU6050 driver (the functionality that is different
is mostly not supported yet in either part).
Staging Graduations
* AD799x ADC
New functionality
* ACPI enumeration for the ak8975 driver
Cleanup / tweaks
* Use snprintf as a matter of good practice in a few additional places.
* Document *_mean_raw attributes. These have been there a while, but were
undocumented.
* Add an in kernel interface to get the mean values.
* Bug in the length of the event info mask that by coincidence wasn't yet
actually causing any problems.
* itg3000 drop an unreachable return statement.
* spear_adc cleanups (heading for a staging graduation but a few more
issues showed up in the review of these patches).
* Exynos ADC dependencies changed so it is only built when Exynos is present
or COMPILE_TEST and OF are set.
* tsl2583 cleanups.
* Some cut and paste typos in the comments of various drivers still in staging.
* Couple of minor improvements to the ST sensor drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTW8asAAoJEFSFNJnE9BaITYoP/1rONn2PS1t61CI4rtWDVZh8
SEn4EQCxRVVAdWCQQz1zY0JZeUSjuWcPi7+MJ/VNaw6efOXN0J4O+bsNfh5Asju2
88giAUuP+hmd4xccGkxaJvdXEhruRMzGugh3/6+L2XuhkJsorAhJe/63XTq+JNOp
Tq6NHVmqV507wuDOguXfUQ2eDKPEFiTBUiutLJqyLOOi5zEq/X3Cnv+YMCDx4coE
BwZEQnXJWLfMSvXQtbTAl1XwqvDY8bjMNwFvjRuTLN73ua0/gMe//kJV/2tm8UMF
90Fs3TPi/cc5QkvpKMC9DP8eeAMi11bRdSRN0/abEQgglCz1LzWuX5Gqpr5psrhM
q1KS9JU9u4oZ8PR49c8QWjN0RtNiKiVVhCgBVcNE/2uYVwQqu0kJWylsq/m2+7jr
99qi8R979b5GoX69TKjVyr9MyGbN2x/vKWm3+UgtujqzXgu7GGdXa6NhrcPGcYjW
/uH3rfW4w0rBFVEJzDXkj74n/j2WDvrukjqYgABfENfBqO14swc0nlBGGyjli0uv
tUiwwS05Fax8wmuMP/wlII7Bq9XA8e+QISXHeO318svP/9SPxRuRwsd2Oo7BxXZz
e6gm5i142XeiSc3KjLGEUAZ+qF7xKUfEZwIajkWZ8LIgeROfDLzNEjvVsU2Byk+0
g+XrtWm4jljKHzjV/33g
=eqGz
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.16a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First round of IIO new driver, functionality and cleanups for the 3.16 cycle.
New device support
* AS3935 Lightning Sensor
* MCP3426/7/8 support added to the existing MCP3422 ADC driver
* AK8963 support in the AK8975 driver
* MPU6500 support in the MPU6050 driver (the functionality that is different
is mostly not supported yet in either part).
Staging Graduations
* AD799x ADC
New functionality
* ACPI enumeration for the ak8975 driver
Cleanup / tweaks
* Use snprintf as a matter of good practice in a few additional places.
* Document *_mean_raw attributes. These have been there a while, but were
undocumented.
* Add an in kernel interface to get the mean values.
* Bug in the length of the event info mask that by coincidence wasn't yet
actually causing any problems.
* itg3000 drop an unreachable return statement.
* spear_adc cleanups (heading for a staging graduation but a few more
issues showed up in the review of these patches).
* Exynos ADC dependencies changed so it is only built when Exynos is present
or COMPILE_TEST and OF are set.
* tsl2583 cleanups.
* Some cut and paste typos in the comments of various drivers still in staging.
* Couple of minor improvements to the ST sensor drivers.
Currently the pressure sensor has code to retrieve and enable two
regulators for Vdd and Vdd IO, but actually these voltage inputs
are found on all of these ST sensors, so move the regulator
handling to the core and make sure all the ST sensors call these
functions on probe() and remove() to enable/disable power.
Here also mover over to obtaining the regulator from the *parent*
device of the IIO device, as the IIO device is created on-the-fly
in this very subsystem it very unlikely evert have any regulators
attached to it whatsoever. It is much more likely that the parent
is a platform device, possibly instantiated from a device tree,
which in turn have Vdd and Vdd IO supplied assigned to it.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Remove the hard coded indexes, instead search for usage id and
use the index to set the power and report state.
This will fix issue, where the report descriptor doesn't contain
the full list of possible selector for power and report state.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In the original HID sensor hub firmwares all Named array enums were
to 0-based. But the most recent hub implemented as 1-based,
because of the implementation by one of the major OS vendor.
Using logical minimum for the field as the base of enum. So we add
logical minimum to the selector values before setting those fields.
Some sensor hub FWs already changed logical minimum from 0 to 1
to reflect this and hope every other vendor will follow.
There is no easy way to add a common HID quirk for NAry elements,
even if the standard specifies these field as NAry, the collection
used to describe selectors is still just "logical".
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We can't store the trigger instance created by iio_trigger_alloc, in
trig field of iio_device structure. This needs to be stored in the
driver private data. Othewise it can result in crash during module
unload. Hence created a trig_ptr in the common data structure
for each HID sensor IIO driver and storing here.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Call hid_sensor_hub_device_open when user space opens device and call
hid_sensor_hub_device_close when device is closed. This helps in
saving power.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Strip out all those unnecessary gotos and just return the error right away.
Aids to simplicity and reduces code.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Not all ST's sensors support data ready, so let's make the declaration
of one conditional.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Makes the code a bit shorter and less ugly.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Denis Ciocca <denis.ciocca@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some chips either don't support it or fail to provide adequate documentation,
so sometimes it's impossible to enable the feature even if it is supported.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Keeping Makefile and Kconfig entries in alphabetical order usually works better
than just appending new entries at the end, since it reduces the amount of
conflicts. This patch adds a comment to the IIO Kconfig and Makefile files to
document that the entries should be kept in alphabetical order.
Also reorder those entries which weren't in alphabetical order yet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch add support to redirect the DRDY interrupt on INT1 or INT2
on accelerometer and pressure sensors.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch introduce num_data_channels variable on st_sensors struct
to manage different type of channels (size or number) in
st_sensors_get_buffer_element function.
Removed ST_SENSORS_NUMBER_DATA_CHANNELS and ST_SENSORS_BYTE_FOR_CHANNEL
and used struct iio_chan_spec const *ch to catch data.
Added 3 byte channel data support on one-shot reads.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Introduce iio_tigger_{set,get}_drvdata which allows to attach driver specific
data to a trigger. The functions wrap access to the triggers private_data field
and all current users are updated to use iio_tigger_{set,get}_drvdata instead of
directly accessing the private_data field. This is the first step towards
removing the private_data field from the iio_trigger struct.
The following coccinelle script has been used to update the drivers:
<smpl>
@@
struct iio_trigger *trigger;
expression priv;
@@
-trigger->private_data = priv
+iio_trigger_set_drv_data(trigger, priv)
@@
struct iio_trigger *trigger;
@@
-trigger->private_data
+iio_trigger_get_drv_data(trigger)
</smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
New stuff
1) Add OF support for specifying mappings between iio devices and their
in kernel consumers.
2) Driver for AD7923 (extra functionality and support for ad7904, ad7914 and
ad7924 added later in series)
3) Driver for Exynos adc (dt suppor for phy added later in series).
4) Make iio_push_event save IRQ context - necessary if it is to be used
within an interrupt handler. Users of this functionality to follow.
5) For iio use the device tree node name to provide the hwmon name attribute
if available.
Removal and moves out of staging
1) Drop the adt7410 driver from IIO now that there is a hmwon driver with
equivalent support. This device is very much targeted at hardware
monitoring so hwmon is a more appropriate host for the driver.
2) Move iio_hwmon driver to drivers/hwmon.
Cleanups
1) Minor cleanup in ST common library.
2) Large set of patches to break the info_mask element which previously used
odd and even bits to specify if a channel attribute was either shared across
similar channels or specific to only one. Now we have two bitmaps, one for
those parameters that are specific to this channel and one for those shared
by all channels with the same type as this one. This has no effect on the
userspace abi. It simplifies the core code and provides more space for new
channel parameters. It has been on the todo list for a long time!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRTYe3AAoJEFSFNJnE9BaIxfEQAJDxF7GZKG3pJhJIrN40d42y
DZD9Tf28Z5Ynd70gA8lITzwyBuj2r56/xpuewR9SH0nsV+s8zUplUoqBg1B5eIOO
WUg/ojzVjJISyrg+egfkNmwqv7LFkINj9CJfrf2xv99OwjQeCqMc9zHQ1JRK+tl/
57Z1zCZFX3B2dKDalH8sGcuGFRB+TturctvSAO2FTKcQ6/8FmubXD7+4zamn7+lH
vsD6+kRhIQ3yZJSUhLMzbueXfdF9OZe3n7MTbCtLhb76JOLmkGAqnSo0APEndBTb
PyS3DPKFxWJZTzzyKVoEW4pdU/fx2JfOZs101TFDXxh5p1hcALP8zwJQ3CqotYT6
kosGlyrPKaAiqkkGURqsUQvjjfcvNuhFQY2IMHQxFhEIRLYHZTLPJGBV1oBPQ4sQ
/OAOgu+Uut45ZeHAo1bTXcykO8GzvYxvQ18LUY1Jo/5Iqid0nRxVL6CkrA6Uw+z4
Tu4/z3ceeBAx1B34/ty58rkX+Xe6CxPPbzSgCtrV6oMpLZhQegHareItnhxbNRFN
oO9CULLXf6nyFhoYFbZRi+FStfsvdLKjfoDshHNp2kcpqsrTDyjwaTjjTQ4u30MD
VVo7lwVmm0ASpOXyVDPIw7ft/HHUDPH8xz7tPhhZHX5uvs74GCHg0WjZ48WMgv/N
Jk6lERQpZ2x6RYe4eH9+
=99m9
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.10a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First set of IIO new drivers and cleanup for the 3.10 cycle.
New stuff
1) Add OF support for specifying mappings between iio devices and their
in kernel consumers.
2) Driver for AD7923 (extra functionality and support for ad7904, ad7914 and
ad7924 added later in series)
3) Driver for Exynos adc (dt suppor for phy added later in series).
4) Make iio_push_event save IRQ context - necessary if it is to be used
within an interrupt handler. Users of this functionality to follow.
5) For iio use the device tree node name to provide the hwmon name attribute
if available.
Removal and moves out of staging
1) Drop the adt7410 driver from IIO now that there is a hmwon driver with
equivalent support. This device is very much targeted at hardware
monitoring so hwmon is a more appropriate host for the driver.
2) Move iio_hwmon driver to drivers/hwmon.
Cleanups
1) Minor cleanup in ST common library.
2) Large set of patches to break the info_mask element which previously used
odd and even bits to specify if a channel attribute was either shared across
similar channels or specific to only one. Now we have two bitmaps, one for
those parameters that are specific to this channel and one for those shared
by all channels with the same type as this one. This has no effect on the
userspace abi. It simplifies the core code and provides more space for new
channel parameters. It has been on the todo list for a long time!
Conflicts:
drivers/iio/dac/ad5064.c
Use the new spi_sync_transfer() helper function instead of open-coding it.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch remove st_sensors_get_sampling_frequency_avl and
st_sensors_get_scale_avl functions used only in
st_sensors_sysfs_sampling_frequency_avail and st_sensors_sysfs_scale_avail
sysfs functions.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This is to get the comedi fixes, and resolve the issue in comdi_test.c
and comedi_fops.c that were caused by changes in both branches.
It also allows the fwserial driver changes to be applied, as they
required the fixes that are in staging-linus.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The structure with common attributes for hid-sensors isn't specific
to the iio-subsystem, so rename it to hid_sensor_common.
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The stuff in hid-sensor-attributes.h is needed by every piece which
uses hid-sensor-hub and merging it into hid-sensor-hub.h makes it accessible
from outside the iio subdirectory.
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Not much to say, without that change, hid-sensor-trigger will be
always compiled if HID_SENSOR_IIO_COMMON is selected which fails if
CONFIG_IIO_TRIGGER is not set because CONFIG_IIO_CONSUMERS_PER_TRIGGER
will not be defined.
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
It's non-sense to use tristate for the option, it's bool.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When hid sensor hub is unplugged, there is a crash in
iio_device_unregister_trigger_consumer.
In a typical IIO driver when remove is called, it will unregister and free
trigger and then it will call iio_device_free.
The function iio_trigger_free() will free the allocated memory for trigger.
If this trigger was assigned to iio_dev->trig, then it should be set to NULL.
Othewise when iio_device_free() is called later, it finally calls
iio_device_unregsister_trigger(), which checks for
if (indio_dev->trig)
iio_trigger_put(indio_dev->trig);
If indio_dev->trig is not set to NULL, it calls iio_trigger_put on a bad
pointer causing crash.
This scenerio can happen in any driver, which is storing trigger pointer in
iio_dev structure and following current procedure during remove.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch contains the common code, which is used by all HID sensors.
There are some common set of attributes, which every hid sensor
needs it. This patch contains all such attributes processing.
Also the trigger interface is common among all HID sensors. This
patch contains common trigger functions utilized by all HID sensors.
Signed-off-by: srinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Greg Kroah-Hartman
Lee Jones
Srinivas Pandruvada
Linus Walleij
Daniel Baluta
Jonathan Cameron
Sachin Kamat
Archana Patni
Dan Carpenter
Lars-Peter Clausen
Denis CIOCCA
Denis Ciocca
Alexander Holler
Kirill A. Shutemov
srinivas pandruvada