summaryrefslogtreecommitdiff
path: root/drivers/iio/accel
AgeCommit message (Collapse)Author
2021-11-17iio: mma8452: Fix trigger reference coutingLars-Peter Clausen
The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call `iio_trigger_put()` to drop the reference count by 1. Without the matching `iio_trigger_get()` in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs. Fix this by getting a reference to the trigger before assigning it to the IIO device. Fixes: ae6d9ce05691 ("iio: mma8452: Add support for interrupt driven triggers.") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211024092700.6844-1-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-11-17iio: kxsd9: Don't return error code in trigger handlerLars-Peter Clausen
IIO trigger handlers need to return one of the irqreturn_t values. Returning an error code is not supported. The kxsd9 interrupt handler returns an error code if reading the data registers fails. In addition when exiting due to an error the trigger handler does not call `iio_trigger_notify_done()`. Which when not done keeps the triggered disabled forever. Modify the code so that the function returns a valid irqreturn_t value as well as calling `iio_trigger_notify_done()` on all exit paths. Since we can't return the error code make sure to at least log it as part of the error message. Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211024171251.22896-2-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-11-17iio: accel: kxcjk-1013: Fix possible memory leak in probe and removeYang Yingliang
When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: a25691c1f967 ("iio: accel: kxcjk1013: allow using an external trigger") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: <Stable@vger.kernel.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211025124159.2700301-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-20iio: accel: sca3000: Use sign_extend32() instead of opencoding sign extension.Jonathan Cameron
Whilst nice to get rid of this non obvious code, this also clears a static checker warning: drivers/iio/accel/sca3000.c:734 sca3000_read_raw() warn: no-op. '((*val) << 19) >> 19' Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211017160303.72441-1-jic23@kernel.org
2021-10-19Merge tag 'iio-for-5.16a-split-take4' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: First set of IIO new device and feature support for the 5.16 cycle Counter subsystem changes now sent separately. This has been a busy cycle, so lots here and a few more stragglers to come next week. Big new feature in this cycle is probably output buffer support. This has been in the works for a very long time so it's great to see Mihail pick up the challenge and build upon his predecessors work to finally bring this feature to mainline. New device support ------------------ * adi,adxl313 - New driver and dt bindings for this low power accelerometer. * adi,adxl355 - New driver and dt bindings for this accelerometer. - Later series adds buffer support. * asahi-kasei,ak8975 - Minor additions to driver to support ak09916 * aspeed,aspeed-adc - Substantial rework plus feature additions to add support for the ast2600 including a new dt bindings doc. * atmel,at91_sama5d2 - Rework and support introduced for the sama7g5 parts. * maxim,max31865 - New driver and bindings for this RTD temperature sensor chip. * nxp,imx8qxp - New driver and bindings for the ADC found on the i.MX 8QuadXPlus Soc. * senseair,sunrise - New driver and bindings for this family of carbon dioxide gas sensors. * sensiron,scd4x - New driver and bindings for this carbon dioxide gas sensor. New features ------------ * Output buffer support. Works in a similar fashion to input buffers, but in this case userspace pushes data into the kfifo which is then drained to the device when a trigger occurs. Support added to the ad5766 DAC driver. * Core, devm_iio_map_array_register() to avoid need for devm_add_action_or_reset() based cleanup in fully managed allocation drivers. * Core iio_push_to_buffers_with_ts_unaligned() function to safely handle a few drivers where it really hard to ensure the correct data alignment in an iio_push_to_buffers_with_timestamp() call. Note this uses a bounce buffer so should be avoided whenever possible. Used in the ti,adc108s102, invense,mpu3050 and adi,adis16400. This closes the last known set of drivers with alignment issues at this interface. * maxim,max1027 - Substantial rework to this driver main target of which was supporting use of other triggers than it's own EOC interrupt. - Transfer optimization. * nxp,fxls8962af - Threshold even support including using it as a wakeup source. Cleanups, minor fixes etc ------------------------- Chances of a common type to multiple drivers: * devm_ conversion and drop of .remove() callbacks in: - adi,ad5064 - adi,ad7291 - adi,ad7303 - adi,ad7746 - adi,ad9832 - adi,adis16080 - dialog,da9150-gpadc - intel,mrfld_adc - marvell,berlin2 - maxim,max1363 - maxim,max44000 - nuvoton,nau7802 - st_sensors (includes a lot of rework!) - ti,ads8344 - ti,lp8788 * devm_platform_ioremap_resource() used to reduce boilerplate - cirrus,ep93xx - rockchip,saradc - stm,stm32-dac * Use dev_err_probe() in more places to both not print on deferred probe and ensure a reason for the deferral is available for debug purposes. - adi,ad8801 - capella,cm36651 - linear,ltc1660 - maxim,ds4424 - maxim,max5821 - microchip,mcp4922 - nxp,lpc18xx - onnn,noa1305 - st,lsm9ds0 - st,st_sensors - st,stm32-dac - ti,afe4403 - ti,afe4404 - ti,dac7311 * Drop error returns in SPI and I2C remove() functions as they are ignored and long term plan is to change these all over to returning void. In some cases these patches just make it 'obvious' they always return 0 where it was the case before but not easy to tell. - adi,ad5380 - adi,ad5446 - adi,ad5686 - adi,ad5592r - bosch,bma400 - bosch,bmc150 - fsl,mma7455 - honeywell,hmc5843 - kionix,kxsd9 - maxim,max5487 - meas,ms5611 - ti,afe4403 Driver specific changes * adi,ad5770r - Bring driver inline with documented bindings. * adi,ad7746 - Trivial style fix * adi,ad7949 - Express some magic values as the underlying parts via new #defines. - Make it work with SPI controllers that don't support 14 or 16 bit messages - Support selection of voltage reference from dt including expanding the dt-bindings to cover this new functionality. * adi,ad799x - Implement selection of external reference voltage on AD7991, AD7995 and AD7999. - Add missing dt-bindings doc for devices supported by this driver. * adi,adislib - Move interrupt startup to better location in startup flow. - Handle devices that cannot mask/unmask the drdy pin and must instead mask at the interrupt controller. Applies to the adis16460 and adis16475 from which we then drop equivalent code. * adi,ltc2983 - Add support for optional reset pin. - Fail to probe if no channels specified in dt binding. * asahi-kasei,ak8975 - dt-binding additions of missing vid-supply regulator. * aspeed,aspeed-adc - Typo fix. * fsl,mma7660 - Mark acpi_device_id table __maybe_unused to avoid build warning. * fsl,imx25-gcq - Avoid initializing regulators that aren't used. * invensense,mpu3050 - Drop a dead protection against a clash with the old input driver. * invensense,mpu6050 - Rework code to not use strcpy() and hence avoid possibility of wrong sized buffers. Note this wasn't a bug, but the new code is a lot more readable. - Mark acpi_device_id table __maybe_unused to avoid build warning. * kionix,kxcjk1013 - dt-binding addition to note it supports interrupts. * marvell,berlin2-adc - Enable COMPILE_TEST building. * maxim,max1027 - Avoid returning success in an error path. * nxp,imx8qxp - Fix warning when runtime pm not enabled via __maybe_unused. * ricoh,rn5t618 - Use the new devm_iio_map_array_register() instead of open coding the same. * samsung,exynos_adc - Improve kconfig help text. * st,lsm6dsx - Move max_fifo_size into the fifo_ops structure where the other configuration parameters are found. * st,st_sensors: - Reorder to ensure we turn the power off after removing userspace interfaces. * senseair,sunrise - Add missing I2C dependency. * ti,twl6030 - Small code tidy up. * tag 'iio-for-5.16a-split-take4' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (148 commits) iio: imx8qxp-adc: mark PM functions as __maybe_unused iio: pressure: ms5611: Make ms5611_remove() return void iio: potentiometer: max5487: Don't return an error in .remove() iio: magn: hmc5843: Make hmc5843_common_remove() return void iio: health: afe4403: Don't return an error in .remove() iio: dac: ad5686: Make ad5686_remove() return void iio: dac: ad5592r: Make ad5592r_remove() return void iio: dac: ad5446: Make ad5446_remove() return void iio: dac: ad5380: Make ad5380_remove() return void iio: accel: mma7455: Make mma7455_core_remove() return void iio: accel: kxsd9: Make kxsd9_common_remove() return void iio: accel: bmi088: Make bmi088_accel_core_remove() return void iio: accel: bmc150: Make bmc150_accel_core_remove() return void iio: accel: bma400: Make bma400_remove() return void drivers:iio:dac:ad5766.c: Add trigger buffer iio: triggered-buffer: extend support to configure output buffers iio: kfifo-buffer: Add output buffer support iio: Add output buffer support iio: documentation: Document scd4x calibration use drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensor ...
2021-10-19iio: accel: mma7455: Make mma7455_core_remove() return voidUwe Kleine-König
Up to now mma7455_core_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-6-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: kxsd9: Make kxsd9_common_remove() return voidUwe Kleine-König
Up to now kxsd9_common_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-5-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: bmi088: Make bmi088_accel_core_remove() return voidUwe Kleine-König
Up to now bmi088_accel_core_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-4-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: bmc150: Make bmc150_accel_core_remove() return voidUwe Kleine-König
Up to now bmc150_accel_core_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-3-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: bma400: Make bma400_remove() return voidUwe Kleine-König
When an i2c or spi driver's remove function returns a non-zero error code nothing happens apart from emitting a generic error message. Make this error message more device specific and return zero instead in the remove callbacks. As the return value of bma400_remove() is unused then, change the function to not yield a return value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-2-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: triggered-buffer: extend support to configure output buffersAlexandru Ardelean
Now that output (kfifo) buffers are supported, we need to extend the {devm_}iio_triggered_buffer_setup_ext() parameter list to take a direction parameter. This allows us to attach an output triggered buffer to a DAC device. Unfortunately it's a bit difficult to add another macro to avoid changing 5 drivers where {devm_}iio_triggered_buffer_setup_ext() is used. Well, it's doable, but may not be worth the trouble vs just updating all these 5 drivers. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-4-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: fxls8962af: add wake on eventSean Nyekjaer
This adds ways for the SoC to wake from accelerometer wake events. In the suspend function we skip disabling the sensor if wakeup-source and events are activated. If buffered reads are enabled they will be deactivated before suspend. As the onboard buffer is only holding up to 32 12-bit X/Y/Z data triplets. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210920114221.1595543-2-sean@geanix.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-19iio: accel: fxls8962af: add threshold event handlingSean Nyekjaer
Add event channels that control the creation of motion events. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20210920114221.1595543-1-sean@geanix.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: accel: mma7660: Mark acpi match table as maybe unusedDaniel Palmer
When building kernels without ACPI support the table is declared but is not used because ACPI_PTR() turns it into a NULL. Add the __maybe_unused attribute to stop the compiler whining. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Link: https://lore.kernel.org/r/20210919072616.3849723-1-daniel@0x0f.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushedSean Nyekjaer
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: accel: adxl355: Add triggered buffer supportPuranjay Mohan
Provide a way for continuous data capture by setting up buffer support. The data ready signal exposed at the DRDY pin of the ADXL355 is exploited as a hardware interrupt which triggers to fill the buffer. Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Link: https://lore.kernel.org/r/20210903184312.21009-3-puranjay12@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: accel: adxl355: use if(ret) in place of ret < 0Puranjay Mohan
Replace if(ret < 0) with if(ret) for consistency. Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Link: https://lore.kernel.org/r/20210903184312.21009-2-puranjay12@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: accel: Add driver support for ADXL313Lucas Stankus
ADXL313 is a small, thin, low power, 3-axis accelerometer with high resolution measurement up to +/-4g. It includes an integrated 32-level FIFO and has activity and inactivity sensing capabilities. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL313.pdf Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/d16e2d1967e46bb2b1024b6d23bc4889da77dc6b.1630523106.git.lucas.p.stankus@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: st_sensors: remove reference to parent device object on st_sensor_dataAlexandru Ardelean
The idea behind it, is that all devm_ calls in ST sensors are bound to the parent device object. However, the reference to that object is kept on both the st_sensor_data struct and the IIO object parent (indio_dev->dev.parent). This change only adds a bit consistency and uses the reference stored on indio_dev->dev.parent, to enforce the assumption that all ST sensors' devm_ calls are bound to the same reference as the one store on st_sensor_data. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210823112204.243255-6-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: st_sensors: remove all driver remove functionsAlexandru Ardelean
At this point all ST driver remove functions do iio_device_unregister(). This change removes them from them and replaces all iio_device_register() with devm_iio_device_register(). This can be done in a single change relatively easy, since all these remove functions are define in st_sensors.h. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210823112204.243255-5-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: st_sensors: remove st_sensors_power_disable() functionAlexandru Ardelean
This change converts the st_sensors_power_enable() function to use devm_add_action_or_reset() handlers to register regulator_disable hooks for when the drivers get unloaded. The parent device of the IIO device object is used. This is based on the assumption that all other devm_ calls in the ST sensors use this reference. This makes the st_sensors_power_disable() un-needed. Removing this also changes unload order a bit, as all ST drivers would call st_sensors_power_disable() first and iio_device_unregister() after that. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210823112204.243255-4-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: st_sensors: remove st_sensors_deallocate_trigger() functionAlexandru Ardelean
This change converts the st_sensors_allocate_trigger() to use device-managed functions. The parent device of the IIO device object is used. This is based on the assumption that all other devm_ calls in the ST sensors use this reference. That makes the st_sensors_deallocate_trigger() function un-needed, so it can be removed. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210823112204.243255-3-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-09-14iio: st_sensors: disable regulators after device unregistrationAlexandru Ardelean
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>
2021-09-14iio: accel: Add driver support for ADXL355Puranjay Mohan
ADXL355 is a 3-axis MEMS Accelerometer. It offers low noise density, low 0g offset drift, low power with selectable measurement ranges. It also features programmable high-pass and low-pass filters. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/adxl354_adxl355.pdf Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Link: https://lore.kernel.org/r/20210811073027.124619-3-puranjay12@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-16Merge 5.14-rc6 into staging-nextGreg Kroah-Hartman
We need the IIO fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-08iio: accel: bmc150: Add support for BMC156Stephan Gerhold
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 Gerhold
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>
2021-07-24iio: accel: st_accel: use devm_iio_triggered_buffer_setup() for bufferAlexandru Ardelean
The st_accel_allocate_ring() function calls iio_triggered_buffer_setup() to allocate a triggered buffer. But the same can be done with devm_iio_triggered_buffer_setup() and then the st_accel_common_remove() no longer needs to manually deallocate it. We know that the parent of the IIO device is used to manage other instances of the devm unwind, so it can be used in the st_accel_allocate_ring() as well. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210720074642.223293-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-24iio: accel: fxls8962af: fix i2c dependencyArnd Bergmann
With CONFIG_SPI=y and CONFIG_I2C=m, building fxls8962af into vmlinux causes a link error against the I2C module: aarch64-linux-ld: drivers/iio/accel/fxls8962af-core.o: in function `fxls8962af_fifo_flush': fxls8962af-core.c:(.text+0x3a0): undefined reference to `i2c_verify_client' Work around it by adding a Kconfig dependency that forces the SPI driver to be a loadable module whenever I2C is a module. Fixes: af959b7b96b8 ("iio: accel: fxls8962af: fix errata bug E3 - I2C burst reads") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210721151330.2176653-1-arnd@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-24iio: st-sensors: Remove some unused includes and add some that should be thereJonathan Cameron
The st-sensors drivers have changed in structure over time, and includes have not always kept up with this. Let's bring them back to nearer the ideal. Identified with the include-what-you-use tool and careful checking of its suggestions. Note I haven't been particularly aggressive here, so this is just the cases where the include obviously isn't needed rather than the more subtle corners. Note I took the opportunity to add mod_devicetable.h as I generally prefer to see that when acpi or of match tables are present. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Denis Ciocca <denis.ciocca@st.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210608175149.4019289-1-jic23@kernel.org
2021-07-19iio: accel: adxl345: convert probe to device-managed functionsAlexandru Ardelean
This driver has two parts, one for i2c and one for spi, since the chip can operate with both wire protocols. The core file has a common adxl345_core_remove() function which puts the chip into a powerdown state. This can be implemented with a devm_add_action_or_reset() hook. Doing that means we can register the IIO device with devm_iio_device_register() and get rid of the adxl345_core_remove() function. The dev_set_drvdata() call can be removed as there is no other user of this private data anymore. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210624080441.8710-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: accel: bma220: make suspend state setting more robustAlexandru Ardelean
The datasheet mentions that the suspend mode is toggled by reading the suspend register. The reading returns value 0xFF if the system was in suspend mode, otherwise it returns value 0x00. The bma220_deinit() function does up to 2 reads, in case the device was in suspend mode, which suggests a level of paranoia that makes the logic in bma220_suspend() and bma220_resume() look insufficient. This change implements a bma220_power() function which does up to 2 reads of the suspend register to make sure that the chip enters a desired (suspended or normal) mode. If the transition fails, then -EBUSY is returned. Since only a reference to SPI device is required, we can remove the spi_set_drvdata() call and get the SPI device object from the base device object in the suspend/resume routines. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625140137.362282-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-19iio: accel: bma220: convert probe to device-managed functionsAlexandru Ardelean
This change converts the driver to use devm_iio_triggered_buffer_setup() and devm_iio_device_register() for initializing and registering the IIO device. The bma220_deinit() is converted into a callback for a devm_add_action_or_reset() hook, so that the device is put in stand-by when the driver gets uninitialized. The return value of the bma220_deinit() function isn't used as it does not add any value. On the error path of the probe function, this can just override the actual error with -EBUSY, or can even return 0 (no error), on the error path. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625140137.362282-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-17iio: accel: da280: convert probe to device-managed functionsAlexandru Ardelean
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210628141709.80534-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-17iio: accel: da311: convert probe to device-managed functionsAlexandru Ardelean
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210630120338.482426-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-17iio: accel: dmard10: convert probe to device-managed functionsAlexandru Ardelean
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210630121509.653717-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-13iio: accel: fxls8962af: fix potential use of uninitialized symbolSean Nyekjaer
Fix this warning from kernel test robot: smatch warnings: drivers/iio/accel/fxls8962af-core.c:640 fxls8962af_i2c_raw_read_errata3() error: uninitialized symbol 'ret'. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sean Nyekjaer <sean@geanix.com> Fixes: af959b7b96b8 ("iio: accel: fxls8962af: fix errata bug E3 - I2C burst reads") Link: https://lore.kernel.org/r/20210709071727.2453536-1-sean@geanix.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-07-13iio: hid-sensors: bind IIO channels alloc to device objectAlexandru Ardelean
Some HID drivers use devm_kmemdup() already to clone the template IIO channels information and update it. However, there are still some drivers that kmemdup() and kfree() the channels. This change converts them to use devm_kmemdup() and bind the life-time of this allocated object to the parent device object (in these drivers). Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210630123029.759609-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-16iio: accel: bmc150: Use more consistent and accurate scale valuesStephan Gerhold
It is quite strange that BMA222 and BMA222E have very close, yet subtly different values in their scale tables. Comparing the datasheets this is simply because the "Resolution" for the different measurement ranges are documented with different precision. For example, for +-2g the BMA222 datasheet [1] suggests a resolution of 15.6 mg/LSB, while the BMA222E datasheet [2] suggests 15.63 mg/LSB. Actually, there is no need to rely on the resolution given by the Bosch datasheets. The resolution and scale can be calculated more consistently and accurately using the range (e.g. +-2g) and the channel size (e.g. 8 bits). Distributing 4g (-2g to 2g) over 8 bits results in an exact resolution of (4g / 2^8) = 15.625 mg/LSB which is the same value as in both datasheets, just slightly more accurate. Multiplying g = 9.80665 m/s^2 we get a more accurate value for the IIO scale table. Generalizing this we can calculate the scale tables more accurately using (range / 2^bits) * g * 10^6 (because of IIO_VAL_INT_PLUS_MICRO). Document this and make the scale tables more consistent and accurate for all the variants using that formula. Now the scale tables for BMA222 and BMA222E are consistent and probably slightly more accurate. [1]: https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA222.pdf [2]: https://www.mouser.com/datasheet/2/783/BST-BMA222E-DS004-06-1021076.pdf Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Andy Shevchenko <andy.shevchenko@gnail.com> Link: https://lore.kernel.org/r/20210611182442.1971-1-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-16iio: hid-sensors: Update header includesJonathan Cameron
General driver churn doesn't always include updates of header includes. Manual review of the output of the include-what-you-use checker lead to the following cleanup. Hopefuly this brings things back to a good state for the hid-sensor drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210608205510.4033887-1-jic23@kernel.org
2021-06-16iio: hid-sensors: lighten exported symbols by moving to IIO_HID namespaceAndy Shevchenko
A namespace for exported symbols makes clear who is a provider and who is a consumer of the certain resources. Besides that, it doesn't pollute the common namespace. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210614162447.5392-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bma180/bmc150: Move BMA254 to bmc150-accel driverStephan Gerhold
Commit c1d1c4a62db5 ("iio: accel: bma180: BMA254 support") added BMA254 support to the bma180 driver and changed some naming to BMA25x to make it easier to add support for BMA253 and BMA255. Unfortunately, there is quite some overlap between the bma180 driver and the bmc150-accel driver. Back when the commit was made, the bmc150-accel driver actually already had support for BMA255, and adding support for BMA254 would have been as simple as adding a new compatible to bmc150-accel. The bmc150-accel driver is a bit better for BMA254 since it also supports the motion trigger/interrupt functionality. Fortunately, moving BMA254 support over to bmc150-accel is fairly simple because the drivers have compatible device tree bindings. Revert most of the changes for BMA254 support in bma180 and move BMA254 over to bmc150-accel. This has the following advantages: - Support for motion trigger/interrupt - Fix incorrect scale values (BMA254 currently uses the same as BMA250 but actually they're different because of 10 vs 12 bits data size) - Less code than before :) BMA250 could be potentially also moved but it's more complicated because its chip_id conflicts with the one for BMA222 in bmc150-accel. Perhaps there are also other register differences, I did not investigate further yet (and I have no way to test it). Cc: Peter Meerwald <pmeerw@pmeerw.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-11-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Add device IDs for BMA253Stephan Gerhold
BMA253 is mostly like BMA255 and has exactly the same register layout as used by the bmc150-accel driver as far I can tell. Making it work is as simple as adding new device IDs for it since it has the same chip_id = 0xFA (250) as BMA255 and others. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-8-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Sort all chip names alphabetically / by chip IDStephan Gerhold
Right now all the device IDs are listed in seemingly random order, make this consistent by ordering those alphabetically. Also, order bmc150_accel_chip_info_tbl by chip ID for the same reason. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-6-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Drop duplicated documentation of supported chipsStephan Gerhold
The chips supported by the bmc150-accel driver are clearly documented in Kconfig, in the bmc150_accel_chip_info_tbl as well as in all the device ID tables in the I2C/SPI drivers. It's easy to forget to update the lists in the file header. Drop those entirely to reduce the amount of changes required to add new chip variants. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-5-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Drop misleading/duplicate chip identifiersStephan Gerhold
Commit 0ad4bf370176 ("iio:accel:bmc150-accel: Use the chip ID to detect sensor variant") stopped using the I2C/ACPI match data to look up the bmc150_accel_chip_info. However, the bmc150_accel_chip_info_tbl remained as-is, with multiple entries with the same chip_id (e.g. 0xFA for BMC150/BMI055/BMA255). This is redundant now because actually the driver will always select the first entry with a matching chip_id. So even if a device probes e.g. with BMA0255 it will end up using the chip_info for BMC150. And in general that's fine for now, the entries for BMC150/BMI055/BMA255 were exactly the same anyway (except for the name, which is replaced with the more accurate one later). But in this case it's misleading because it suggests that one should add even more entries with the same chip_id when adding support for new variants. Let's make that more clear by removing the enum with the chip identifiers entirely and instead have only one entry per chip_id. Note that we may need to bring back some mechanism to differentiate between different chips with the same chip_id in the future. For example, BMA250 (currently supported by the bma180 driver) has the same chip_id = 0x03 as BMA222 even though they have different channel sizes (8 bits vs 10 bits). But in any case, that mechanism would need to look quite different from what we have right now. Cc: Bastien Nocera <hadess@hadess.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Clarify combo modules in KconfigStephan Gerhold
The Kconfig option currently says that all Bosch accelerometers supported by the bmc150-accel driver are combo chips with both accelerometer and magnetometer. This is wrong: actually only BMC150 is such a combo. The BMA* variants only contain an accelerometer and the BMI055 actually is a accelerometer + gyroscope combo. Clarify this in the help text and also make the list of supported variants complete and sorted for consistency. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-3-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Fix bma222 scale unitStephan Gerhold
According to sysfs-bus-iio documentation the unit for accelerometer values after applying scale/offset should be m/s^2, not g, which explains why the scale values for the other variants in bmc150-accel do not match exactly the values given in the datasheet. To get the correct values, we need to multiply the BMA222 scale values by g = 9.80665 m/s^2. Fixes: a1a210bf29a1 ("iio: accel: bmc150-accel: Add support for BMA222") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bma180: Fix BMA25x bandwidth register valuesStephan Gerhold
According to the BMA253 datasheet [1] and BMA250 datasheet [2] the bandwidth value for BMA25x should be set as 01xxx: "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] It is recommended [...] to use the range from ´01000b´ to ´01111b´ only in order to be compatible with future products." However, at the moment the drivers sets bandwidth values from 0 to 6, which is not recommended and always results into 7.81 Hz bandwidth according to the datasheet. Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, so the additional bit is always set for BMA25x. [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma253-ds000.pdf [2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf Cc: Peter Meerwald <pmeerw@pmeerw.net> Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Set label based on accel-location for ACPI DUAL250E fwnodesHans de Goede
Some Yoga laptops with 1 accelerometer in the display and 1 in the base, use an ACPI HID of DUAL250E instead of BOSC0200. Set the iio-device's label for DUAL250E devices to a value indicating which sensor is which, mirroring how we do this for BOSC0200 dual sensor devices. Note the DUAL250E fwnode unfortunately does not include a mount-matrix. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-10-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit (git 2.34.1) at 2024-05-26 21:36:44 +0000