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
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.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmFudVERHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0Foiepg//R5DRm1gMFGP/dl2P8u6KD2oXNmbqc3J0
+EPRTkyTyawQzc21wdxUh3oObgxmDS6P7Cr17z9viGse2PsUjza4Sptic3Zqi3Kv
FzeXZaP0GY9nC+hAyz+dSkMKNw19mkCYYEIWhDwYFpXMiOV8QlT+6pFgOiffofeR
GYMUoV2XeuxR6OH0zMOuYKTzjOCYC+VJTP4BfeUetpRZQyllgFOA+5KX4ZWTiJMV
eGCaq3Hhn6IQa7ATgYUBYJyMkAXQDrKDaMxiaCIuh/k3bgjAkfhkV48mu2cHTsX9
v0q21JkgmBenwNP/OQ6mxmWR9SFY4eB22Ptkd1foTPjAsqoST7qmqEBhhLrRb/fB
HkL0I7M4tWDqSTJKgdn+UHYrKFW9oBHIt5SK1tCS+zTYIn1wEmkY/w/9MuZllBFO
VKu5q2ypf/yGgCqPIZilK69mrZd7/72rE6tr3oefUF2iUVLdh9fI1TjGGyoT6GZ5
ZlEIfGHRpcRGHFiA4e+6tTx9VLr8m1B5YVvBWWPlruYe8ep7MmD3KjUcwINiRyNs
5rdBl2RI8VAUBbQ+60VWn03e/0kuRESpFC3Gf/ng+6hRSUbRFe4lZw60GbyFDXwV
m1odTlkXA7l6oRG9f5COhE/oNO7dsfMO74W6+yzhWICnxjgJFosaaZTLw8F9QJdS
m3z9tSU84js=
=htmG
-----END PGP SIGNATURE-----
Merge tag 'iio-for-5.16a-split-take4' of 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
...
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>
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>
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>
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>
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>
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>
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>
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>
fxls8962af_fifo_flush() will return the samples flushed.
So return IRQ_NONE only if an error is returned.
Fixes: 79e3a5bdd9 ("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>
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>
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>
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>
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>
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>
Up until commit ea7e586bdd ("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: 774487611c ("iio: pressure-core: st: Provide support for the Vdd power supply")
Fixes: ea7e586bdd ("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>
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 c06a6aba68
("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>
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>
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>
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: af959b7b96 ("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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
Commit c1d1c4a62d ("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>
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>
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>
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>
Commit 0ad4bf3701 ("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>
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>
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: a1a210bf29 ("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>
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: 2017cff24c ("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>
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>
Factor the BOSC0200 ACPI HID handling out into a new
bmc150_apply_bosc0200_acpi_orientation() function and make
bmc150_apply_acpi_orientation() call that when dealing with
a BOSC0200 ACPI device (and make it return false otherwise).
This is a preparation patch for adding special handling for other
ACPI HIDs (the "DUAL250E" HID).
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
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-9-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some 360 degree hinges (yoga) style 2-in-1 devices use 2 bmc150 accels
to allow the OS to determine the angle between the display and the base
of the device, so that the OS can determine if the 2-in-1 is in laptop
or in tablet-mode.
On Windows both accelerometers are read (polled) by a special service
and this service calls the DSM (Device Specific Method), which in turn
translates the angles to one of laptop/tablet/tent/stand mode and then
notifies the EC about the new mode and the EC then enables or disables
the builtin keyboard and touchpad based in the mode.
When the 2-in-1 is powered-on or resumed folded in tablet mode the
EC senses this independent of the DSM by using a HALL effect sensor
which senses that the keyboard has been folded away behind the display.
At power-on or resume the EC disables the keyboard based on this and
the only way to get the keyboard to work after this is to call the
DSM to re-enable it.
Call the DSM on probe() and resume() to fix the keyboard not working
when powered-on / resumed in tablet-mode.
This patch was developed and tested on a Lenovo Yoga 300-IBR.
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-8-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Now that the definition of the bmc150_accel_data struct is no longer
private to bmc150-accel-core.c, bmc150-accel-i2c.c can simply directly
access the second_dev member and the accessor functions are no longer
necessary.
Note if the i2c_acpi_new_device() for the second-client now fails,
an ERR_PTR gets stored in data->second_dev this is fine since it is only
ever passed to i2c_unregister_device() which has an IS_ERR_OR_NULL() check.
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-7-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
