aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2019-04-04iio: adc: stmpe-adc: Shuffle an if statement around in stmpe_adc_isrNathan Chancellor1-3/+2
When building with -Wsometimes-uninitialized, Clang warns: drivers/iio/adc/stmpe-adc.c:204:13: warning: variable 'data' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] Clang can't tell that data will never be used uninitialized because the two if statements take care of all cases. Remove the first if statement and make it the else branch of the second one so that it is apparent to Clang that all cases are covered. Link: https://github.com/ClangBuiltLinux/linux/issues/387 Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: NIck Desaulniers <ndesaulniers@google.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: common: ssp_sensors: Initialize calculated_time in ssp_common_process_dataNathan Chancellor1-1/+1
When building with -Wsometimes-uninitialized, Clang warns: drivers/iio/common/ssp_sensors/ssp_iio.c:95:6: warning: variable 'calculated_time' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] While it isn't wrong, this will never be a problem because iio_push_to_buffers_with_timestamp only uses calculated_time on the same condition that it is assigned (when scan_timestamp is not zero). While iio_push_to_buffers_with_timestamp is marked as inline, Clang does inlining in the optimization stage, which happens after the semantic analysis phase (plus inline is merely a hint to the compiler). Fix this by just zero initializing calculated_time. Link: https://github.com/ClangBuiltLinux/linux/issues/394 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: proximity: as3935: fix use-after-free on device removeSven Van Asbroeck1-29/+21
This driver's probe() uses a mix of devm_ and non-devm_ functions. This means that the remove order will not be the exact opposite of the probe order. Remove order: 1. remove() executes: iio_device_unregister iio_triggered_buffer_cleanup iio_trigger_unregister (A) 2. core frees devm resources in reverse order: free_irq iio_trigger_free iio_device_free In (A) the trigger has been unregistered, but the irq handler is still registered and active, so the trigger may still be touched via interrupt -> as3935_event_work. This is a potential use-after-unregister. Given that the delayed work is never canceled explicitly, it may run even after iio_device_free. This is a potential use-after-free. Solution: convert all probe functions to their devm_ equivalents. Add a devm callback, called by the core on remove right after irq_free, which explicitly cancels the delayed work. This will guarantee that all resources are freed in the correct order. As an added bonus, some boilerplate code can be removed. Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:potentiostat:lmp91000: change dev_err messageAnderson Reis1-1/+1
Change dev_err message on line 215 in order to inform that tia-gain-ohm is not defined and an external resistor is not specified. Signed-off-by: Anderson Reis <andersonreisrosa@gmail.com> Signed-off-by: Lucas Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:potentiostat:lmp91000: invert if statementAnderson Reis1-3/+2
Invert if statement arms in line 214, in order to make the code cleaner, solve these checkpatch.pl CHECKs: - lmp9100.c:214: CHECK: braces {} should be used on all arms of this statement - lmp9100.c:216: CHECK: Unbalanced braces around else statement Signed-off-by: Lucas Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Anderson Reis <andersonreisrosa@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:potentiostat:lmp91000: reduce line width and remove blank lineAnderson Reis1-3/+2
Break the line 258 in order fit the line width on 80 characters. Remove the blank line 279, as the line before is also a blank line. Solve these checkpath.el WARNING and CHECK: - lmp91000.c:258: WARNING: line over 80 characters - lmp91000.c:279: CHECK: Please don't use multiple blank lines Signed-off-by: Lucas Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Anderson Reis <andersonreisrosa@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:potentiostat:lmp91000: remove unnecessary parenthesesLucas Oshiro1-1/+1
Remove unnecessary parentheses on line 116. Signed-off-by: Lucas Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Anderson Reis <andersonreisrosa@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: adc: ti-ads7950: add GPIO supportJustin Chen1-6/+194
The ADS79XX has GPIO pins that can be used. Add support for the GPIO pins using the GPIO chip framework. Signed-off-by: Justin Chen <justinpopo6@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: adc: fix a potential NULL pointer dereferenceKangjie Lu1-0/+2
devm_iio_trigger_alloc may fail and return NULL. The fix returns ENOMEM when it fails. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: dac: ti-dac5571: Update the module author email addressSean Nyekjaer1-1/+1
Update the module author to the current email address Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: adc: ti-ads8688: Update the module author email addressSean Nyekjaer1-1/+1
Update the module author to the current email address. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: accel: kxcjk1013: Add device tree supportRobert Yang1-0/+10
Add device tree support for kxcjk-1013 accelerometer sensors. Signed-off-by: Robert Yang <decatf@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: adc: meson-saradc: add support for Meson G12ANeil Armstrong1-0/+8
Add the SAR ADC driver for the Amlogic Meson-G12A SoC. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: buffer: Switch to bitmap_zalloc()Andy Shevchenko2-19/+15
Switch to bitmap_zalloc() to show clearly what we are allocating. Besides that it returns pointer of bitmap type instead of opaque void *. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: cros_ec_accel_legacy: Refactor code in cros_ec_accel_legacy_probeGustavo A. R. Silva1-15/+12
Refactor some code in order to fix both the technical implementation and the following warnings: drivers/iio/accel/cros_ec_accel_legacy.c: In function ‘cros_ec_accel_legacy_probe’: drivers/iio/accel/cros_ec_accel_legacy.c:387:36: warning: this statement may fall through [-Wimplicit-fallthrough=] ec_accel_channels[X].scan_index = Y; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ drivers/iio/accel/cros_ec_accel_legacy.c:388:3: note: here case Y: ^~~~ drivers/iio/accel/cros_ec_accel_legacy.c:389:36: warning: this statement may fall through [-Wimplicit-fallthrough=] ec_accel_channels[Y].scan_index = X; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ drivers/iio/accel/cros_ec_accel_legacy.c:390:3: note: here case Z: ^~~~ Notice that neither the for loop nor the switch statement is needed. Also, "state->sign[Y] = 1" should be unconditional. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: st_accel: remove redundant unsigned less than zero checkColin Ian King1-1/+1
The check that variable val is less than zero is redundant since val is an unsigned int and hence can never be less than zero. Remove it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: st_lsm6dsx: add support to ASM330LHHLorenzo Bianconi6-6/+57
Add support to STM ASM330LHH 6-axis (acc + gyro) Mems sensor https://www.st.com/resource/en/datasheet/asm330lhh.pdf Tested-by: Mario Tesi <mario.tesi@st.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: ak8975: improve code readabilityH. Nikolaus Schaller1-3/+5
- use temporary variable in get_mount_matrix() - remove , after { } Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: mpu6050: improve code readabilityH. Nikolaus Schaller1-2/+4
- use temporary variable in get_mount_matrix() - remove , after { } Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: magnetometer: hmc5843: add mount matrix supportH. Nikolaus Schaller2-2/+19
This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: magnetometer: bmc150: add mount matrix supportH. Nikolaus Schaller1-0/+21
This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: gyro: itg3200: add mount matrix supportH. Nikolaus Schaller1-0/+20
This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: gyro: bmg160: add mount matrix supportH. Nikolaus Schaller1-0/+21
This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: accel: bma180: add mount matrix supportH. Nikolaus Schaller1-1/+17
This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: accel: bmc150: add mount matrix supportH. Nikolaus Schaller1-0/+21
This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: Allow to read mount matrix from ACPIAndy Shevchenko6-41/+26
Currently mount matrix is allowed in Device Tree, though there is no technical issue to extend it to support ACPI. Convert the function to use device_property_read_string_array() and thus allow to read mount matrix from ACPI if available. Example of use in _DSD method: Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mount-matrix", Package() { "1", "0", "0", "0", "0.866", "0.5", "0", "-0.5", "0.866", } }, } }) At the same time drop the "of" prefix from its name and convert current users. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:adc:ad7923: Rewrite comparison to NULLBárbara Fernandes1-1/+1
Solves checkpath.pl's message: CHECK: Comparison to NULL could be written "!indio_dev" Signed-off-by: Bárbara Fernandes <barbara.fernandes@usp.br> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:adc:ad7923: Put macro argument between ()'sBárbara Fernandes1-5/+5
Put macro argument between parenthesis in order to avoid precedence issues. Solves the following checkpath.pl's messages: CHECK: Macro argument 'mode' may be better as '(mode)' to avoid precedence issues CHECK: Macro argument 'channel' may be better as '(channel)' to avoid precedence issues CHECK: Macro argument reuse 'sequence' - possible side-effects? CHECK: Macro argument 'sequence' may be better as '(sequence)' to avoid precedence issues CHECK: Macro argument 'val' may be better as '(val)' to avoid precedence issues CHECK: Macro argument 'dec' may be better as '(dec)' to avoid precedence issues CHECK: Macro argument 'bits' may be better as '(bits)' to avoid precedence issues Signed-off-by: Bárbara Fernandes <barbara.fernandes@usp.br> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:adc:ad7923: Use BIT macro instead of bitshiftBárbara Fernandes1-3/+3
Replace use of the operation '<<' by the BIT macro. Solves checkpath.pl's message: CHECK: Prefer using the BIT macro Signed-off-by: Bárbara Fernandes <barbara.fernandes@usp.br> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio:adc:ad7923: Align broken line to parenthesisBárbara Fernandes1-3/+3
Get broken line aligned with parenthesis on upper line. Solves checkpatch.pl's message: CHECK: Alignment should match open parenthesis Signed-off-by: Bárbara Fernandes <barbara.fernandes@usp.br> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: counter: stm32-lptimer: Add power management supportFabrice Gasnier1-0/+55
Add suspend/resume PM sleep ops. When going to low power, disable active counter. Only active counter should be resumed: don't touch disabled counter, as it may be used by other LPTimer MFD child driver. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: adis16480: Add support for ADIS1649x family of devicesStefan Popa1-0/+97
The ADIS16495 and ADIS16497 are inertial systems that include a triaxis gyroscope and a triaxis accelerometer. The serial peripheral interface (SPI) provide a simple interface for data collection and configuration control. The devices are similar to ADIS16475, ADIS16480, ADIS16485 and ADIS16488, the main differences are highlighted below: * The temperature data scale is 0.00565 C/LSB for ADIS16475 and ADIS1648x devices, while for ADIS1649x 0.0125 C/LSB. * ADIS1649x devices support different gyroscope measurement ranges which are dependent on the dash number (-1, -2, -3), see Table 24 in the ADIS16495 datasheet. However, the ADIS16497 gyroscopes have the same scale as ADIS16495. * ADIS16495 devices support the acceleration maximum range of 8g, while ADIS16497 devices go up to 40g. * The internal clock for ADIS1649x devices is 4.25 kSPS. The sampling frequency is calculated by applying a decimation rate which can take a maximum value of 4250. * ADIS1649x devices support different default filter frequencies. Datasheets: Link: https://www.analog.com/media/en/technical-documentation/data-sheets/adis16495.pdf Link: https://www.analog.com/media/en/technical-documentation/data-sheets/adis16497.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: adis16480: Deal with filter freq in a generic wayStefan Popa1-4/+9
When setting the filter frequency, the driver looks into the adis16480_def_filter_freqs table for the best match. Pass this table to the chip_info struct since future devices will need to use a different table. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: adis16480: Calculate the sampling frequency in a generic wayStefan Popa1-4/+14
The adis1648x devices have an internal clock of 2.46 kSPS. The sampling frequency is calculated by applying a decimation rate which can take the maximum value of 2047. Although all adis1648x devices are similar in this regard, devices that will use this feature will be added in the future. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: adis16480: Treat temperature scale in a generic wayStefan Popa1-3/+15
All supported devices provide internal temperature measurement from -40 C to +85 C, with +25 C representing value 0x00. This patch treats the temperature scale in a generic way, similar to the accelerometer and gyroscope scales. So far, there are no temperature max scale differences between the supported devices. However, devices that will make use of this feature will be added in the future. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: adis16480: Add OF device ID tableStefan Popa1-0/+10
The driver does not have a struct of_device_id table, but supported devices are registered via Device Trees. This patch adds OF device ID table. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: imu: adis16480: Add support for configurable drdy indicatorStefan Popa1-2/+95
The FNCTIO_CTRL register provides configuration control for each I/O pin (DIO1, DIO2, DIO3 and DIO4). This patch adds the option to configure each DIOx pin as data ready indicator with positive or negative polarity by reading the 'interrupts' and 'interrupt-names' properties from the devicetree. The 'interrupt-names' property is optional, if it is not specified, then the DIO1 pin is used as default data ready signal. Although the factory default assigns DIO2 as data ready signal, in the versions previous this patch, DIO1 pin was used. We should leave this configuration as is, since some devices might be expecting the interrupt on the wrong physical pin. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: adc: ti-ads7950: Fix improper use of mlockJustin Chen1-4/+15
Indio->mlock is used for protecting the different iio device modes. It is currently not being used in this way. Replace the lock with an internal lock specifically used for protecting the SPI transfer buffer. Signed-off-by: Justin Chen <justinpopo6@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: trigger: Print an error if there is no available irqMathieu Othacehe1-1/+4
If there are more trigger consumers than CONFIG_IIO_CONSUMERS_PER_TRIGGER, iio_trigger_attach_poll_func will silently fail. Add an error message to inform the user that CONFIG_IIO_CONSUMERS_PER_TRIGGER limit might be exceeded. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: mma8452: mark expected switch fall-throughGustavo A. R. Silva1-1/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/iio/accel/mma8452.c: In function ‘mma8452_probe’: drivers/iio/accel/mma8452.c:1581:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (ret == data->chip_info->chip_id) ^ drivers/iio/accel/mma8452.c:1584:2: note: here default: ^~~~~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: chemical: pms7003: extend supported sensors listTomasz Duszynski1-0/+5
Add other sensors to the compatible list. Signed-off-by: Tomasz Duszynski <tduszyns@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: adc: ingenic: remove redundant dev_err call in ingenic_adc_probe()Wei Yongjun1-3/+1
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-04iio: remove redundant unlikely annotationChengguang Xu1-1/+1
unlikely has already included in IS_ERR(), so just remove redundant unlikely annotation. Signed-off-by: Chengguang Xu <cgxu519@gmx.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-31iio: core: fix a possible circular locking dependencyFabrice Gasnier1-2/+2
This fixes a possible circular locking dependency detected warning seen with: - CONFIG_PROVE_LOCKING=y - consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc") When using the IIO consumer interface, e.g. iio_channel_get(), the consumer device will likely call iio_read_channel_raw() or similar that rely on 'info_exist_lock' mutex. typically: ... mutex_lock(&chan->indio_dev->info_exist_lock); if (chan->indio_dev->info == NULL) { ret = -ENODEV; goto err_unlock; } ret = do_some_ops() err_unlock: mutex_unlock(&chan->indio_dev->info_exist_lock); return ret; ... Same mutex is also hold in iio_device_unregister(). The following deadlock warning happens when: - the consumer device has called an API like iio_read_channel_raw() at least once. - the consumer driver is unregistered, removed (unbind from sysfs) ====================================================== WARNING: possible circular locking dependency detected 4.19.24 #577 Not tainted ------------------------------------------------------ sh/372 is trying to acquire lock: (kn->count#30){++++}, at: kernfs_remove_by_name_ns+0x3c/0x84 but task is already holding lock: (&dev->info_exist_lock){+.+.}, at: iio_device_unregister+0x18/0x60 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&dev->info_exist_lock){+.+.}: __mutex_lock+0x70/0xa3c mutex_lock_nested+0x1c/0x24 iio_read_channel_raw+0x1c/0x60 iio_read_channel_info+0xa8/0xb0 dev_attr_show+0x1c/0x48 sysfs_kf_seq_show+0x84/0xec seq_read+0x154/0x528 __vfs_read+0x2c/0x15c vfs_read+0x8c/0x110 ksys_read+0x4c/0xac ret_fast_syscall+0x0/0x28 0xbedefb60 -> #0 (kn->count#30){++++}: lock_acquire+0xd8/0x268 __kernfs_remove+0x288/0x374 kernfs_remove_by_name_ns+0x3c/0x84 remove_files+0x34/0x78 sysfs_remove_group+0x40/0x9c sysfs_remove_groups+0x24/0x34 device_remove_attrs+0x38/0x64 device_del+0x11c/0x360 cdev_device_del+0x14/0x2c iio_device_unregister+0x24/0x60 release_nodes+0x1bc/0x200 device_release_driver_internal+0x1a0/0x230 unbind_store+0x80/0x130 kernfs_fop_write+0x100/0x1e4 __vfs_write+0x2c/0x160 vfs_write+0xa4/0x17c ksys_write+0x4c/0xac ret_fast_syscall+0x0/0x28 0xbe906840 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->info_exist_lock); lock(kn->count#30); lock(&dev->info_exist_lock); lock(kn->count#30); *** DEADLOCK *** ... cdev_device_del() can be called without holding the lock. It should be safe as info_exist_lock prevents kernelspace consumers to use the exported routines during/after provider removal. cdev_device_del() is for userspace. Help to reproduce: See example: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt sysv { compatible = "voltage-divider"; io-channels = <&adc 0>; output-ohms = <22>; full-ohms = <222>; }; First, go to iio:deviceX for the "voltage-divider", do one read: $ cd /sys/bus/iio/devices/iio:deviceX $ cat in_voltage0_raw Then, unbind the consumer driver. It triggers above deadlock warning. $ cd /sys/bus/platform/drivers/iio-rescale/ $ echo sysv > unbind Note I don't actually expect stable will pick this up all the way back into IIO being in staging, but if's probably valid that far back. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Fixes: ac917a81117c ("staging:iio:core set the iio_dev.info pointer to null on unregister") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-24iio: ad_sigma_delta: select channel when reading registerDragos Bogdan1-0/+1
The desired channel has to be selected in order to correctly fill the buffer with the corresponding data. The `ad_sd_write_reg()` already does this, but for the `ad_sd_read_reg_raw()` this was omitted. Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-16iio: pms7003: select IIO_TRIGGERED_BUFFERArnd Bergmann1-0/+1
Without IIO_TRIGGERED_BUFFER, this driver fails to link: drivers/iio/chemical/pms7003.o: In function `pms7003_probe': pms7003.c:(.text+0x21c): undefined reference to `devm_iio_triggered_buffer_setup' pms7003.c:(.text+0x21c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `devm_iio_triggered_buffer_setup' Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003 sensor") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Tomasz Duszynski <tduszyns@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-16iio: cros_ec: Fix the maths for gyro scale calculationGwendal Grignou1-3/+4
Calculation did not use IIO_DEGREE_TO_RAD and implemented a variant to avoid precision loss as we aim a nano value. The offset added to avoid rounding error, though, doesn't give us a close result to the expected value. E.g. For 1000dps, the result should be: (1000 * pi ) / 180 >> 15 ~= 0.000532632218 But with current calculation we get $ cat scale 0.000547890 Fix the calculation by just doing the maths involved for a nano value val * pi * 10e12 / (180 * 2^15) so we get a closer result. $ cat scale 0.000532632 Fixes: c14dca07a31d ("iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-16iio: adc: xilinx: prevent touching unclocked h/w on removeSven Van Asbroeck1-1/+1
In remove, the clock is disabled before canceling the delayed work. This means that the delayed work may be touching unclocked hardware. Fix by disabling the clock after the delayed work is fully canceled. This is consistent with the probe error path order. Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-16iio: adc: xilinx: fix potential use-after-free on probeSven Van Asbroeck1-0/+1
If probe errors out after request_irq(), its error path does not explicitly cancel the delayed work, which may have been scheduled by the interrupt handler. This means the delayed work may still be running when the core frees the private structure (struct xadc). This is a potential use-after-free. Fix by inserting cancel_delayed_work_sync() in the probe error path. Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-03-16iio: adc: xilinx: fix potential use-after-free on removeSven Van Asbroeck1-1/+1
When cancel_delayed_work() returns, the delayed work may still be running. This means that the core could potentially free the private structure (struct xadc) while the delayed work is still using it. This is a potential use-after-free. Fix by calling cancel_delayed_work_sync(), which waits for any residual work to finish before returning. Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>