summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2021-11-25iio: imu: st_lsm6dsx: Avoid potential array overflow in st_lsm6dsx_set_odr()Teng Qi1-2/+4
[ Upstream commit 94be878c882d8d784ff44c639bf55f3b029f85af ] The length of hw->settings->odr_table is 2 and ref_sensor->id is an enum variable whose value is between 0 and 5. However, the value ST_LSM6DSX_ID_MAX (i.e. 5) is not caught properly in switch (sensor->id) { If ref_sensor->id is ST_LSM6DSX_ID_MAX, an array overflow will ocurrs in function st_lsm6dsx_check_odr(): odr_table = &sensor->hw->settings->odr_table[sensor->id]; and in function st_lsm6dsx_set_odr(): reg = &hw->settings->odr_table[ref_sensor->id].reg; To avoid this array overflow, handle ST_LSM6DSX_ID_GYRO explicitly and return -EINVAL for the default case. The enum value ST_LSM6DSX_ID_MAX is only present as an easy way to check the limit and as such is never used, however this is not locally obvious. Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Teng Qi <starmiku1207184332@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/20211011114003.976221-1-starmiku1207184332@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iio: adis: do not disabe IRQs in 'adis_init()'Nuno Sá1-1/+3
[ Upstream commit b600bd7eb333554518b4dd36b882b2ae58a5149e ] With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup") we are doing a HW or SW reset to the device which means that we'll get the default state of the data ready pin (which is enabled). Hence there's no point in disabling the IRQ in the init function. Moreover, this function is intended to initialize internal data structures and not really do anything on the device. As a result of this, some devices were left with the data ready pin enabled after probe which was not the desired behavior. Thus, we move the call to 'adis_enable_irq()' to the initial startup function where it makes more sense for it to be. Note that for devices that cannot mask/unmask the pin, it makes no sense to call the function at this point since the IRQ should not have been yet requested. This will be improved in a follow up change. Fixes: ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210903141423.517028-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iio: buffer: Fix double-free in iio_buffers_alloc_sysfs_and_mask()Yang Yingliang1-1/+1
[ Upstream commit 09776d9374e635b1580b3736c19b95b788fbaa85 ] When __iio_buffer_alloc_sysfs_and_mask() failed, 'unwind_idx' should be set to 'i - 1' to prevent double-free when cleanup resources. BUG: KASAN: double-free or invalid-free in __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio] Call Trace: kfree+0x117/0x4c0 __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio] iio_buffers_alloc_sysfs_and_mask+0x60d/0x1570 [industrialio] __iio_device_register+0x483/0x1a30 [industrialio] ina2xx_probe+0x625/0x980 [ina2xx_adc] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211013094923.2473-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iio: st_pressure_spi: Add missing entries SPI to device ID tableMark Brown1-0/+4
[ Upstream commit 03748d4e003c9f2ad3cd00e3e46f054dcad6b96d ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding SPI IDs for parts that only have a compatible listed. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210927134153.12739-1-broonie@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iio: st_sensors: disable regulators after device unregistrationAlexandru Ardelean8-16/+16
[ Upstream commit 9f0b3e0cc0c88618aa9e5cecef747b1337ae0a5d ] Up until commit ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") only the ST pressure driver seems to have had any regulator disable. After that commit, the regulator handling was moved into the common st_sensors logic. In all instances of this regulator handling, the regulators were disabled before unregistering the IIO device. This can cause issues where the device would be powered down and still be available to userspace, allowing it to send invalid/garbage data. This change moves the st_sensors_power_disable() after the common probe functions. These common probe functions also handle unregistering the IIO device. Fixes: 774487611c949 ("iio: pressure-core: st: Provide support for the Vdd power supply") Fixes: ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") Cc: Lee Jones <lee.jones@linaro.org> Cc: Denis CIOCCA <denis.ciocca@st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210823112204.243255-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iio: ad5770r: make devicetree property reading consistentNuno Sá1-1/+1
commit 26df977a909f818b7d346b3990735513e7e0bf93 upstream. The bindings file for this driver is defining the property as 'reg' but the driver was reading it with the 'num' name. The bindings actually had the 'num' property when added in commit ea52c21268e6 ("dt-bindings: iio: dac: Add docs for AD5770R DAC") and then changed it to 'reg' in commit 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors"). However, both these commits landed in v5.7 so the assumption is that either 'num' is not being used or if it is, the validations were not done. Anyways, if someone comes back yelling about this, we might just support both of the properties in the future. Not ideal, but that's life... Fixes: 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210818080525.62790-1-nuno.sa@analog.com Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: dac: ad5446: Fix ad5622_write() return valuePekka Korpinen1-1/+8
commit 558df982d4ead9cac628153d0d7b60feae05ddc8 upstream. On success i2c_master_send() returns the number of bytes written. The call from iio_write_channel_info(), however, expects the return value to be zero on success. This bug causes incorrect consumption of the sysfs buffer in iio_write_channel_info(). When writing more than two characters to out_voltage0_raw, the ad5446 write handler is called multiple times causing unexpected behavior. Fixes: 3ec36a2cf0d5 ("iio:ad5446: Add support for I2C based DACs") Signed-off-by: Pekka Korpinen <pekka.korpinen@iki.fi> Link: https://lore.kernel.org/r/20210929185755.2384-1-pekka.korpinen@iki.fi Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18drivers: iio: dac: ad5766: Fix dt property nameMihail Chindris1-3/+3
commit d9de0fbdeb0103a204055efb69cb5cc8f5f12a6a upstream. In the documentation the name for the property is output-range-microvolts which is a standard name, therefore this name must be used. Fixes: fd9373e41b9ba ("iio: dac: ad5766: add driver support for AD5766") Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211007080035.2531-5-mihail.chindris@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups()Yang Yingliang1-2/+2
commit 604faf9a2ecd1addcc0c10a47e5aaef3c4d4fd6b upstream. If the second iio_device_register_sysfs_group() fails, 'legacy_buffer_group.attrs' need be freed too or it will cause memory leak: unreferenced object 0xffff888003618280 (size 64): comm "xrun", pid 357, jiffies 4294907259 (age 22.296s) hex dump (first 32 bytes): 80 f6 8c 03 80 88 ff ff 80 fb 8c 03 80 88 ff ff ................ 00 f9 8c 03 80 88 ff ff 80 fc 8c 03 80 88 ff ff ................ backtrace: [<00000000076bfd43>] __kmalloc+0x1a3/0x2f0 [<00000000c32e4886>] iio_buffers_alloc_sysfs_and_mask+0xc31/0x1290 [industrialio] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013144242.1685060-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask()Yang Yingliang1-3/+2
commit 9a2ff8009e53296e47de72d5af0bc31cd53274ff upstream. When iio_buffer_wrap_attr() returns NULL or buffer->buffer_group.name alloc fails, the 'attr' which is allocated in __iio_buffer_alloc_sysfs_and_mask() is not freed, and cause memory leak. unreferenced object 0xffff888014882a00 (size 64): comm "i2c-adjd_s311-8", pid 424, jiffies 4294907737 (age 44.396s) hex dump (first 32 bytes): 00 0f 8a 15 80 88 ff ff 00 0e 8a 15 80 88 ff ff ................ 80 04 8a 15 80 88 ff ff 80 05 8a 15 80 88 ff ff ................ backtrace: [<0000000021752e67>] __kmalloc+0x1af/0x3c0 [<0000000043e8305c>] iio_buffers_alloc_sysfs_and_mask+0xe73/0x1570 [industrialio] [<00000000b7aa5a17>] __iio_device_register+0x483/0x1a30 [industrialio] [<000000003fa0fb2f>] __devm_iio_device_register+0x23/0x90 [industrialio] [<000000003ab040cf>] adjd_s311_probe+0x19c/0x200 [adjd_s311] [<0000000080458969>] i2c_device_probe+0xa31/0xbe0 [<00000000e20678ad>] really_probe+0x299/0xc30 [<000000006bea9b27>] __driver_probe_device+0x357/0x500 [<00000000e1df10d4>] driver_probe_device+0x4e/0x140 [<0000000003661beb>] __device_attach_driver+0x257/0x340 [<000000005bb4aa26>] bus_for_each_drv+0x166/0x1e0 [<00000000272c5236>] __device_attach+0x272/0x420 [<00000000d52a96ae>] bus_probe_device+0x1eb/0x2a0 [<00000000129f7737>] device_add+0xbf0/0x1f90 [<000000005eed4e52>] i2c_new_client_device+0x622/0xb20 [<00000000b85a9c43>] new_device_store+0x1fa/0x420 This patch fix to free it before the error return. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013094343.315275-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: Fix memory leak in iio_buffers_alloc_sysfs_and_mask()Yang Yingliang1-5/+7
commit 486a25084155bf633768c26f022201c051d6fd95 upstream. When 'iio_dev_opaque->buffer_ioctl_handler' alloc fails in iio_buffers_alloc_sysfs_and_mask(), the 'attrs' allocated in iio_buffer_register_legacy_sysfs_groups() will be leaked: unreferenced object 0xffff888108568d00 (size 128): comm "88", pid 2014, jiffies 4294963294 (age 26.920s) hex dump (first 32 bytes): 80 3e da 02 80 88 ff ff 00 3a da 02 80 88 ff ff .>.......:...... 00 35 da 02 80 88 ff ff 00 38 da 02 80 88 ff ff .5.......8...... backtrace: [<0000000095a9e51e>] __kmalloc+0x1a3/0x2f0 [<00000000faa3735e>] iio_buffers_alloc_sysfs_and_mask+0xfa3/0x1480 [industrialio] [<00000000a46384dc>] __iio_device_register+0x52e/0x1b40 [industrialio] [<00000000210af05e>] __devm_iio_device_register+0x22/0x80 [industrialio] [<00000000730d7b41>] adjd_s311_probe+0x195/0x200 [adjd_s311] [<00000000c0f70eb9>] i2c_device_probe+0xa07/0xbb0 The iio_buffer_register_legacy_sysfs_groups() is called in __iio_buffer_alloc_sysfs_and_mask(), so move the iio_buffer_unregister_legacy_sysfs_groups() into __iio_buffer_free_sysfs_and_mask(), then the memory will be freed. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211018063718.1971240-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: buffer: check return value of kstrdup_const()Yang Yingliang1-0/+5
commit 2c0ad3f0cc04dec489552a21b80cd6d708bea96d upstream. Check return value of kstrdup_const() in iio_buffer_wrap_attr(), or it will cause null-ptr-deref in kernfs_name_hash() when calling device_add() as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: kernfs_name_hash+0x22/0x110 kernfs_find_ns+0x11d/0x390 kernfs_remove_by_name_ns+0x3b/0xb0 remove_files.isra.1+0x7b/0x190 internal_create_group+0x7f1/0xbb0 internal_create_groups+0xa3/0x150 device_add+0x8f0/0x2020 cdev_device_add+0xc3/0x160 __iio_device_register+0x1427/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] adjd_s311_probe+0x195/0x200 [adjd_s311] i2c_device_probe+0xa07/0xbb0 Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013040438.1689277-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: adc: tsc2046: fix scan interval warningOleksij Rempel1-1/+1
commit 69b31fd7a61784692db6433c05d46915b1b1a680 upstream. Sync if statement with the actual warning. Fixes: 9504db5765e8 ("iio: adc: tsc2046: fix a warning message in tsc2046_adc_update_scan_mode()") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20211007093007.1466-2-o.rempel@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: core: check return value when calling dev_set_name()Yang Yingliang1-1/+7
commit fe6f45f6ba22d625a8500cbad0237c60dd3117ee upstream. I got a null-ptr-deref report when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: start_creating+0x199/0x2f0 debugfs_create_dir+0x25/0x430 __iio_device_register+0x4da/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] max1027_probe+0x639/0x860 [max1027] spi_probe+0x183/0x210 really_probe+0x285/0xc30 If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support...") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211012063624.3167460-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18iio: core: fix double free in iio_device_unregister_sysfs()Yang Yingliang1-0/+1
commit 19833c40d0415d6fe4340b5b9c46239abbf718f6 upstream. I got the double free report: BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 iio_device_unregister_sysfs+0x108/0x13b [industrialio] iio_dev_release+0x9e/0x10e [industrialio] device_release+0xa5/0x240 If __iio_device_register() fails, iio_dev_opaque->groups will be freed in error path in iio_device_unregister_sysfs(), then iio_dev_release() will call iio_device_unregister_sysfs() again, it causes double free. Set iio_dev_opaque->groups to NULL when it's freed to fix this double free. Not this is a local work around for a more general mess around life time management that will get cleaned up and should make this handling unnecesarry. Fixes: 32f171724e5c ("iio: core: rework iio device group creation") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-18Merge tag 'staging-5.15-rc6' of ↵Linus Torvalds14-16/+50
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO driver fixes from Greg KH: "Here are a number of small IIO and staging driver fixes for 5.15-rc6. They include: - vc04_services bugfix for reported problem - r8188eu array underflow fix - iio driver fixes for a lot of tiny reported issues. All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: r8188eu: prevent array underflow in rtw_hal_update_ra_mask() staging: vc04_services: shut up out-of-range warning iio: light: opt3001: Fixed timeout error when 0 lux iio: adis16480: fix devices that do not support sleep mode iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED iio: adis16475: fix deadlock on frequency set iio: ssp_sensors: add more range checking in ssp_parse_dataframe() iio: ssp_sensors: fix error code in ssp_print_mcu_debug() iio: adc: ad7793: Fix IRQ flag iio: adc: ad7780: Fix IRQ flag iio: adc: ad7192: Add IRQ flag iio: adc: aspeed: set driver data when adc probe. iio: adc: rzg2l_adc: add missing clk_disable_unprepare() in rzg2l_adc_pm_runtime_resume() iio: adc: max1027: Fix the number of max1X31 channels iio: adc: max1027: Fix wrong shift with 12-bit devices iio: adc128s052: Fix the error handling path of 'adc128_probe()' iio: adc: rzg2l_adc: Fix -EBUSY timeout error return iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed iio: dac: ti-dac5571: fix an error code in probe()
2021-10-07iio/test-format: build kunit tests without structleak pluginBrendan Higgins1-0/+1
The structleak plugin causes the stack frame size to grow immensely when used with KUnit: ../drivers/iio/test/iio-test-format.c: In function ‘iio_test_iio_format_value_fixedpoint’: ../drivers/iio/test/iio-test-format.c:98:1: warning: the frame size of 2336 bytes is larger than 2048 bytes [-Wframe-larger-than=] Turn it off in this file. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-10-03iio: light: opt3001: Fixed timeout error when 0 luxJiri Valek - 2N1-3/+3
Reading from sensor returned timeout error under zero light conditions. Signed-off-by: Jiri Valek - 2N <valek@2n.cz> Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ") Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-26iio: adis16480: fix devices that do not support sleep modeNuno Sá1-3/+11
Not all devices supported by this driver support being put to sleep mode. For those devices, when calling 'adis16480_stop_device()' on the unbind path, we where actually writing in the SYNC_SCALE register. Fixes: 80cbc848c4fa0 ("iio: imu: adis16480: Add support for ADIS16490") Fixes: 82e7a1b250170 ("iio: imu: adis16480: Add support for ADIS1649x family of devices") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210903141423.517028-6-nuno.sa@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-26iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSEDHui Liu1-0/+8
The previous driver does't apply the necessary scaling to take the voltage range into account. We change readback value from raw data to input voltage to fix case IIO_CHAN_INFO_PROCESSED. Fixes: ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.") Signed-off-by: Hui Liu <hui.liu@mediatek.com> Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-25iio: adis16475: fix deadlock on frequency setNuno Sá1-1/+2
With commit 39c024b51b560 ("iio: adis16475: improve sync scale mode handling"), two deadlocks were introduced: 1) The call to 'adis_write_reg_16()' was not changed to it's unlocked version. 2) The lock was not being released on the success path of the function. This change fixes both these issues. Fixes: 39c024b51b560 ("iio: adis16475: improve sync scale mode handling") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210920090047.74903-1-nuno.sa@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-18iio: ssp_sensors: add more range checking in ssp_parse_dataframe()Dan Carpenter1-1/+8
The "idx" is validated at the start of the loop but it gets incremented during the iteration so it needs to be checked again. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210909091336.GA26312@kili Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-18iio: ssp_sensors: fix error code in ssp_print_mcu_debug()Dan Carpenter1-1/+1
The ssp_print_mcu_debug() function should return negative error codes on error. Returning "length" is meaningless. This change does not affect runtime because the callers only care about zero/non-zero. Reported-by: Jonathan Cameron <jic23@kernel.org> Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210914105333.GA11657@kili Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: ad7793: Fix IRQ flagAlexandru Tachici1-1/+1
In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7793 datasheet: " The DOUT/RDY falling edge can be used as an interrupt to a processor" Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210906065630.16325-4-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: ad7780: Fix IRQ flagAlexandru Tachici1-1/+1
Correct IRQ flag here is falling. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7780 datasheet: " The DOUT/Figure 22 RDY falling edge can be used as an interrupt to a processor" Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210906065630.16325-3-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: ad7192: Add IRQ flagAlexandru Tachici1-0/+1
IRQ type in ad_sigma_delta_info struct was missing. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7192 datasheet: "The DOUT/RDY falling edge can be used as an interrupt to a processor," Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210906065630.16325-2-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: aspeed: set driver data when adc probe.Billy Tsai1-0/+1
Fix the issue when adc remove will get the null driver data. Fixed: commit 573803234e72 ("iio: Aspeed ADC") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: rzg2l_adc: add missing clk_disable_unprepare() in ↵Yang Yingliang1-1/+3
rzg2l_adc_pm_runtime_resume() Add clk_disable_unprepare() on error path in rzg2l_adc_pm_runtime_resume(). Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210819132416.175644-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: max1027: Fix the number of max1X31 channelsMiquel Raynal1-1/+0
The macro MAX1X29_CHANNELS() already calls MAX1X27_CHANNELS(). Calling MAX1X27_CHANNELS() before MAX1X29_CHANNELS() in the definition of MAX1X31_CHANNELS() declares the first 8 channels twice. So drop this extra call from the MAX1X31 channels list definition. Fixes: 7af5257d8427 ("iio: adc: max1027: Prepare the introduction of different resolutions") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210818111139.330636-3-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: max1027: Fix wrong shift with 12-bit devicesMiquel Raynal1-1/+1
10-bit devices must shift the value twice. This is not needed anymore on 12-bit devices. Fixes: ae47d009b508 ("iio: adc: max1027: Introduce 12-bit devices support") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210818111139.330636-2-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc128s052: Fix the error handling path of 'adc128_probe()'Christophe JAILLET1-0/+6
A successful 'regulator_enable()' call should be balanced by a corresponding 'regulator_disable()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: adc: rzg2l_adc: Fix -EBUSY timeout error returnColin Ian King1-1/+1
Currently when a timeout occurs in rzg2l_adc_hw_init the error -EBUSY is assigned to ret but the error code is used as the function is hard-coded to return 0. The variable ret is 0 before entering the while-loop hence the fix is just to return ret at the end of the function to return the success 0 or -EBUSY return code. Addresses-Coverity: ("Unused value") Fixes: d484c21bacfa ("iio: adc: Add driver for Renesas RZ/G2L A/D converter") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210817172111.495897-1-colin.king@canonical.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushedSean Nyekjaer1-1/+1
fxls8962af_fifo_flush() will return the samples flushed. So return IRQ_NONE only if an error is returned. Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20210817124336.1672169-1-sean@geanix.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: dac: ti-dac5571: fix an error code in probe()Dan Carpenter1-0/+1
If we have an unexpected number of channels then return -EINVAL instead of returning success. Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210816183954.GB2068@kili Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-08Merge branch 'akpm' (patches from Andrew)Linus Torvalds2-4/+2
Merge more updates from Andrew Morton: "147 patches, based on 7d2a07b769330c34b4deabeed939325c77a7ec2f. Subsystems affected by this patch series: mm (memory-hotplug, rmap, ioremap, highmem, cleanups, secretmem, kfence, damon, and vmscan), alpha, percpu, procfs, misc, core-kernel, MAINTAINERS, lib, checkpatch, epoll, init, nilfs2, coredump, fork, pids, criu, kconfig, selftests, ipc, and scripts" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (94 commits) scripts: check_extable: fix typo in user error message mm/workingset: correct kernel-doc notations ipc: replace costly bailout check in sysvipc_find_ipc() selftests/memfd: remove unused variable Kconfig.debug: drop selecting non-existing HARDLOCKUP_DETECTOR_ARCH configs: remove the obsolete CONFIG_INPUT_POLLDEV prctl: allow to setup brk for et_dyn executables pid: cleanup the stale comment mentioning pidmap_init(). kernel/fork.c: unexport get_{mm,task}_exe_file coredump: fix memleak in dump_vma_snapshot() fs/coredump.c: log if a core dump is aborted due to changed file permissions nilfs2: use refcount_dec_and_lock() to fix potential UAF nilfs2: fix memory leak in nilfs_sysfs_delete_snapshot_group nilfs2: fix memory leak in nilfs_sysfs_create_snapshot_group nilfs2: fix memory leak in nilfs_sysfs_delete_##name##_group nilfs2: fix memory leak in nilfs_sysfs_create_##name##_group nilfs2: fix NULL pointer in nilfs_##name##_attr_release nilfs2: fix memory leak in nilfs_sysfs_create_device_group trap: cleanup trap_init() init: move usermodehelper_enable() to populate_rootfs() ...
2021-09-08iio/drivers/hid-sensor: use HZ macrosDaniel Lezcano1-2/+1
HZ unit conversion macros are available in units.h, use them and remove the duplicate definition. Link: https://lkml.kernel.org/r/20210816114732.1834145-8-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Christian Eggers <ceggers@arri.de> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Lukasz Luba <lukasz.luba@arm.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: MyungJoo Ham <myungjoo.ham@samsung.com> Cc: Peter Meerwald <pmeerw@pmeerw.net> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-08iio/drivers/as73211: use HZ macrosDaniel Lezcano1-2/+1
HZ unit conversion macros are available in units.h, use them and remove the duplicate definition. Link: https://lkml.kernel.org/r/20210816114732.1834145-6-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Lukasz Luba <lukasz.luba@arm.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: MyungJoo Ham <myungjoo.ham@samsung.com> Cc: Peter Meerwald <pmeerw@pmeerw.net> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-01Merge tag 'staging-5.15-rc1' of ↵Linus Torvalds80-687/+2386
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull IIO and staging driver updates from Greg KH: "Here is the big set of staging and IIO driver updates for 5.15-rc1. Also included in here are the counter driver subsystem updates as the IIO drivers needed them. Lots of churn in some staging drivers, we dropped the "old" rtl8188eu driver and replaced it with a newer version of the driver that had been maintained out-of-tree by Larry with the end goal of actually being able to get this driver out of staging eventually. Despite that driver being "newer" the line count of this pull request is going up. Some drivers moved out of staging as well, which is always nice to see, that is why there are additions to the mfc and misc driver subsystems. All of these were acked by the various subsystem maintainers involved. But by far, as normal, it's coding style cleanups all over the drivers/staging/ tree in here. Full details of these changes are in the shortlog. All of these have been in linux-next for a while with no reported problems" [ Note: the r8188eu merge clashed with commit 89939e890605 ("staging: rtlwifi: use siocdevprivate") from the networking tree. When resolving the issue, I noted that the whole r8188eu rtw_android code is dead since commit ae7471cae00a ("staging: r8188eu: remove rtw_ioctl function"). End result: the merge resolution was to throw all of that away, rather than do the mindless fixup to code that isn't actually reachable - Linus ] * tag 'staging-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (551 commits) staging: vt6655: Remove filenames in files staging: r8188eu: add extra TODO entries staging: vt6656: Remove filenames in files staging: wlan-ng: fix invalid assignment warning staging: r8188eu: rename fields of struct rtl_ps staging: r8188eu: remove ODM_DynamicPrimaryCCA_DupRTS() staging: r8188eu: rename fields of struct dyn_primary_cca staging: r8188eu: rename struct field Wifi_Error_Status staging: r8188eu: Provide a TODO file for this driver staging: r8188eu: remove unneeded variable staging: r8188eu: remove unneeded conversions to bool staging: r8188eu: remove {read,write}_macreg staging: r8188eu: core: remove condition with no effect staging: r8188eu: remove ethernet.h header file staging: r8188eu: remove ip.h header file staging: r8188eu: remove if_ether.h header file staging: r8188eu: make rtw_deinit_intf_priv return void staging: r8188eu: use is_multicast_ether_addr in os_dep/recv_linux.c staging: r8188eu: use is_multicast_ether_addr in hal/rtl8188eu_xmit.c staging: r8188eu: use is_multicast_ether_addr in core/rtw_xmit.c ...
2021-08-30Merge tag 'for-v5.15' of ↵Linus Torvalds1-0/+23
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: "Battery/charger related: - cros-peripheral-charger: new driver - mt6360-charger: new driver - simple-battery: support reading chemistry info - max17042-battery: add max77849 support - sbs-battery: add time_to_empty_now support - smb347-charger: prepare USB OTG support - rn5t618: add voltage_now support - axp288: cleanup & optimizations - max17042_battery: cleanups - ab8500: cleanups - misc minor cleanups and DT binding fixes reset related: - tps65086-restart: new driver - linkstation-poweroff: support NETGEAR ReadyNAS Duo v2" * tag 'for-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (51 commits) power: supply: core: Fix parsing of battery chemistry/technology power: supply: max17042_battery: log SOC threshold using debug log level power: supply: max17042_battery: more robust chip type checks power: supply: max17042_battery: fix typo in MAx17042_TOFF power: supply: max17042_battery: clean up MAX17055_V_empty power: supply: smb347-charger: Implement USB VBUS regulator power: supply: smb347-charger: Add missing pin control activation power: supply: smb347-charger: Utilize generic regmap caching power: supply: smb347-charger: Make smb347_set_writable() IRQ-safe dt-bindings: power: supply: smb347-charger: Document USB VBUS regulator power: reset: Add TPS65086 restart driver dt-bindings: power: supply: max17042: describe interrupt power: supply: max17042: remove duplicated STATUS bit defines power: supply: max17042: handle fails of reading status register power: supply: core: Parse battery chemistry/technology dt-bindings: power: Extend battery bindings with chemistry power: reset: linkstation-poweroff: add new device power: reset: linkstation-poweroff: prepare for new devices power: supply: bq24735: reorganize ChargeOption command macros power: supply: rn5t618: Add voltage_now property ...
2021-08-17Merge tag 'iio-for-5.15b' of ↵Greg Kroah-Hartman9-52/+1027
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: 2nd set of new IIO device support and cleanups for the 5.15 cycle. A small pull request to pick up a few new drivers and some cleanup and fix patches. New device support * ad5110 non-volatile digital potentiometer - New driver * renesas rzl/gl2 12-bit / 8 channel ADC block - New driver and bindings Minor or late breaking fixes and cleanups * ltc2983 - Fix a false assumption of initial interrupt during probe(). * hp03 - Use devm_* to simplify probe and allow the remove function to be dropped. * rockchip_saradc - Use a regulator notifier to reduce overheads of querying the scale. * tag 'iio-for-5.15b' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: adc: Add driver for Renesas RZ/G2L A/D converter dt-bindings: iio: adc: Add binding documentation for Renesas RZ/G2L A/D converter iio: pressure: hp03: update device probe to register with devm functions iio: adc: rockchip_saradc: add voltage notifier so get referenced voltage once at probe iio: ltc2983: fix device probe iio: potentiometer: Add driver support for AD5110 dt-bindings: iio: potentiometer: Add AD5110 in trivial-devices
2021-08-16Merge 5.14-rc6 into staging-nextGreg Kroah-Hartman6-8/+10
We need the IIO fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-15iio: adc: Add driver for Renesas RZ/G2L A/D converterLad Prabhakar3-0/+611
Add ADC driver support for Renesas RZ/G2L A/D converter in SW trigger mode. A/D Converter block is a successive approximation analog-to-digital converter with a 12-bit accuracy and supports a maximum of 8 input channels. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210804202118.25745-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-15iio: pressure: hp03: update device probe to register with devm functionsThéo Borém Fabris1-29/+7
Update device probe to register resources with device-managed functions. Further, get rid of device-specific remove callback which is no longer needed. Signed-off-by: Théo Borém Fabris <theobf@usp.br> Link: https://lore.kernel.org/r/20210809203014.10955-1-theobf@usp.br Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-15iio: adc: rockchip_saradc: add voltage notifier so get referenced voltage ↵David Wu1-7/+40
once at probe Add voltage notifier, no need to query regulator voltage for every saradc read, just get regulator voltage once at probe. Signed-off-by: David Wu <david.wu@rock-chips.com> Signed-off-by: Simon Xue <xxm@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20210810011007.54066-1-xxm@rock-chips.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-15iio: ltc2983: fix device probeNuno Sá1-16/+14
There is no reason to assume that the IRQ rising edge (indicating that the device start up phase is done) will happen after we request the IRQ. If the device is already up by the time we request it, the call to 'wait_for_completion_timeout()' will timeout and we will fail the device probe even though there's nothing wrong. Fix it by just polling the status register until we get the indication that the device is up and running. As a side effect of this fix, requesting the IRQ is also moved to after the setup function. Fixes: f110f3188e563 ("iio: temperature: Add support for LTC2983") Reported-and-tested-by: Drew Fustini <drew@pdp7.com> Reviewed-by: Drew Fustini <drew@pdp7.com> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210811133220.190264-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-15iio: potentiometer: Add driver support for AD5110Mugilraj Dhavachelvan3-0/+355
The AD5110/AD5112/AD5114 provide a nonvolatile solution for 128-/64-/32-position adjustment applications, offering guaranteed low resistor tolerance errors of ±8% and up to ±6 mA current density. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5110_5112_5114.pdf Signed-off-by: Mugilraj Dhavachelvan <dmugil2000@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210814175607.48399-3-dmugil2000@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-13iio: adc: rn5t618: Add iio mapAndreas Kemnade1-0/+23
Add iio map to allow power driver to read out values as a consumer. This approach does not block later addition of devicetree support which would be helpful if there is an in-kernel consumer for AIN0/1. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-08-09iio: hid-sensor-press: Add timestamp channelYe Xiang1-16/+24
Each sample has a timestamp field with this change. This timestamp may be from the sensor hub when present or local kernel timestamp. The unit of timestamp is nanosecond. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210731032556.26813-1-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-08iio: accel: bmc150: Add support for BMC156Stephan Gerhold5-9/+45
BMC156 is another accelerometer that works just fine with the bmc150-accel driver. It's very similar to BMC150 (also a accelerometer + magnetometer combo) but with only one accelerometer interrupt pin. It would make sense if only INT1 was exposed but someone at Bosch decided to only have an INT2 pin. Try to deal with this by making use of the INT2 support introduced in the previous commit and force using INT2 for BMC156. To detect that we need to bring up a simplified version of the previous type IDs. Note that unlike the type IDs removed in commit c06a6aba6835 ("iio: accel: bmc150: Drop misleading/duplicate chip identifiers") here I only add one for the special case of BMC156. Everything else still happens by reading the CHIP_ID register since the chip type information often is not accurate in ACPI tables. Tested-by: Nikita Travkin <nikita@trvn.ru> # BMC156 Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210802155657.102766-5-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-08iio: accel: bmc150: Make it possible to configure INT2 instead of INT1Stephan Gerhold1-12/+59
Some Bosch accelerometers have two interrupt pins (INT1 and INT2). At the moment, the driver uses only the first one, which is fine for most situations. However, some boards might only have INT2 connected for some reason. Add the necessary bits and configuration to set up INT2. Then try to detect this situation at least for device tree setups by checking if the first interrupt (the one picked by the I2C/SPI core) is actually named "INT2" using the interrupt-names property. of_irq_get_byname() returns either 0 or some error code in case the driver probed without device tree, so in all other cases we fall back to configuring INT1 as before. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210802155657.102766-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-13 04:13:51 +0300