iio: accel: mma8452: Balance runtime pm + use pm_runtime_resume_and_get()
Remove() callback calls pm_runtime_put_noidle() but there it is not
balancing a get. No actual affect because the runtime pm core prevents
the reference count going negative.
Whilst here use pm_runtime_resume_and_get() rather than open coded version.
Again, coccinelle script missed this one due to more complex code
structure.
iio: magn: bmc150: Balance runtime pm + use pm_runtime_resume_and_get()
probe() error paths after runtime pm is enabled, should disable it.
remove() should not call pm_runtime_put_noidle() as there is no
matching get() to have raised the reference count. This case
has no affect a the runtime pm core protects against going negative.
Whilst here use pm_runtime_resume_and_get() to tidy things up a little.
coccicheck script didn't get this one due to complex code structure so
found by inspection.
iio: proximity: srf04: Use pm_runtime_resume_and_get() and handle error
Previously this driver used pm_runtime_sync_get() and did not handle any
errors that occurred. Moving to the new pm_runtime_resume_and_get() +
handle errors.
iio: adc: rcar-gyroadc: Use pm_runtime_resume_and_get() and check in probe()
1 instance found using coccicheck script under review at:
https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/
The other instance changed did not check for failure of the
pm_runtime_get_sync() so that is added.
Note the remaining pm_runtime_get_sync() call is left alone because it
is not obvious what to do on failure to power up in remove()
This is a prequel to taking a closer look at the runtime pm in IIO drivers
in general.
iio: temp: mlx90614: Handle failure in pm_runtime_resume_and_get()
Converts from using pm_runtime_get_sync() with no error handling over
to pm_runtime_resume_and_get() which will ensure we don't end up
holding a reference. Ensure this error return is then handled at
calls to mlx90614_power_get(). These are all direct returns.
iio: imu: kmx61: Balance runtime pm + use pm_runtime_resume_and_get()
No point in calling pm_runtime_put_noidle() that isn't balancing a get.
Note no actual impact because the runtime pm core protects against
a negative reference counter.
For the pm_runtime_resume_and_get() main interest is in clearing
out this old pattern to avoid it getting coppied into new submissions.
iio: accel: kxcjk-1013: Balance runtime pm + use pm_runtime_resume_and_get()
This driver alls pm_runtime_put_noidle() in it's remove function, but there
is no matching get call. This isn't a bug as runtime pm will not allow
the reference counter to go negative, but it is missleading so lets remove
it.
Whilst here use pm_runtime_resume_and_get() to tidy up some boilerplate.
The coccicheck script didn't get this one due to the less obvious
structure. Found by inspection.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210509113354.660190-8-jic23@kernel.org
iio: accel: bmc150-accel: Balanced runtime pm + use pm_runtime_resume_and_get()
A call to pm_runtime_put_noidle() doesn't match any call that would
result in a get(). It is safe because runtime pm core protects against
the reference counter going 0, but it makes it harder to understand the
code.
Whilst here use pm_runtime_resume_and_get() to tidy things up.
The Coccinelle script didn't get this one due to more complex code
structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210509113354.660190-5-jic23@kernel.org
iio: light: tsl2583: Balance runtime pm + use pm_runtime_resume_and_get()
Error paths in read_raw() and write_raw() callbacks failed to perform and
type of runtime pm put(). Remove called pm_runtime_put_noidle()
but there is no equivalent get (this is safe because the reference
count is protected against going below zero, but it is misleading.
Whilst here use pm_runtime_resume_and_get() to replace boilerplate.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Brian Masney <masneyb@onstation.org> Reviewed-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210509113354.660190-4-jic23@kernel.org
iio: light: isl29028: Balance runtime pm + use pm_runtime_resume_and_get()
In remove this driver called pm_runtime_put_noidle() but there is
no matching get operation. This does not cause any problems because
the reference counter will not change if already zero, but it
does make the code harder to reason about so should be dropped.
Whilst we are here, use pm_runtime_resume_and_get() to replace open
coded version.
Found using coccicheck script under review at:
https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/
iio: gyro: fxa21002c: Balance runtime pm + use pm_runtime_resume_and_get().
In both the probe() error path and remove() pm_runtime_put_noidle()
is called which will decrement the runtime pm reference count.
However, there is no matching function to have raised the reference count.
Not this isn't a fix as the runtime pm core will stop the reference count
going negative anyway.
An alternative would have been to raise the count in these paths, but
it is not clear why that would be necessary.
Whilst we are here replace some boilerplate with pm_runtime_resume_and_get()
Found using coccicheck script under review at:
https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/
Stephan Gerhold [Tue, 11 May 2021 14:24:02 +0000 (16:24 +0200)]
iio: accel: kxcjk-1013: Add support for KX023-1025
The KX023-1025 accelerometer [1] seems to be some mixture of
KXCJK and KXTF9. It has the motion interrupt functionality from KXCJK
but also the tap detection from KXTF9, and a lot more functionality.
The configuration register map seems fairly different at first,
but actually all register bits used by the kxcjk-1013 driver are
available at the same bit positions on KX023-1025. It's just quite
misleading because:
1. The registers have entirely different names and are at different
addresses, but the bits are mostly named the same (and mean the same).
2. There are many more registers and bits used that are reserved on KXCJK
to enable additional functionality.
Ignoring all additionally available functionality for now, the KX023
works just fine after setting up the struct with the correct register
addresses. The only difference that needs to be handled additionally
is that the KX023 supports two configurable interrupt lines (INT1/2).
For now only INT1 is supported so we route all interrupts used by
the driver there.
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stephan Gerhold [Tue, 11 May 2021 14:24:01 +0000 (16:24 +0200)]
iio: accel: kxcjk-1013: Refactor configuration registers into struct
Most Kionix accelerometers seem to use fairly consistent register bits,
but the register addresses are not necessarily the same. This is already
partially the case for the KXTF9 (added in commit 1540d0106bcb
("iio: accel: kxcjk1013: add support for KXTF9")), which has some
registers at different addresses.
However, it's even much worse for the KX023-1025. All register bits
used by the kxcjk-1013 driver seem to be fully compatible with KX023,
but it has most registers at totally different addresses.
In preparation to add support for KX023-1025, move the fixed register
addresses into a struct so we can change them for KX023 more easily.
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The KX023-1025 accelerometer uses similar register bits as kxcjk1023,
so it can make use of the same driver. Document the new kionix,kx023-1025
compatible that is also supported by the kxcjk-1013 driver now.
Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Chunyan Zhang [Wed, 12 May 2021 09:38:44 +0000 (17:38 +0800)]
iio: adc: Add missing MODULE_DEVICE_TABLE
MODULE_DEVICE_TABLE is used to extract the device information out of the
driver and builds a table when being compiled. If using this macro,
kernel can find the driver if available when the device is plugged in,
and then loads that driver and initializes the device.
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The current-sense-shunt is an IIO provider thus can be referenced by IIO
consumers (via "io-channels" property in consumer device node).
Such provider is required to describe number of cells used in phandle
lookup with "io-channel-cells" property. This also fixes dtbs_check
warnings like:
arch/arm/boot/dts/s5pv210-fascinate4g.dt.yaml: current-sense-shunt:
'#io-channel-cells' does not match any of the regexes: 'pinctrl-[0-9]+'
Fixes: ce66e52b6c16 ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml conversion.") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Zhen Lei [Tue, 11 May 2021 11:39:12 +0000 (19:39 +0800)]
iio: ep93xx: Remove redundant error printing in ep93xx_adc_probe()
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
binary size.
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Thu, 6 May 2021 07:09:39 +0000 (09:09 +0200)]
iio: accel: fxls8962af: add hw buffered sampling
When buffered sampling is enabled, the accelerometer will dump data into
the internal fifo and interrupt at watermark. Then the driver flushes
all data to the iio buffer.
As the accelerometer doesn't have internal timestamps, they are
approximated between the current and last interrupt.
Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Thu, 6 May 2021 07:09:38 +0000 (09:09 +0200)]
iio: accel: fxls8962af: add interrupt support
Preparation commit for the next that adds hw buffered sampling.
Adds the interrupt function and reads the devicetree for which
interrupt pin that is used.
Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Thu, 6 May 2021 07:09:36 +0000 (09:09 +0200)]
dt-bindings: iio: accel: fxls8962af: add bindings
Add devicetree binding for the NXP FXLS8962AF/FXLS8964AF
accelerometer sensor.
Signed-off-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Fri, 7 May 2021 10:31:49 +0000 (12:31 +0200)]
iio: imu: st_lsm6dsx: correct ODR in header
Fix wrongly stated 13 Hz ODR for accelerometers, the correct ODR is 12.5 Hz
Signed-off-by: Sean Nyekjaer <sean@geanix.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Guenter Roeck [Thu, 6 May 2021 03:43:32 +0000 (20:43 -0700)]
iio: bme680_i2c: Remove acpi_device_id table
With CONFIG_ACPI=n and -Werror, 0-day reports:
drivers/iio/chemical/bme680_i2c.c:46:36: error:
'bme680_acpi_match' defined but not used
Apparently BME0680 is not a valid ACPI ID. Remove the ID.
Note the driver will still work with ACPI bindings that use the PRP0001
mechanism as that uses the of_device_id table instead.
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Guenter Roeck [Thu, 6 May 2021 13:31:45 +0000 (06:31 -0700)]
iio: bme680_spi: Remove acpi_device_id table
BME0680 is not an official ACPI ID, so let's remove it before someone
starts using it.
Note that ACPI can still be used with this driver via the PRP0001 method
which will use the of_device_id table to match.
Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Guenter Roeck [Thu, 6 May 2021 03:56:59 +0000 (20:56 -0700)]
iio:accel:stk8312: Remove acpi_device_id table
With CONFIG_ACPI=n, W=1 and -Werror, 0-day reports:
drivers/iio/accel/stk8312.c:644:36: error:
'stk8312_acpi_id' defined but not used
Apparently STK8312 is not a valid ACPI ID. Remove the ID table
as this is the only entry. If ACPI support is desired an explicit
of_device_id table should be added (rather than relying on the fallback
to the existing ID table).
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Wed, 14 Apr 2021 19:54:53 +0000 (22:54 +0300)]
iio: st_sensors: Add lsm9ds0 IMU support
We can utilize separate drivers for accelerometer and magnetometer,
so here is the glue driver to enable LSM9DS0 IMU support.
The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
was sent as RFC due to race condition concerns, which are indeed possible.
In order to amend the initial change, I went further by providing a specific
multi-instantiate probe driver that reuses existing accelerometer and
magnetometer.
Suggested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: mr.lahorde@laposte.net Cc: Matija Podravec <matija_podravec@fastmail.fm> Cc: Sergey Borishchenko <borischenko.sergey@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210414195454.84183-6-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Wed, 14 Apr 2021 19:54:51 +0000 (22:54 +0300)]
iio: st_sensors: Call st_sensors_power_enable() from bus drivers
In case we would initialize two IIO devices from one physical device,
we shouldn't have a clash on regulators. That's why move
st_sensors_power_enable() call from core to bus drivers.
Jonathan Cameron [Mon, 26 Apr 2021 17:49:05 +0000 (18:49 +0100)]
iio: core: move @driver_module from struct iio_dev to struct iio_dev_opaque
Continuing move to hide internal elements from drivers, move this structure
element over. It's only accessed from iio core files so this one was
straight forward and no accessor functions are needed.
Jonathan Cameron [Mon, 26 Apr 2021 17:49:04 +0000 (18:49 +0100)]
iio: avoid shadowing of variable name in to_iio_dev_opaque()
indio_dev was both the macro input parameter and the field name
in this macro. That causes trouble if the instance of
struct iio_dev passed in is not called indio_dev.
Whilst a fix of sorts, no need to backport as it seems we never
hit this previously due to some very consistent naming in IIO.
Jonathan Cameron [Mon, 26 Apr 2021 17:49:03 +0000 (18:49 +0100)]
iio: core: move @id from struct iio_dev to struct iio_dev_opaque
Continuing from Alexandru Ardelean's introduction of the split between
driver modifiable fields and those that should only be set by the core.
This could have been done in two steps to make the actual move after
introducing iio_device_id() but there seemed limited point to that
given how mechanical the majority of the patch is.
Includes fixup from Alex for missing mxs-lradc-adc conversion.
iio: adc: add ADC driver for the TI TSC2046 controller
Basically the TI TSC2046 touchscreen controller is 8 channel ADC optimized for
the touchscreen use case. By implementing it as an IIO ADC device, we can
make use of resistive-adc-touch and iio-hwmon drivers.
Polled readings are currently not implemented to keep this patch small, so
iio-hwmon will not work out of the box for now.
So far, this driver was tested with a custom version of resistive-adc-touch driver,
since it needs to be extended to make use of Z1 and Z2 channels. The X/Y
are working without additional changes.
dt-bindings:iio:adc: add generic settling-time-us and oversampling-ratio channel properties
Settling time and over sampling is a typical challenge for different IIO ADC
devices. So, introduce channel specific settling-time-us and oversampling-ratio
properties to cover this use case.
iio: Documentation: move incompatible ABI to obsolete
Commit 63cd35f34d2e ("iio: Documentation: update definitions for bufferY and scan_elements")
updated iio documentation in order to point to the newly
per-buffer API, as it is now possible to support multi buffers.
While the previous ABI will be kept forever, the best is
for applications to use the 5.11+ ABI. So, move the
legacy one ABI/obsolete.
This fixes an issue with scripts/get_abi.pl, that doesn't
accept two different Kernel version support for the same
API set.
dt-bindings: iio: chemical: sps30: update binding with serial example
sps30 has gained support for serial communication so add example to the
binding file. While at it remove reg property from list of required
properties because it's no-op in case of serial communication.
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sensor has support for both i2c and serial communication interfaces.
Both offer very similar set of features. Minor differences don't impact
overall functionality like doing measurements, etc.
Support for i2c have already been added, this patch adds support
for the latter ie. serial interface.
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: sps30: separate core and interface specific code
Move code responsible for handling i2c communication to a separate file.
Rationale for this change is preparation for adding support for serial
communication.
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 17 Jan 2021 15:38:16 +0000 (15:38 +0000)]
iio:ABI docs: Move specific description of out_altvoltageX_frequency to main docs.
The adf4371 has channels that are very closely coupled, so additional
documentation is needed to express these constraints.
Unfortunately having the same sysfs filename in multiple documentation
does not work well when generating automated documentation.
To avoid this issue, we add a new device specific description to the
main docs and remove the one in the device specific file.
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:0 ./Documentation/ABI/testing/sysfs-bus-iio:599
Jonathan Cameron [Sun, 17 Jan 2021 15:38:13 +0000 (15:38 +0000)]
iio:ABI docs: Fix issue around repeated definition of out_currentY_raw
This one is challenging as both the places this appears in specific drivers
are making 'unusual' uses of what looks like a simple output current
channel.
As a side note, this was particular bit of ABI occurs in other drivers
where the use is much more straight forward e.g. dac/ad5421
This patch attempts to make a best effort of adding it to the main docs but
retaining enough information. Both of these drivers probably need
specific documents being written to describe their unusual interfaces, but
those should be in the main documentation, not under Documentation/ABI.
That is a non trivial job so left for another time.
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als:43 ./Documentation/ABI/testing/sysfs-bus-iio-health-afe440x:38
Jonathan Cameron [Sun, 17 Jan 2021 15:38:12 +0000 (15:38 +0000)]
iio:ABI docs: Drop device specific docs for _powerdown for the adf4371
The interface is standard and the extra info provided on exactly what is
being powered down is not of interest to most users. Hence this doesn't
need it's own documentation and can rely on the docs in sysfs-bus-iio
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:36 ./Documentation/ABI/testing/sysfs-bus-iio:588
Jonathan Cameron [Sun, 17 Jan 2021 15:38:10 +0000 (15:38 +0000)]
iio:ABI docs: Fix up duplicate *_calibbias_* documentation for icm42600
This device has the unusual characteristic that the calibbias values
have well defined units (more commonly they are tweaks to a DAC)
Unfortunately the previous approach of having more specific documentation
in sysfs-bus-iio-icm42600 results in warnings during the documentation
build and random ordering in the resulting documentation.
To avoid this, add a note to the main documentation on this special
characteristic for the icm42600. The _available for calibbias was
missing from the main sysfs-bus-iio docs so also add that, allowing
us to drop the icm42600 specific file.
Fixes
$ scripts/get_abi.pl validate warning:
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:0 ./Documentation/ABI/testing/sysfs-bus-iio:394
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:1 ./Documentation/ABI/testing/sysfs-bus-iio:395
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:2 ./Documentation/ABI/testing/sysfs-bus-iio:396
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:3 ./Documentation/ABI/testing/sysfs-bus-iio:397
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:4 ./Documentation/ABI/testing/sysfs-bus-iio:398
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:5 ./Documentation/ABI/testing/sysfs-bus-iio:399
Nuno Sa [Tue, 27 Apr 2021 08:54:54 +0000 (10:54 +0200)]
iio: adis16400: do not directly change spi 'max_speed_hz'
With commit 3ba10e37371d ("iio: adis: add burst_max_speed_hz variable"), we
just need to define 'burst_max_speed_hz' and the adis core will take
care of setting up the spi transfers for burst mode. Hence, we fix
a potential race with the spi core where we could be left witn an
invalid 'max_speed_hz'.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Fixes: 5eda3550a3cc1 ("staging:iio:adis16400: Preallocate transfer message") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210427085454.30616-7-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sa [Tue, 27 Apr 2021 08:54:53 +0000 (10:54 +0200)]
iio: adis16475: do not directly change spi 'max_speed_hz'
With commit 3ba10e37371d ("iio: adis: add burst_max_speed_hz variable"), we
just need to define 'burst_max_speed_hz' and the adis core will take
care of setting up the spi transfers for burst mode. Hence, we fix
a potential race with the spi core where we could be left with an
invalid 'max_speed_hz'.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210427085454.30616-6-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sa [Tue, 27 Apr 2021 08:54:52 +0000 (10:54 +0200)]
iio: adis: add burst_max_speed_hz variable
Typically, in burst mode, the device cannot operate at it's full spi
speed. Hence, the spi transfers for burst mode have to take this into
account. With this change we avoid a potential race with the spi core as
drivers were 'hacking' the device 'max_speed_hz' directly in the
trigger handler.
Nuno Sa [Tue, 27 Apr 2021 08:54:50 +0000 (10:54 +0200)]
iio: adis_buffer: update device page after changing it
It makes more sense to update the device page as soon as we we
successfully changed it. Moreover, a follow up patch will handle
'spi_sync' error path which would leave 'current_page' in a inconsistent
state.
Nuno Sa [Tue, 27 Apr 2021 08:54:49 +0000 (10:54 +0200)]
iio: adis16475: do not return ints in irq handlers
On an IRQ handler we should not return normal error codes as 'irqreturn_t'
is expected.
This is done by jumping to the 'check_burst32' label where we return
'IRQ_HANDLED'. Note that it is fine to do the burst32 check in this
error path. If we have proper settings to apply burst32, we might just
do the setup now so that the next sample already uses it.
Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475") Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210427085454.30616-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tomas Melin [Mon, 26 Apr 2021 08:10:41 +0000 (11:10 +0300)]
iio: accel: Add driver for Murata SCA3300 accelerometer
Add initial support for Murata SCA3300 3-axis industrial
accelerometer with digital SPI interface. This device also
provides a temperature measurement.
Datasheet: https://www.murata.com/en-global/products/sensor/accel/sca3300 Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210426081041.59807-3-tomas.melin@vaisala.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 25 Apr 2021 16:31:53 +0000 (17:31 +0100)]
iio:adc:ad7476: Handle the different regulators used by various parts.
Not all of the parts supported by this driver use single supply.
Hence we add chip_info fields to say what additional supplies exist
and in the case of vref, ensure that is used for the reference voltage
rather than vcc.
One corner case is the ad7091r which has an internal reference that
can be over-driven by an external reference connected on the vref pin.
To handle that force_ext_vref is introduced and set if an optional
vref regulator is present.
Tested using really simple QEMU model and some fixed regulators.
The devm_add_action_or_reset() callback is changed to take the
regulator as it's parameter so we can use one callback for all the
different regulators without having to store pointers to them in
the iio_priv() structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20210425163154.73209-2-jic23@kernel.org
These are never upper case. Chances are that all users of this driver
were using the ACPI binding but just in case keep the uppercase version
but mark it deprecated.
The device has a tsens-busy pin, but it's both fiddly and currently
ignored by the Linux driver. Given it's not clear whether the binding
should be an interrupt, or a GPIO I have left that out for now.
Binding documentation for this driver was missing.
Note that the binding and some in tree dts files specifiy interrupts
etc but the driver is fairly simple and does not yet make use of them.
Listed both Joachim and myself as maintainers for this binding on basis
it's Joachim's driver but I don't want to volunteer Joachim too
strongly to look after this doc.
Yicong Yang [Thu, 8 Apr 2021 11:38:16 +0000 (19:38 +0800)]
iio: inkern: simplify some devm functions
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-8-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-7-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Yicong Yang [Thu, 8 Apr 2021 11:38:14 +0000 (19:38 +0800)]
iio: core: simplify some devm functions
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-6-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-5-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-4-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-3-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/1617881896-3164-2-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Joe Sandom [Wed, 21 Apr 2021 22:13:30 +0000 (23:13 +0100)]
dt-bindings: iio: light: Added AMS tsl2591 device tree binding
Device tree binding for AMS/TAOS tsl2591 ambient light sensor.
This driver supports configuration via device tree and sysfs.
Supported channels for raw infrared light intensity,
raw combined light intensity and illuminance in lux.
The driver additionally supports iio events on lower and
upper thresholds.
This is a very-high sensitivity light-to-digital converter that
transforms light intensity into a digital signal.
Signed-off-by: Joe Sandom <joe.g.sandom@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210421221330.17007-2-joe.g.sandom@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>