aboutsummaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2021-01-22iio:pressure:ms5637: introduce hardware differentiationAlexandre Belloni
Some sensors in the ms58xx family have a different PROM length and a different number of available resolution. introduce struct ms_tp_hw_data to handle those differences. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210109231148.1168104-3-alexandre.belloni@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: dac: ad5766: add driver support for AD5766Cristian Pop
The AD5766/AD5767 are 16-channel, 16-bit/12-bit, voltage output dense DACs Digital-to-Analog converters. This change adds support for these DACs. Signed-off-by: Cristian Pop <cristian.pop@analog.com> Link: https://lore.kernel.org/r/20210115112105.58652-3-cristian.pop@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensor-rotation: Add timestamp channelYe Xiang
Each sample has a timestamp field with this change. This timestamp may be from the sensor hub when present or local kernel timestamp. And the unit of timestamp is nanosecond. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210105093515.19135-7-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensor-incl-3d: Add timestamp channelYe Xiang
Each sample has a timestamp field with this change. This timestamp may be from the sensor hub when present or local kernel timestamp. And the unit of timestamp is nanosecond. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210105093515.19135-6-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensor-magn-3d: Add timestamp channelYe Xiang
Each sample has a timestamp field with this change. This timestamp may be from the sensor hub when present or local kernel timestamp. And the unit of timestamp is nanosecond. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210105093515.19135-5-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensor-als: Add timestamp channelYe Xiang
Each sample has a timestamp field with this change. This timestamp may be from the sensor hub when present or local kernel timestamp. And the unit of timestamp is nanosecond. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210105093515.19135-4-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensor-gyro-3d: Add timestamp channelYe Xiang
Each sample has a timestamp field with this change. This timestamp may be from the sensor hub when present or local kernel timestamp. And the unit of timestamp is nanosecond. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210105093515.19135-3-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensor-accel-3d: Add timestamp channel for gravity sensorYe Xiang
The accel_3d sensor already has a timestamp channel, this patch just replicate that for gravity sensor. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210105093515.19135-2-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: magnetometer: bmc150: Add rudimentary regulator supportStephan Gerhold
BMC150 needs VDD and VDDIO regulators that might need to be explicitly enabled. Add some rudimentary support to obtain and enable these regulators during probe() and disable them during remove() or on the error path. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210109152327.512538-2-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: Handle enumerated properties with gapsLars-Peter Clausen
Some enums might have gaps or reserved values in the middle of their value range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a meaning, but 2 is a reserved value and can not be used. Add support for such enums to the IIO enum helper functions. A reserved values is marked by setting its entry in the items array to NULL rather than the normal descriptive string value. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210107112049.10815-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: hid-sensors: Add hinge sensor driverYe Xiang
The Hinge sensor is a common custom sensor on laptops. It calculates the angle between the lid (screen) and the base (keyboard). In addition, it also exposes screen and the keyboard angles with respect to the ground. Applications can easily get laptop's status in space through this sensor, in order to display appropriate user interface. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20201215054444.9324-3-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: gyro: bmg160: Add rudimentary regulator supportStephan Gerhold
BMG160 needs VDD and VDDIO regulators that might need to be explicitly enabled. Add some rudimentary support to obtain and enable these regulators during probe() and disable them using a devm action. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201211183815.51269-2-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-22iio: accel: kxcjk1013: Add rudimentary regulator supportDevajith V S
kxcjk1013 devices have VDD and VDDIO power lines. Need to make sure the regulators are enabled before any communication with kxcjk1013. This patch introduces vdd/vddio regulators for kxcjk1013. Signed-off-by: Devajith V S <devajithvs@gmail.com> Link: https://lore.kernel.org/r/20201213172437.2779-2-devajithvs@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: adc: ad7476: Add LTC2314-14 supportDragos Bogdan
The LTC2314-14 is a 14-bit, 4.5Msps, serial sampling A/D converter that draws only 6.2mA from a wide range analog supply adjustable from 2.7V to 5.25V. Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com> Link: https://lore.kernel.org/r/20201216083639.89425-1-mircea.caprioru@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: adc: stm32-adc: Remove redundant null check before ↵Xu Wang
clk_prepare_enable/clk_disable_unprepare Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20201218093512.871-1-vulab@iscas.ac.cn Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: frequency: adf4350: Remove redundant null check before ↵Xu Wang
clk_disable_unprepare Because clk_disable_unprepare() already checked NULL clock parameter, so the additional check is unnecessary, just remove it. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Link: https://lore.kernel.org/r/20201218094647.1386-1-vulab@iscas.ac.cn Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: adc: ab8500-gpadc: Support non-hw-conversionLinus Walleij
The hardware conversion mode only exists in the AB8500 version of the chip, as it is lacking in the AB8505 it will not be in the device tree and we should just not even try to obtain it. The driver already contains code to avoid using a non-existing hardware conversion IRQ at conversion time. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201218222013.383704-1-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: sc27xx_adc: Use DIV_ROUND_CLOSEST() instead of open-coding itLars-Peter Clausen
Use DIV_ROUND_CLOSEST() instead of open-coding it. This makes it more clear what is going on for the casual reviewer. Generated using the following the Coccinelle semantic patch. // <smpl> @@ expression x, y; @@ -((x) + ((y) / 2)) / (y) +DIV_ROUND_CLOSEST(x, y) // </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lore.kernel.org/r/20201222191618.3433-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: magnetometer: Add driver for Yamaha YAS530Linus Walleij
This adds an IIO magnetometer driver for the Yamaha YAS530 family of magnetometer/compass chips YAS530, YAS532 and YAS533. A quick survey of the source code released by different vendors reveal that we have these variants in the family with some deployments listed: * YAS529 MS-3C (2005 Samsung Aries) * YAS530 MS-3E (2011 Samsung Galaxy S Advance) * YAS532 MS-3R (2011 Samsung Galaxy S4) * YAS533 MS-3F (Vivo 1633, 1707, V3, Y21L) * (YAS534 is a magnetic switch) * YAS535 MS-6C * YAS536 MS-3W * YAS537 MS-3T (2015 Samsung Galaxy S6, Note 5) * YAS539 MS-3S (2018 Samsung Galaxy A7 SM-A750FN) The YAS529 is so significantly different from the YAS53x variants that it will require its own driver. The YAS537 and YAS539 have slightly different register sets but have strong similarities so a common driver patching this one will probably be reasonable. The source code for Samsung Galaxy A7's YAS539 is not that is significantly different from the YAS530 in the Galaxy S Advance, so I believe we will only need this one driver with quirks to handle all of them. The YAS539 is actively announced on Yamaha's devices site: https://device.yamaha.com/en/lsi/products/e_compass/ This is a driver written from scratch using buffered IIO and runtime PM handling regulators and reset. Thanks to Andy Shevchenko for great help in finding all the special kernel infrastructure functions and quirks during review of this driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: phone-devel@vger.kernel.org Cc: Jonathan Bakker <xc-racer2@live.ca> Link: https://lore.kernel.org/r/20201224120820.1120099-2-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: tsl2583: Use DIV_ROUND_CLOSEST() instead of open-coding itLars-Peter Clausen
Use DIV_ROUND_CLOSEST() instead of open-coding it. This documents intent and makes it more clear what is going on for the casual reviewer. Generated using the following the Coccinelle semantic patch. // <smpl> @r1@ expression x; constant C1; constant C2; @@ ((x) + C1) / C2 @script:python@ C1 << r1.C1; C2 << r1.C2; @@ try: if int(C1) * 2 != int(C2): cocci.include_match(False) except: cocci.include_match(False) @@ expression r1.x; constant r1.C1; constant r1.C2; @@ -(((x) + C1) / C2) +DIV_ROUND_CLOSEST(x, C2) // </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201227171126.28216-3-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: bme680: Use DIV_ROUND_CLOSEST() instead of open-coding itLars-Peter Clausen
Use DIV_ROUND_CLOSEST() instead of open-coding it. This documents intent and makes it more clear what is going on for the casual reviewer. Generated using the following the Coccinelle semantic patch. // <smpl> @r1@ expression x; constant C1; constant C2; @@ ((x) + C1) / C2 @script:python@ C1 << r1.C1; C2 << r1.C2; @@ try: if int(C1) * 2 != int(C2): cocci.include_match(False) except: cocci.include_match(False) @@ expression r1.x; constant r1.C1; constant r1.C2; @@ -(((x) + C1) / C2) +DIV_ROUND_CLOSEST(x, C2) // </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20201227171126.28216-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: vl6180: Use DIV_ROUND_CLOSEST() instead of open-coding itLars-Peter Clausen
Use DIV_ROUND_CLOSEST() instead of open-coding it. This documents intent and makes it more clear what is going on for the casual reviewer. Generated using the following the Coccinelle semantic patch. // <smpl> @r1@ expression x; constant C1; constant C2; @@ ((x) + C1) / C2 @script:python@ C1 << r1.C1; C2 << r1.C2; @@ try: if int(C1) * 2 != int(C2): cocci.include_match(False) except: cocci.include_match(False) @@ expression r1.x; constant r1.C1; constant r1.C2; @@ -(((x) + C1) / C2) +DIV_ROUND_CLOSEST(x, C2) // </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://lore.kernel.org/r/20201227171126.28216-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio:light:apds9960 add detection for MSHW0184 ACPI device in apds9960 driverMax Leiter
The device is used in the Microsoft Surface Book 3 and Surface Pro 7 Signed-off-by: Max Leiter <maxwell.leiter@gmail.com> Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20201220015057.107246-1-maxwell.leiter@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: imu: inv_mpu6050: Add support for MPU-6880Stephan Gerhold
MPU-6880 seems to be very similar to MPU-6500 and it works fine with some minor additions for the mpu6050 driver. Add the necessary defines for it and make it use the same registers as MPU-6500 but with a FIFO size of 4096. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Link: https://lore.kernel.org/r/20201202104656.5119-2-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: chemical: pms7003: convert comma to semicolonZheng Yongjun
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20201211085700.3037-1-zhengyongjun3@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: core: Copy iio_info.attrs->is_visible into ↵Hans de Goede
iio_dev_opaque.chan_attr_group.is_visible The iio-core extends the attr_group provided by the driver with its own attributes. To be able to do this it: 1. Has its own (non const) io_dev_opaque.chan_attr_group attr_group struct 2. It allocates a new attrs array with room for both the drivers and its own attributes 3. It copies over the driver provided attributes into the newly allocated attrs array. But the drivers attr_group may contain more then just the attrs array, it may also contain an is_visible callback and at least the adi-axi-adc.c is currently defining such a callback. Change the attr_group copying code to also copy over the is_visible callback, so that drivers can define one and have it workins as is normal for attr_group-s all over the kernel. Note that the is_visible callback takes an index into the array as argument, so that indices of the driver's attributes must not change, this is not a problem as the driver's own attributes are added first to the newly allocated attrs array and the attributes handled by the core are appended after the driver's attributes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20201125084606.11404-2-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: adc: xilinx: use more devres helpers and remove remove()Bartosz Golaszewski
In order to simplify resource management and error paths in probe() and entirely drop the remove() callback - use devres helpers wherever possible. Define devm actions for cancelling the delayed work and disabling the clock. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Anand Ashok Dumbre <anandash@xilinx.com> Reviewed-by: Anand Ashok Dumbre <anandash@xilinx.com> Link: https://lore.kernel.org/r/20201130142759.28216-4-brgl@bgdev.pl Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: adc: xilinx: use devm_krealloc() instead of kfree() + kcalloc()Bartosz Golaszewski
We now have devm_krealloc() in the kernel Use it indstead of calling kfree() and kcalloc() separately. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Anand Ashok Dumbre <anandash@xilinx.com> Reviewed-by: Anand Ashok Dumbre <anandash@xilinx.com> Link: https://lore.kernel.org/r/20201130142759.28216-3-brgl@bgdev.pl Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: adc: xilinx: use helper variable for &pdev->devBartosz Golaszewski
It's more elegant to use a helper local variable to store the address of the underlying struct device than to dereference pdev everywhere. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Anand Ashok Dumbre <anandash@xilinx.com> Reviewed-by: Anand Ashok Dumbre <anandash@xilinx.com> Link: https://lore.kernel.org/r/20201130142759.28216-2-brgl@bgdev.pl Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-01-09iio: xilinx-xadc: Add basic support for Ultrascale System MonitorLars-Peter Clausen
The xilinx-xadc IIO driver currently has support for the XADC in the Xilinx 7 series FPGAs. The system-monitor is the equivalent to the XADC in the Xilinx UltraScale and UltraScale+ FPGAs. The IP designers did a good job at maintaining backwards compatibility and only minor changes are required to add basic support for the system-monitor core. The non backwards compatible changes are: * Register map offset was moved from 0x200 to 0x400 * Only one ADC compared to two in the XADC * 10 bit ADC instead of 12 bit ADC * Two of the channels monitor different supplies Add the necessary logic to accommodate these changes to support the system-monitor in the XADC driver. Note that this patch does not include support for some new features found in the system-monitor like additional alarms, user supply monitoring and secondary system-monitor access. This might be added at a later time. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Tested-by: Anand Ashok Dumbre <anandash@xilinx.com> Reviewed-by: Anand Ashok Dumbre <anandash@xilinx.com> Link: https://lore.kernel.org/r/20200922134624.13191-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-15Merge tag 'staging-5.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging / IIO driver updates from Greg KH: "Here is the big staging and IIO driver pull request for 5.11-rc1 Lots of different things in here: - loads of driver updates - so many coding style cleanups - new IIO drivers - Android ION code is finally removed from the tree - wimax drivers are moved to staging on their way out of the kernel Nothing really exciting, just the constant grind of kernel development :) All have been in linux-next for a while with no reported issues" * tag 'staging-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (341 commits) staging: olpc_dcon: Do not call platform_device_unregister() in dcon_probe() staging: most: Fix spelling mistake "tranceiver" -> "transceiver" staging: qlge: remove duplicate word in comment staging: comedi: mf6x4: Fix AI end-of-conversion detection staging: greybus: Add TODO item about modernizing the pwm code pinctrl: ralink: add a pinctrl driver for the rt2880 family dt-bindings: pinctrl: rt2880: add binding document staging: rtl8723bs: remove ELEMENT_ID enum staging: rtl8723bs: remove unused macros staging: rtl8723bs: replace EID_EXTCapability staging: rtl8723bs: replace EID_BSSIntolerantChlReport staging: rtl8723bs: replace EID_BSSCoexistence staging: rtl8723bs: replace _MME_IE_ staging: rtl8723bs: replace _WAPI_IE_ staging: rtl8723bs: replace _EXT_SUPPORTEDRATES_IE_ staging: rtl8723bs: replace _ERPINFO_IE_ staging: rtl8723bs: replace _CHLGETXT_IE_ staging: rtl8723bs: replace _COUNTRY_IE_ staging: rtl8723bs: replace _IBSS_PARA_IE_ staging: rtl8723bs: replace _TIM_IE_ ...
2020-12-03iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in ↵Qinglang Miao
rockchip_saradc_resume Fix the missing clk_disable_unprepare() of info->pclk before return from rockchip_saradc_resume in the error handling case when fails to prepare and enable info->clk. Suggested-by: Robin Murphy <robin.murphy@arm.com> Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc") Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: imu: st_lsm6dsx: fix edge-trigger interruptsLorenzo Bianconi
If we are using edge IRQs, new samples can arrive while processing current interrupt since there are no hw guarantees the irq line stays "low" long enough to properly detect the new interrupt. In this case the new sample will be missed. Polling FIFO status register in st_lsm6dsx_handler_thread routine allow us to read new samples even if the interrupt arrives while processing previous data and the timeslot where the line is "low" is too short to be properly detected. Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts") Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: sysfs-trigger: Mark irq_work to expire in hardirq contextLars-Peter Clausen
Mark the IIO sysfs-trigger irq_work with IRQ_WORK_HARD_IRQ to ensure that it is always executed in hard interrupt context, even with PREEMPT_RT=y. The IIO sysfs-trigger irq_work needs to run in hard interrupt context since it will end up calling generic_handle_irq() which has the requirement to run in hard interrupt context. Note that the IRQ_WORK_HARD_IRQ flag, while it exists, does not seem to do anything in the mainline kernel yet. It does have an effect in the RT patchset though and presumably this is sooner or later going to be added to mainline as well. Reported-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20201117103751.16131-2-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt contextLars-Peter Clausen
On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. The IIO hrtimer-trigger needs to run in hard interrupt context since it will end up calling generic_handle_irq() which has the requirement to run in hard interrupt context. Explicitly specify that the timer needs to run in hard interrupt context by using the HRTIMER_MODE_REL_HARD flag. Fixes: f5c2f0215e36 ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT") Reported-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150: Get mount-matrix from ACPIHans de Goede
bmc150 accelerometers with an ACPI hardware-id of BOSC0200 have an ACPI method providing their mount-matrix, add support for retrieving this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-3-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150: Check for a second ACPI device for BOSC0200Jeremy Cline
Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI device. Normally we would handle this by letting the special drivers/platform/x86/i2c-multi-instantiate.c driver handle the BOSC0200 ACPI id and let it instantiate 2 bmc150_accel type i2c_client-s for us. But doing so changes the modalias for the first accelerometer (which is already supported and used on many devices) from acpi:BOSC0200 to i2c:bmc150_accel. The modalias is not only used to load the driver, but is also used by hwdb matches in /lib/udev/hwdb.d/60-sensor.hwdb which provide a mountmatrix to userspace by setting the ACCEL_MOUNT_MATRIX udev property. Switching the handling of the BOSC0200 over to i2c-multi-instantiate.c will break the hwdb matches causing the ACCEL_MOUNT_MATRIX udev prop to no longer be set. So switching over to i2c-multi-instantiate.c is not an option. Changes by Hans de Goede: -Add explanation to the commit message why i2c-multi-instantiate.c cannot be used -Also set the dev_name, fwnode and irq i2c_board_info struct members for the 2nd client Signed-off-by: Jeremy Cline <jeremy@jcline.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-2-hdegoede@redhat.com BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198671 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio: accel: bmc150: Removed unused bmc150_accel_dat irq memberHans de Goede
The bmc150_accel_dat struct irq member is only ever used inside bmc150_accel_core_probe, drop it and just use the function argument directly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-1-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-12-03iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break upJonathan Cameron
Inspired by Andy Shevchenko's proposal to use get_unaligned_leXX(). The whole one time programable memory is treated as a single 64bit little endian value. Thus we can avoid a lot of messy handling of fields overlapping byte boundaries by just loading and manipulating it as an __le64 converted to a u64. That lets us just use FIELD_GET() and GENMASK() to extract the values desired. Note only build tested. We need to use GENMASK_ULL and %llX formatters to account for the larger types used in computing the various fields. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201128185156.428327-1-jic23@kernel.org Link: https://lore.kernel.org/r/20201129184459.647538-1-jic23@kernel.org
2020-12-03iio:adc:ti-ads124s08: Fix alignment and data leak issues.Jonathan Cameron
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver the timestamp can end up in various different locations depending on what other channels are enabled. As a result, we don't use a structure to specify it's position as that would be misleading. Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Dan Murphy <dmurphy@ti.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
2020-12-03iio:adc:ti-ads124s08: Fix buffer being too long.Jonathan Cameron
The buffer is expressed as a u32 array, yet the extra space for the s64 timestamp was expressed as sizeof(s64)/sizeof(u16). This will result in 2 extra u32 elements. Fix by dividing by sizeof(u32). Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code") Signed-off-by: Jonathan Cameron<Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Dan Murphy <dmurphy@ti.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-8-jic23@kernel.org
2020-12-03iio:pressure:mpl3115: Force alignment of bufferJonathan Cameron
Whilst this is another case of the issue Lars reported with an array of elements of smaller than 8 bytes being passed to iio_push_to_buffers_with_timestamp(), the solution here is a bit different from the other cases and relies on __aligned working on the stack (true since 4.6?) This one is unusual. We have to do an explicit memset() each time as we are reading 3 bytes into a potential 4 byte channel which may sometimes be a 2 byte channel depending on what is enabled. As such, moving the buffer to the heap in the iio_priv structure doesn't save us much. We can't use a nice explicit structure on the stack either as the data channels have different storage sizes and are all separately controlled. Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Peter Meerwald <pmeerw@pmeerw.net> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-7-jic23@kernel.org
2020-12-03iio:imu:bmi160: Fix alignment and data leak issuesJonathan Cameron
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
2020-12-03iio:imu:bmi160: Fix too large a buffer.Jonathan Cameron
The comment implies this device has 3 sensor types, but it only has an accelerometer and a gyroscope (both 3D). As such the buffer does not need to be as long as stated. Note I've separated this from the following patch which fixes the alignment for passing to iio_push_to_buffers_with_timestamp() as they are different issues even if they affect the same line of code. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org
2020-12-03iio:magnetometer:mag3110: Fix alignment and data leak issues.Jonathan Cameron
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
2020-12-03iio:light:st_uvis25: Fix timestamp alignment and prevent data leak.Jonathan Cameron
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() This data is allocated with kzalloc() so no data can leak apart from previous readings. A local unsigned int variable is used for the regmap call so it is clear there is no potential issue with writing into the padding of the structure. Fixes: 3025c8688c1e ("iio: light: add support for UVIS25 sensor") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
2020-12-03iio:light:rpr0521: Fix timestamp alignment and prevent data leak.Jonathan Cameron
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device. The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile. >From personal communications with Mikko: We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles. Fixes: e12ffd241c00 ("iio: light: rpr0521 triggered buffer") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Mikko Koivunen <mikko.koivunen@fi.rohmeurope.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org
2020-12-03iio:adc:ti-adc084s021 Tidy up endian typesJonathan Cameron
By adding a few local variables and avoiding a void * for a parameter we can easily make all the endian types explicit and get rid of the warnings from sparse: CHECK drivers/iio/adc/ti-adc084s021.c drivers/iio/adc/ti-adc084s021.c:84:26: warning: incorrect type in assignment (different base types) drivers/iio/adc/ti-adc084s021.c:84:26: expected unsigned short [usertype] drivers/iio/adc/ti-adc084s021.c:84:26: got restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200722155103.979802-23-jic23@kernel.org
2020-12-03iio:trigger: rename try_reenable() to reenable() plus return voidJonathan Cameron
As we no longer support a try again if we cannot reenable the trigger rename the function to reflect this. Also we don't do anything with the value returned so stop it returning anything. For the few drivers that didn't already print an error message in this patch, add such a print. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Christian Oder <me@myself5.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nishant Malpani <nish.malpani25@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org
2020-12-03iio: Fix: Do not poll the driver again if try_reenable() callback returns non 0.Jonathan Cameron
The original reason for this behaviour is long gone and no current drivers are making use of this function correctly. Note however, that you would be very unlucky to actually hit the problem as it would require a bus comms failure in the callback. This dates back a long way. The original board on which I did a lot of early IIO development only supported edge interrupts, but some of the sensors were level interrupt based. As such, the lis3l02dq driver did a dance with checking a GPIO to identify if it should retrigger. That was an unsustainable hack so we later just stopped supporting interrupts for that particular combination. There are a number of drivers where a fault on a bus read in the try_reenable() callback will result in them returning non 0 and incorrectly then causing iio_trigger_poll() to be called. Anyhow, this handling is unused and causing issues so let us rip it out. Link: https://lore.kernel.org/linux-iio/20200813075358.13310-1-lars@metafoo.de/ After this the try_reenable() naming makes no sense, so as a follow up patch I'll rename it to simply reenable(). I haven't done that here as it will add noise to the fix for backporting. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Christian Eggers <ceggers@arri.de> Link: https://lore.kernel.org/r/20200920132548.196452-2-jic23@kernel.org
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 02:10:38 +0000