user/sven/linux.git/include/linux/iio, branch v4.9.53

iio: sw-device: Fix config group initialization

2017-03-30T07:41:25Z

commit c42f8218610aa09d7d3795e5810387673c1f84b6 upstream. Use the IS_ENABLED() helper macro to ensure that the configfs group is initialized either when configfs is built-in or when configfs is built as a module. Otherwise software device creation will result in undefined behaviour when configfs is built as a module since the configfs group for the device not properly initialized. Similar to commit b2f0c09664b7 ("iio: sw-trigger: Fix config group initialization"). Fixes: 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs") Reported-by: Miguel Robles Signed-off-by: Lars-Peter Clausen Acked-by: Daniel Baluta Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: accel: st_accel: fix LIS3LV02 reading and scaling

2017-01-12T10:39:21Z

commit 65e4345c8ef8811bbb4860fe5f2df10646b7f2e1 upstream. The LIS3LV02 has a special bit that need to be set to get the read values left aligned. Before this patch we get gibberish like this: iio_generic_buffer -a -c10 -n lis3lv02dl_accel (...) 0.000000 -0.010042 -0.642688 19155832931907 0.000000 -0.010042 -0.642688 19155858751073 Which is because we read a raw value for 1g as 64 which is the nominal 1024 for 1g shifted 4 bits to the left by being right-aligned rather than left aligned. Since all other sensors are left aligned, add some code to set the special DAS (data alignment setting) bit to 1 so that the right value is now read like this: iio_generic_buffer -a -c10 -n lis3lv02dl_accel (...) 0.000000 -0.147095 -10.120135 24761614364956 -0.029419 -0.176514 -10.120135 24761631624540 The scaling was weird as well: we have a gain of 1000 for 1g and 3000 for 6g. I don't even remember how I came up with the old values but they are wrong. Fixes: 3acddf74f807 ("iio: st-sensors: add support for lis3lv02d accelerometer") Cc: Lorenzo Bianconi Cc: Giuseppe Barba Cc: Denis Ciocca Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

Merge tag 'iio-for-4.9b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next

2016-09-14T18:42:03Z

Jonathan writes: Second set of iio new device support, features and cleanups for the 4.9 cycle. New device support * ad8801 dac - new driver supporting ad8801 and ad8803 DACs. * adc12138 - new driver supporting TI adc12130/adc12132 and adc12138 ADCs. * ltc2485 adc - new driver * mxc6255 - add support for the mxc6225 part name and fixup the ID check so it works. * vz89x VOC sensor - add support for the vz89te part which drops the voc_short channel and adds CRCs compared to other supported parts. New features * core - immutable triggers. These effectively grant exclusive control over a trigger. The typical usecase is a device representing an analog part (perhaps a MUX) that needs to control the sampling of a downstream ADC. - resource managed trigger registration and triggered_buffer_init. - iio_push_event now protected against case of the event interface registration not having yet occured. Only matters if an interrupt can occur during this window - might happen on shared interrupt lines. - helper to let a driver query if the trigger it is using is provided by itself (using the convention of both device and trigger having the same parent). * tools - iio-utils. Used channel modifier scaling in preference to generic scaling when both exist. * at91-adc - Add support for touchscreen switches closure time needed by some newer parts. * stx104 - support the ADC channels on this ADC/DAC board. As these are the primary feature of the board also move the driver to the iio/adc directory. * sx9500 - device tree bindings. Cleanups / Fixes * ad5755 - fix an off-by-one on devnr limit check (introduced earlier this cycle) * ad7266 - drop NULL check on devm_regulator_get_optional as it can't return NULL. * ak8974 - avoid an unused functional warning due to rework in PM core code. - remove .owner field setting as done by i2c_core. * ina2xx - clear out a left over debug field from chip global data. * hid-sensors - avoid an unused functional warning due to rework in PM core code. * maxim-thermocouple - fix non static symbol warnings. * ms5611 - fetch and enable regulators unconditionally when they aren't optional. * sca3000 - whitespace cleanup. * st_sensors - fetch and enable regulators unconditionally rather than having them supported as optional regulators (missunderstanding on my part amongst others a while back) - followup to previous patch fixes error checking on the regulators. - mark symbols static where possible. - use the 'is it my trigger' help function. This prevents the odd case of another device triggering from the st-sensors trigger whilst the st-sensors trigger is itself not using it but rather using say an hrtimer. * ti-ads1015 - add missing of_node_put. * vz89x - rework to all support of new devices. - prevent reading of a corrupted buffer. - fixup a return value of 0/1 in a bool returning function. Address updates - Vlad Dogaru email address change.

