It's fine to call dev_err_probe() in ->probe() when error code is known.
Convert the driver to use dev_err_probe().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20220222090009.2060-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Clang warns:
drivers/iio/accel/adxl367.c:887:2: error: variable 'handled' is uninitialized when used here [-Werror,-Wuninitialized]
handled |= adxl367_push_event(indio_dev, status);
^~~~~~~
drivers/iio/accel/adxl367.c:879:14: note: initialize the variable 'handled' to silence this warning
bool handled;
^
= 0
1 error generated.
This should have used '=' instead of '|='; make that change to resolve
the warning.
Fixes: cbab791c5e ("iio: accel: add ADXL367 driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1605
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20220224211034.625130-1-nathan@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADXL367 is an ultralow power, 3-axis MEMS accelerometer.
The ADXL367 does not alias input signals to achieve ultralow power
consumption, it samples the full bandwidth of the sensor at all
data rates. Measurement ranges of +-2g, +-4g, and +-8g are available,
with a resolution of 0.25mg/LSB on the +-2 g range.
In addition to its ultralow power consumption, the ADXL367
has many features to enable true system level power reduction.
It includes a deep multimode output FIFO, a built-in micropower
temperature sensor, and an internal ADC for synchronous conversion
of an additional analog input.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220214073810.781016-6-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-40-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-39-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-10-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-9-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-8-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-7-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-6-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-5-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-4-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-3-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-2-jic23@kernel.org
In order to avoid unneessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-9-jic23@kernel.org
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Both the exports used between the two common modules and the individual
drivers are moved to a single namespace as greater granularity does
not feel useful.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-6-jic23@kernel.org
To avoid unnecessary pollution of the global symbol namespace move the
driver core and type specific core exports into their a new namespace
and import that where needed.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-14-jic23@kernel.org
The core module and type specific core modules are made up of
several files. There is no benefit in duplicating the MODULE_* macros
in each file so remove them.
Noticed whilst adding MODULE_IMPORT_NS() as I missed some files and
it still worked, making it clear not all of these blocks were needed.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220116180535.2367780-13-jic23@kernel.org
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Sean Nyekjaer <sean@geanix.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-12-jic23@kernel.org
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-10-jic23@kernel.org
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-7-jic23@kernel.org
In order to avoid unnecessary pollution of the global symbol namespace
move the driver core exports into their own namespace and import
that into the two bus modules.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lucas Stankus <lucas.p.stankus@gmail.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-6-jic23@kernel.org
In order to avoid unnecessary pollution of the global symbol namespace
move the core bma400 functions into a bma400 specific namespace
and import that into the two bus modules.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220116180535.2367780-5-jic23@kernel.org
In order to avoid unnecessary pollution of the global symbol namespace
move the core mma7455 functions into an mma7455 specific namespace and
import that into the two bus modules.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220116180535.2367780-3-jic23@kernel.org
The mma8452_driver declares both of_match_table and i2c_driver.id_table
match-tables, but its probe() function only checked for of matches.
Add support for i2c_device_id matches. This fixes the driver not loading
on some x86 tablets (e.g. the Nextbook Ares 8) where the i2c_client is
instantiated by platform code using an i2c_device_id.
Drop of_match_ptr() protection to avoid unused warning.
Fixes: c3cdd6e48e ("iio: mma8452: refactor for seperating chip specific data")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220208124336.511884-1-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The value returned by an spi driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Claudius Heine <ch@denx.de>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Acked-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Acked-by: Łukasz Stelmach <l.stelmach@samsung.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The pm_runtime_enable will increase power disable depth.
If the probe fails, we should use pm_runtime_disable() to balance
pm_runtime_enable(). In the PM Runtime docs:
Drivers in ->remove() callback should undo the runtime PM changes done
in ->probe(). Usually this means calling pm_runtime_disable(),
pm_runtime_dont_use_autosuspend() etc.
We should do this in error handling.
Fix this problem for the following drivers: bmc150, bmg160, kmx61,
kxcj-1013, mma9551, mma9553.
Fixes: 7d0ead5c3f ("iio: Reconcile operation order between iio_register/unregister and pm functions")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220106112309.16879-1-linmq006@gmail.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add missing don't care padding between address and
data for SPI transfers
Fixes: a3e0b51884 ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers")
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20211220125144.3630539-1-sean@geanix.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This patch makes I2C and SPI interface drivers for STMicroelectronics
sensor chips individually selectable via Kconfig.
The default is kept unchanged - I2C and SPI interface drivers are still
selected by default if the corresponding bus support is available.
However, the patch makes it possible to explicitly disable drivers
that are not needed for a particular target.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220110152432.3799227-1-nikita.yoush@cogentembedded.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Previously inconsistent with a space after { but not before }.
Tidy that up to avoid providing a bad example that might get
copied into other drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211230174911.78291-17-jic23@kernel.org
Includes some fixes that were either late breaking, low priority or
complex enough to not be good to rush in late in the cycle.
Tree rebased today to fix up some trivial issues + pull in a fix that
was previously on the fixes-togreg branch. Vast majority have been
in linux-next for some time now.
New device support
* adi,ad7293
- New driver and bindings for this Power Amplifier drain current
controller. A complex device with various related monitoring functions.
* adi,ad75513R
- New driver and bindings for this combined ADC and DAC device.
- A few follow up fixes.
* adi,admv8818
- New driver (and type) for this 2-18GHz filter device. Includes
bindings and ABI documentation to allow clk_notifier based auto
adjustment of the filters in appropriate applications.
* liteon,ltr501
- Support for the ltr303. ID and chip specific info table.
* xilinx,ams
- New generic firmware function fwnode_iomap() as used in this driver.
- New driver and bindings for this ADC and on-chip sensors as found
in various Xilinx devices.
Core
* Introduced IIO_VAL_INT_64 which uses val and val2 in IIO callbacks to
form a 64 bit integer when higher precision needed.
* Allow IIO_ENUM_AVAILABLE to be used with different shared values.
* Fix a long term issue with scheduling whilst atomic when iio_trig_poll()
is called but no trigger consumers are actually enabled and hence the
trigger may be reenabled from the interrupt handler. Seen in the wild
on the tsc2046.
* Mark iio_device_type const.
* buffer: Use a separate index variable to simplify code.
* buffer-dma: Clear out unused struct iio_buffer_block
* buffer-dmaengine: Switch to cheaper round_down() as power of 2 values.
Tests/tools
* format_value
- Check against NULL returns from allocations in tests.
- Add IIO_VAL_INT_64 test case.
* event_monitor
- Flush the output after event to given more consistent latency
when tool output piped to other programs.
Driver Features
* axp20x
- Add support for NTC thermistor channel and document TS pin binding.
* arm,scmi
- Add reading of raw channel values (using IIO_VAL_INT_64)
* liteon,ltr501
- Add proximity-near-level support and dt-binding.
Tree wide cleanup
* Remove no-op trigger ops from multiple drivers.
* Stop using dev_get_drvdata() on the iio_dev->dev in various drivers
and then stop assigning it to allow this to be used for other purposes.
We can always get to the indio_dev using dev_to_iio_dev() which is
a container_of() based approach. Also cleanup up some related unnecessary
convoluted cases.
- atmel,at91-sam5d2
- nxp,imx7d
- meas,ms5611
- st,st_sensors
* Where available (or easy to introduce) use the scan_type.* values
in place of a second copy for read_raw and similar paths.
- adi,ad7266
- bosch,bma220
- fsl,mac3110
- fsl,mma7455
- fsl,mpl3115
- kionix,kcjk-1013
- sensortek,stk8ba50
- sensortek,stk8312
- ti,adc12138
- ti,ads1015
- vti,sca3000
- xilinx,xadc-core
* Switch drives over to generic firmware properties including appropriate
header changes to avoid including of.h
- Various DACs had false CONFIG_OF dependencies.
- dpot-dac
- envelope-detector
- adi,ad5755
- adi,ad5758
- capella,cm3605
- maxim,max9611
- microchip,mcp41010
- microchip,mcp3911
- ti,adc12138
* Trivial clang warning fixes for W=1 warnings.
Driver specific cleanup and minor fixes
* adi,ad7606
- Comment fixes.
* ams,ad3935
- Drop pointless cast to the same type.
* atmel,at91-sama5d2
- Fix wrong cast of iio_dev->dev to platform_device that happened to
be harmless.
* fsl,mma7660
- Stop i2c remove() function returning an error code. Part of a rework
to eventually stop returning anything from these.
* fsl,mma8452
- Use correct type for local irqreturn_t.
* nxp,imx8mq
- Maintainer email address update.
* nxp,lpc18xx_adc
- Ensure clk_prepare_enable() called before clk_get_rate().
- Switch of.h for mod_devicetable.h to reflect no of specific functions,
just the id table.
* renesas,rzg2l
- Drop a dev_err() that just duplicates error printed in platform_get_irq()
* sgx,vz89x
- Drop pointless cast.
* st,lsm6dsx
- Make it possible to disable the sensorhub from DT to avoid a corner
case where the address of a slave device many be accidentally modified.
* st,stm32-adc
- Stop leaking an of_node in an error path.
* st,stmp2
- Avoid wrong sized type for bit field which could result in
over-reading (harmless). Precursor to enabling -Warray-bounds.
* ti,adc081c
- Put back some ACPI support for non standards compliant ADC081C
ID because it is known to be in the wild on some Aaeon boards.
* ti,ads8688
- Cleanup redundant local ret variable assignment.
* ti,ina2xx-adc
- Use helper macro kthread_run() to replace some boilerplate.
- Avoid double reference counting.
- Drop pointless cast.
* xilinx,xadc
- Make the IRQ optional as not always wired to the host system.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmHB8WsRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FoiiUg/8Dsg+oaZ126Wo+xW1FGk8LQ2GjCpIMHnt
pLW+O1ezBipqCL3pemQeV5b8GcAo5Tia/yplzZxxhbP3GMY9gMkMWqnCdY/81E69
w1SQF84OvMFdN+jHGAqu0mnyBkHEdT/nLyNMExBXSXMzXWzITY3bWbygMsKeN5Rs
/GWyiAgqA8PPi6DoMa9tiGiPGxejic7jEVHMLjXk4ytRLndNtD1IxUElD9yTFxhk
Hteba0hq+Et56nw/yOjz3mP4oSZSd//qPWQJ/qbMcHCvnr6LJ24sqhXiEQXyZ2vA
hjkoYRXQnzKdPcrYFcre4VY1nJdQ3v0GKCDEFPUHzRJh8iKJleQCH6dIGNNkiRld
KvBah2SetS43zQ11c4JywAUxENiWrUGIrF6u9xPCLq8Pe9b454r+Fb5BCwR7Ra+7
bit11aIazCQV98bFwQvwMzPL9L/SZI6cmsbizdjT2VMRBTPIWl4NhQRVoYQjb8v0
yZ6/S1560ibTxurTStkcGjjBC+mUzvVNuKir2mHaBdzCVAX82+babJcOhxzlI8jh
9adyfHsBL8HwOWBjxHgybjw87DDtuByiVuVy7h2jAVgQevPknVC1toj4Q2bNCbUj
tB2Ln6hBIaU29B1dj6GDwGvrCmi9XQzHOd0MSf524E/GlOKy4JEDQZU9bHFW5MKS
VcQSGTXSG7s=
=xXvq
-----END PGP SIGNATURE-----
Merge tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next
Jonathan writes:
1st set of IIO new device support, features and cleanup for 5.17
Includes some fixes that were either late breaking, low priority or
complex enough to not be good to rush in late in the cycle.
Tree rebased today to fix up some trivial issues + pull in a fix that
was previously on the fixes-togreg branch. Vast majority have been
in linux-next for some time now.
New device support
* adi,ad7293
- New driver and bindings for this Power Amplifier drain current
controller. A complex device with various related monitoring functions.
* adi,ad75513R
- New driver and bindings for this combined ADC and DAC device.
- A few follow up fixes.
* adi,admv8818
- New driver (and type) for this 2-18GHz filter device. Includes
bindings and ABI documentation to allow clk_notifier based auto
adjustment of the filters in appropriate applications.
* liteon,ltr501
- Support for the ltr303. ID and chip specific info table.
* xilinx,ams
- New generic firmware function fwnode_iomap() as used in this driver.
- New driver and bindings for this ADC and on-chip sensors as found
in various Xilinx devices.
Core
* Introduced IIO_VAL_INT_64 which uses val and val2 in IIO callbacks to
form a 64 bit integer when higher precision needed.
* Allow IIO_ENUM_AVAILABLE to be used with different shared values.
* Fix a long term issue with scheduling whilst atomic when iio_trig_poll()
is called but no trigger consumers are actually enabled and hence the
trigger may be reenabled from the interrupt handler. Seen in the wild
on the tsc2046.
* Mark iio_device_type const.
* buffer: Use a separate index variable to simplify code.
* buffer-dma: Clear out unused struct iio_buffer_block
* buffer-dmaengine: Switch to cheaper round_down() as power of 2 values.
Tests/tools
* format_value
- Check against NULL returns from allocations in tests.
- Add IIO_VAL_INT_64 test case.
* event_monitor
- Flush the output after event to given more consistent latency
when tool output piped to other programs.
Driver Features
* axp20x
- Add support for NTC thermistor channel and document TS pin binding.
* arm,scmi
- Add reading of raw channel values (using IIO_VAL_INT_64)
* liteon,ltr501
- Add proximity-near-level support and dt-binding.
Tree wide cleanup
* Remove no-op trigger ops from multiple drivers.
* Stop using dev_get_drvdata() on the iio_dev->dev in various drivers
and then stop assigning it to allow this to be used for other purposes.
We can always get to the indio_dev using dev_to_iio_dev() which is
a container_of() based approach. Also cleanup up some related unnecessary
convoluted cases.
- atmel,at91-sam5d2
- nxp,imx7d
- meas,ms5611
- st,st_sensors
* Where available (or easy to introduce) use the scan_type.* values
in place of a second copy for read_raw and similar paths.
- adi,ad7266
- bosch,bma220
- fsl,mac3110
- fsl,mma7455
- fsl,mpl3115
- kionix,kcjk-1013
- sensortek,stk8ba50
- sensortek,stk8312
- ti,adc12138
- ti,ads1015
- vti,sca3000
- xilinx,xadc-core
* Switch drives over to generic firmware properties including appropriate
header changes to avoid including of.h
- Various DACs had false CONFIG_OF dependencies.
- dpot-dac
- envelope-detector
- adi,ad5755
- adi,ad5758
- capella,cm3605
- maxim,max9611
- microchip,mcp41010
- microchip,mcp3911
- ti,adc12138
* Trivial clang warning fixes for W=1 warnings.
Driver specific cleanup and minor fixes
* adi,ad7606
- Comment fixes.
* ams,ad3935
- Drop pointless cast to the same type.
* atmel,at91-sama5d2
- Fix wrong cast of iio_dev->dev to platform_device that happened to
be harmless.
* fsl,mma7660
- Stop i2c remove() function returning an error code. Part of a rework
to eventually stop returning anything from these.
* fsl,mma8452
- Use correct type for local irqreturn_t.
* nxp,imx8mq
- Maintainer email address update.
* nxp,lpc18xx_adc
- Ensure clk_prepare_enable() called before clk_get_rate().
- Switch of.h for mod_devicetable.h to reflect no of specific functions,
just the id table.
* renesas,rzg2l
- Drop a dev_err() that just duplicates error printed in platform_get_irq()
* sgx,vz89x
- Drop pointless cast.
* st,lsm6dsx
- Make it possible to disable the sensorhub from DT to avoid a corner
case where the address of a slave device many be accidentally modified.
* st,stm32-adc
- Stop leaking an of_node in an error path.
* st,stmp2
- Avoid wrong sized type for bit field which could result in
over-reading (harmless). Precursor to enabling -Warray-bounds.
* ti,adc081c
- Put back some ACPI support for non standards compliant ADC081C
ID because it is known to be in the wild on some Aaeon boards.
* ti,ads8688
- Cleanup redundant local ret variable assignment.
* ti,ina2xx-adc
- Use helper macro kthread_run() to replace some boilerplate.
- Avoid double reference counting.
- Drop pointless cast.
* xilinx,xadc
- Make the IRQ optional as not always wired to the host system.
* tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (103 commits)
iio: adc: ti-adc081c: Partial revert of removal of ACPI IDs
iio:addac:ad74413r: Fix uninitialized ret in a path that won't be hit.
MAINTAINERS: Add maintainer for xilinx-ams
dt-bindings: iio: adc: Add Xilinx AMS binding documentation
iio: adc: Add Xilinx AMS driver
device property: Add fwnode_iomap()
iio:accel:kxcjk-1013: Mark struct __maybe_unused to avoid warning.
iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops.
iio:dummy: Drop set but unused variable len.
iio:magn:ak8975: Suppress clang W=1 warning about pointer to enum conversion.
iio:imu:inv_mpu6050: Suppress clang W=1 warning about pointer to enum conversion.
iio:imu:inv_icm42600: Suppress clang W=1 warning about pointer to enum conversion.
iio:dac:mcp4725: Suppress clang W=1 warning about pointer to enum conversion.
iio:amplifiers:hmc425a: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:ti-ads1015: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:rcar: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:ina2xx-adc: Suppress clang W=1 warning about pointer to enum conversion.
iio:accel:bma180: Suppress clang W=1 warning about pointer to enum conversion.
drivers:iio:dac: Add AD3552R driver support
dt-bindings: iio: dac: Add adi,ad3552r.yaml
...
This structure is only used in PM ops, so may not be used depending
on build configuration.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-13-jic23@kernel.org
If CONFIG_PM not set then clang warns this structure is unused.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211128172445.2616166-12-jic23@kernel.org
The shared parameter should be configurable based on its usage, and not
constrained to IIO_SHARED_BY_TYPE.
This patch aims to improve the flexibility in using the
IIO_ENUM_AVAILABLE define and avoid redefining custom iio enums that
expose the shared parameter.
An example is the ad5766.c driver where IIO_ENUM_AVAILABLE_SHARED was
defined in order to achieve `shared` parameter customization.
The current state of the IIO_ENUM_AVAILABLE implementation will imply
similar redefinitions each time a driver will require access to the
`shared` parameter. An example would be admv1013 driver which will
require custom device attribute for the frequency translation modes:
Quadrature I/Q mode and Intermediate Frequency mode.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211119085627.6348-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: ae6d9ce056 ("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>
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: 0427a106a9 ("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>
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: a25691c1f9 ("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>
Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-7-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-6-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-5-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-4-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-2-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The IRQ handler's return type is irqreturn_t. The mma8452 uses a variable
to store the return value, but the variable is of type int. Change this to
irqreturn_t. This makes it easier to verify that the code is correct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20211101102734.32291-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Whan an i2c 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.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211025195007.84541-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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>
