'struct iio_info' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
17366 1454 16 18836 4994 drivers/iio/proximity/aw96103.o
After:
=====
text data bss dec hex filename
17526 1294 16 18836 4994 drivers/iio/proximity/aw96103.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/da4918af46fef03903ab0e9fdcb4f23e014f3821.1733522812.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
All devices supported by this driver (currently veml6030, veml6035
and veml7700) have two 16-bit channels, and can profit for the same
configuration to support data access via triggered buffers.
The measurements are stored in two 16-bit consecutive registers
(addresses 0x04 and 0x05) as little endian, unsigned data.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://patch.msgid.link/20241124-veml6030_triggered_buffer-v3-1-565bb6b4b5c8@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add check for the return value of clk_enable() in order to catch the
potential exception.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Link: https://patch.msgid.link/20241123220149.30655-1-jiashengjiangcool@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
i.MX6SX only has 4 ADC channels, so limit channel numbers to 4 for
compatible string 'fsl,imx6sx-adc'.
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241126195256.2441622-2-Frank.Li@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use devm_* and dev_err_probe() simplify probe function and remove
vf610_adc_remove().
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241126195256.2441622-1-Frank.Li@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM KX134-1211 has very similar register interface as KX132-1211
does. The main differencies are the content of the "Who am I"
identification register and different g-ranges. The KX132-1211 can
measure ranges from +/- 2g to +/-16g where the KX134-1211 supports
measuring ranges +/- 8g to +/- 64g.
Support the ROHM KX134-1211.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/6e95af6b425df6a5ff5218825ec8923f1341f7c3.1732783834.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM KX134-1211 is very similar to KX132-1211. The main difference is
supported g-ranges. The KX132-1211 can measure ranges from +/- 2g to
+/-16g where the KX134-1211 supports measuring ranges +/- 8g to +/- 64g.
Support the ROHM KX134-1211.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/48b50cbda3d6c3a58a7b7c9ff23ed4dc7f418a5e.1732783834.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The register interface of the ROHM KX134ACR-LBZ accelerometer is
almost identical to the KX132ACR-LBZ. The main difference between these
accelerometers is that the KX134ACR-LBZ supports different G-ranges. The
driver can model this by informing different scale to users. Also, the
content of the "who_am_I" register is different.
Add an ID and scales for the KX134ACR-LBZ.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/27c43c595de1f3f698ace671922d4f5a48c3cd54.1732783834.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>From the software point of view, the KX134ACR-LBZ is almost identical to
the KX132ACR-LBZ. They, however, have different g ranges and ID register
values which makes them incompatible.
Add compatible and information for ROHM KX134ACR-LBZ accelerometer.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/2efe2bf7078704be3f020663960fef563ab21aca.1732783834.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The register interface of the ROHM KX134ACR-LBZ accelerometer is almost
identical to the KX132ACR-LBZ. Main difference between these
accelerometers is that the KX134ACR-LBZ supports G-ranges +/- 8, 16,
32 and 64G. All the other sensors supported by the kx022a driver can
measure +/- 2, 4, 8 and 16G.
Prepare supporting the KX134ACR-LBZ with different G-ranges by storing
a pointer to the scale tables in IC specific structure.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/fc667b1495adf4e3f29ecbb336495c1f18b47e61.1732783834.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
A few functions in KX022A need to use mutex for protecting the
enabling/disabling of the measurement while configurations are being
made. Some of the functions can be slightly simplified by using the
__cleanup based scoped mutexes, which allows dropping the goto based
unlocking at error path.
Simplify error paths using guard(mutex).
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/4785f841ad5f131356ba78b4f3c76f676d86a2e8.1732783834.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM BU27008 and BU27010 RGB sensors got cancelled. I was informed
they never reached mass production stage.
Keeping the bindings around is waste of maintenance resources. Drop the
bindings.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/3be66a8ec15fedd18ef13afae48ebb182196da13.1732819203.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM BU27008 and BU27010 RGB sensors got cancelled. I was informed
they never reached mass production stage.
Keeping the drivers around is waste of maintenance resources. Drop the
drivers.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/f4d0aa31f29f160a06cba4856a034fa5636d3372.1732819203.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for the Invensense IAM20380 sensor to the MPU6050 driver. It is
similar to the IAM20680. But IAM20380 only supports gyro and WHOAMI
register data is difference.
Signed-off-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Link: https://patch.msgid.link/20241115-iam20380-v2-2-d8d9dc6891f5@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add compatible string "invensense,iam20380" for the Invensense IAM20380
sensor. The IAM20380 is similar to the IAM20680, but only supports gyro.
Signed-off-by: Han Xu <han.xu@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241115-iam20380-v2-1-d8d9dc6891f5@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_dmaengine_buffer_setup_ext() function is public and should be
documented. Also, while touching this, fix the description of @dev in
related functions. @dev does not strictly have to be the parent of the
IIO device. It is only passed to dma_request_chan() so strictly
speaking, it can be any device that is a valid DMA channel consumer.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241115-dlech-mainline-spi-engine-offload-2-v5-9-bea815bd5ea5@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
According to the datasheet, the chip requires a reset before any data
can be read. This commit moves the device identification logic to
occur after the reset to ensure proper initialization.
Cc: Kevin Tsai <ktsai@capellamicro.com>
Signed-off-by: Cibil Pankiras <cibil.pankiras@aerq.com>
Link: https://patch.msgid.link/20241114091323.7415-1-cibil.pankiras@aerq.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Move the dt-bindings header file to the include/dt-bindings/iio/adc/
directory. ad4695 is an ADC driver, so it should be in the adc/
subdirectory for better organization. Previously, it was in the iio/
subdirectory.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241113-iio-adc-ad4695-move-dt-bindings-header-v1-1-aba1f0f9b628@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The BM1390 uses mutex for protecting the fifo read sequence. The clean-up
for a few of the functions can be slightly simplified by removing the
goto-based error handling/unlocking and by utilizing the guard(mutex)
scoped mutex handling instead.
Simplify driver by using the scoped mutexes.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://patch.msgid.link/a4c2f21189964132d245531b77fb0865562443a1.1732193263.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The BU27034 uses mutex for protecting the gain / time / scale changes.
The clean-up for a few of the functions can be slightly simplified by
removing the goto-based error handling/unlocking and by utilizing the
guard(mutex) scoped mutex handling instead.
Simplify driver by using the scoped mutexes.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://patch.msgid.link/4e65a4725c211b166906f70fdb5ba90f2af0f570.1732193263.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This patch implements ACPI support to Microchip pac1921.
The driver can read the shunt resistor value and label from the ACPI table.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matteo Martelli <matteomartelli3@gmail.com>
Signed-off-by: Victor Duicu <victor.duicu@microchip.com>
Link: https://patch.msgid.link/20241115133436.13204-1-victor.duicu@microchip.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Remove driver remove callback for the ltc2632 driver.
By making use of devm_iio_device_register(), we no longer need a driver
remove callback. Also since this was the last user of spi_get_drvdata(),
we can drop the call to spi_set_drvdata().
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241120-iio-regulator-cleanup-round-6-v1-9-d5a5360f7ec3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Simplify the code by using devm_regulator_get_enable_read_voltage().
Some use of dev_err() is replaced with dev_err_probe() to simplify
things even more since we are refactoring these lines anyway.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241120-iio-regulator-cleanup-round-6-v1-8-d5a5360f7ec3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Remove driver remove callback in the ad8801 driver.
By making use of devm_iio_device_register(), we no longer need a driver
remove callback. Also since this was the last user of spi_get_drvdata(),
we can drop the call to spi_set_drvdata().
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241120-iio-regulator-cleanup-round-6-v1-7-d5a5360f7ec3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Simplify the code by using devm_regulator_get_enable_read_voltage().
There is a small change in behavior. Before, all errors from
devm_regulator_get_optional() were ignored and assumed to mean that
the external reference supply was absent. Now, only -ENODEV is checked
and other errors will cause a failure to probe. So now, this will
catch errors, like using the wrong data type for the devicetree
property.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20241120-iio-regulator-cleanup-round-6-v1-3-d5a5360f7ec3@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
fxls8967af is similar with fxls8962af, the only difference is the device id
change to 0x87.
Signed-off-by: Han Xu <han.xu@nxp.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241115-fxls-v2-4-95f3df9228ed@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
fxls8974cf is similar with fxls8962af, the only difference is the device id
change to 0x86.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Clark Wang <xiaoning.wang@nxp.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241115-fxls-v2-3-95f3df9228ed@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add 'nxp,fxls8974cf' compatible for the FXLS8974CF sensor, falling back to
'nxp,fxls8962af' as the only difference is the ID.
Signed-off-by: Han Xu <han.xu@nxp.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20241115-fxls-v2-2-95f3df9228ed@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add 'nxp,fxls8967af' compatible for the FXLS8967AF sensor, falling back to
'nxp,fxls8962af' as the only difference is the ID.
Signed-off-by: Han Xu <han.xu@nxp.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20241115-fxls-v2-1-95f3df9228ed@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The use of of_property_read_bool() for non-boolean properties is
deprecated in favor of of_property_present() when testing for property
presence.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20241104190846.278417-1-robh@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
I3C client drivers should not include linux/i3c/master.h. Use
i3cdev_to_dev() to get the device pointer from struct i3c_device
to be able to avoid that include.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20241109145430.3702482-1-linux@roeck-us.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the adis16486, adis16487 and adis16489 Six Degrees
of Freedom Inertial Sensors to the list of compatible devices
of the adis16480 iio subsystem driver.
adis16486 is similar to adis16485, has the exact same channels
but acceleration and delta velocity scales are different.
adis16487 is fallback compatible with adis16485 and as a
consequence, dt-bindings list was updated to use oneOf.
adis16489 is similar to adis16488 but lacks the magnetometer
and has a different accelerometer scale.
Signed-off-by: Darius Berghe <darius.berghe@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20241108125814.3097213-4-darius.berghe@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add datasheet links for adis16486, adis16487 and adis16489
Six Degrees of Freedom Inertial Sensors into the existing
adis16480 driver documentation.
adis16486 is similar to adis16485, has the exact same channels
but acceleration and delta velocity scales are different.
adis16487 is fallback compatible with adis16485.
adis16489 is similar to adis16488 but lacks the magnetometer
and has a different accelerometer scale.
Signed-off-by: Darius Berghe <darius.berghe@analog.com>
Link: https://patch.msgid.link/20241108125814.3097213-3-darius.berghe@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for adis16486, adis16487 and adis16489 Six Degrees
of Freedom Inertial Sensors into the existing adis16480 iio
subsystem driver.
adis16486 is similar to adis16485, has the exact same channels
but acceleration and delta velocity scales are different.
adis16487 is fallback compatible with adis16485.
adis16489 is similar to adis16488 but lacks the magnetometer
and has a different accelerometer scale.
Signed-off-by: Darius Berghe <darius.berghe@analog.com>
Link: https://patch.msgid.link/20241108125814.3097213-2-darius.berghe@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The continual trickle of small conversion patches is grating on me, and
is really not helping. Just get rid of the 'remove_new' member
function, which is just an alias for the plain 'remove', and had a
comment to that effect:
/*
* .remove_new() is a relic from a prototype conversion of .remove().
* New drivers are supposed to implement .remove(). Once all drivers are
* converted to not use .remove_new any more, it will be dropped.
*/
This was just a tree-wide 'sed' script that replaced '.remove_new' with
'.remove', with some care taken to turn a subsequent tab into two tabs
to make things line up.
I did do some minimal manual whitespace adjustment for places that used
spaces to line things up.
Then I just removed the old (sic) .remove_new member function, and this
is the end result. No more unnecessary conversion noise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