iio: trigger: helpers to determine own trigger

2016-09-10T15:49:14Z

This adds a helper function to the IIO trigger framework: iio_trigger_using_own(): for an IIO device, this tells whether the device is using itself as a trigger. This is true if the indio device: (A) supplies a trigger and (B) has assigned its own buffer poll function to use this trigger. This helper function is good when constructing triggered, buffered drivers that can either use its own hardware *OR* an external trigger such as a HRTimer or even the trigger from a totally different sensor. Under such circumstances it is important to know for example if the timestamp from the same trigger hardware should be used when populating the buffer: if iio_trigger_using_own() is true, we can use this timestamp, else we need to pick a unique timestamp directly in the trigger handler. For this to work of course IIO devices registering hardware triggers must follow the convention to set the parent device properly, as as well as setting the parent of the IIO device itself. When a new poll function is attached, we check if the parent device of the IIO of the poll function is the same as the parent device of the trigger and in that case we conclude that the hardware is using itself as trigger. Cc: Giuseppe Barba Cc: Denis Ciocca Cc: Crestez Dan Leonard Cc: Gregor Boirie Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron

Merge 4.8-rc5 into staging-next

2016-09-05T06:13:24Z

We want the staging fixes in here as well to handle merge issues. Signed-off-by: Greg Kroah-Hartman

iio: add resource managed triggered buffer init helpers

2016-09-04T14:42:46Z

Add resource managed devm_iio_triggered_buffer_setup() and devm_iio_triggered_buffer_cleanup() to automatically clean up triggered buffers setup by IIO drivers, thus leading to simplified IIO drivers code. Signed-off-by: Gregor Boirie Signed-off-by: Jonathan Cameron

iio:trigger: add resource managed (un)register

2016-09-04T14:42:37Z

Add resource managed devm_iio_trigger_register() and devm_iio_triger_unregister() to automatically clean up registered triggers allocated by IIO drivers, thus leading to simplified IIO drivers code. Signed-off-by: Gregor Boirie Signed-off-by: Jonathan Cameron

iio: trigger: allow immutable triggers to be assigned

2016-09-03T14:31:55Z

There are times when an assigned trigger to a device shouldn't ever change after intialization. Examples of this being used is when an provider device has a trigger that is assigned to an ADC, which uses it populate data into a callback buffer. Signed-off-by: Matt Ranostay Signed-off-by: Jonathan Cameron

iio: buffer-callback: allow getting underlying iio_dev

2016-08-21T10:47:19Z

Add iio_channel_cb_get_iio_dev function to allow getting the underlying iio_dev. This is useful for setting the trigger of the consumer ADC device. Signed-off-by: Matt Ranostay Signed-off-by: Jonathan Cameron

iio: sw-trigger: Fix config group initialization

2016-08-15T14:39:09Z

Use the IS_ENABLED() helper macro to ensure that the configfs group is initialized either when configfs is built-in or when configfs is built as a module. Otherwise software trigger creation will result in undefined behaviour when configfs is built as a mdoule since the configfs group for the trigger is not properly initialized. Fixes: b662f809d410 ("iio: core: Introduce IIO software triggers") Signed-off-by: Lars-Peter Clausen Acked-by: Daniel Baluta Cc: Signed-off-by: Jonathan Cameron