[ Upstream commit 38f67d0264929762e54ae5948703a21f841fe706 ]
Fix setting the odr value to update activity time based on frequency
derrived by recent odr, and not by obsolete odr value.
The [small] bug: When _adxl367_set_odr() is called with a new odr value,
it first writes the new odr value to the hardware register
ADXL367_REG_FILTER_CTL.
Second, it calls _adxl367_set_act_time_ms(), which calls
adxl367_time_ms_to_samples(). Here st->odr still holds the old odr value.
This st->odr member is used to derrive a frequency value, which is
applied to update ADXL367_REG_TIME_ACT. Hence, the idea is to update
activity time, based on possibilities and power consumption by the
current ODR rate.
Finally, when the function calls return, again in _adxl367_set_odr() the
new ODR is assigned to st->odr.
The fix: When setting a new ODR value is set to ADXL367_REG_FILTER_CTL,
also ADXL367_REG_TIME_ACT should probably be updated with a frequency
based on the recent ODR value and not the old one. Changing the location
of the assignment to st->odr fixes this.
Fixes: cbab791c5e ("iio: accel: add ADXL367 driver")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://patch.msgid.link/20250309193515.2974-1-l.rubusch@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 60a0cf2ebab92011055ab7db6553c0fc3c546938 ]
Reorder the claiming of direct mode and runtime pm calls to simplify
handling a little. For correct error handling, after the reorder
iio_device_release_direct_mode() must be claimed in an error occurs
in pm_runtime_resume_and_get()
Fixes: 1ca2cfbc0c ("iio: add MEMSensing MSA311 3-axis accelerometer driver")
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250217140135.896574-7-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit df330c808182a8beab5d0f84a6cbc9cff76c61fc ]
If a match was not found, then the write_raw() callback would return
the odr index, not an error. Return -EINVAL if this occurs.
To avoid similar issues in future, introduce j, a new indexing variable
rather than using ret for this purpose.
Fixes: 79de2ee469 ("iio: accel: mma8452: claim direct mode during write raw")
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250217140135.896574-2-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b7d2bc99b3bdc03fff9b416dd830632346d83530 upstream.
The KX022A provides the accelerometer data in two subsequent registers.
The registers are laid out so that the value obtained via bulk-read of
these registers can be interpreted as signed 16-bit little endian value.
The read value is converted to cpu_endianes and stored into 32bit integer.
The le16_to_cpu() casts value to unsigned 16-bit value, and when this is
assigned to 32-bit integer the resulting value will always be positive.
This has not been a problem to users (at least not all users) of the sysfs
interface, who know the data format based on the scan info and who have
converted the read value back to 16-bit signed value. This isn't
compliant with the ABI however.
This, however, will be a problem for those who use the in-kernel
interfaces, especially the iio_read_channel_processed_scale().
The iio_read_channel_processed_scale() performs multiplications to the
returned (always positive) raw value, which will cause strange results
when the data from the sensor has been negative.
Fix the read_raw format by casting the result of the le_to_cpu() to
signed 16-bit value before assigning it to the integer. This will make
the negative readings to be correctly reported as negative.
This fix will be visible to users by changing values returned via sysfs
to appear in correct (negative) format.
Reported-by: Kalle Niemi <kaleposti@gmail.com>
Fixes: 7c1d1677b3 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Tested-by: Kalle Niemi <kaleposti@gmail.com>
Cc: <Stable@vger.kernel.org>
Link: https://patch.msgid.link/ZyIxm_zamZfIGrnB@mva-rohm
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan writes:
IIO: 1st set of fixes for the 6.12 cycle.
Most of this pull request is the result of Javier Carrasco doing a
careful audit for missing Kconfig dependencies that luck has meant
the random builds have never hit. The rest is the usual mix of old
bugs that have surfaced and some fallout from the recent merge window.
adi,ad5686
- Fix binding duplication of compatible strings.
bosch,bma400
- Fix an uninitialized variable in the event tap handling.
bosch,bmi323
- Fix several issues in the register saving and restore on suspend/resume
sensiron,spd500
- Fix missing CRC8 dependency
ti,op3001
- Fix a missing full-scale range value (values above this point were
all reported wrongly)
vishay,veml6030
- Fix a segmentation fault due to some type confusion.
- Fix wrong ambient light sensor resolution.
* tag 'iio-fixes-for-6.12a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (34 commits)
iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig
iio: frequency: {admv4420,adrf6780}: format Kconfig entries
iio: adc: ad4695: Add missing Kconfig select
iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency()
iioc: dac: ltc2664: Fix span variable usage in ltc2664_channel_config()
iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig
iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig
iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig
iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig
iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig
iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig
iio: resolver: ad2s1210 add missing select REGMAP in Kconfig
iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
...
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
In the current implementation, the local variable field_value is used
without prior initialization, which may lead to reading uninitialized
memory. Specifically, in the macro set_mask_bits, the initial
(potentially uninitialized) value of the buffer is copied into old__,
and a mask is applied to calculate new__. A similar issue was resolved in
commit 6ee2a7058f ("iio: accel: bma400: Fix smatch warning based on use
of unintialized value.").
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 961db2da15 ("iio: accel: bma400: Add support for single and double tap events")
Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
Link: https://patch.msgid.link/20240910083624.27224-1-m.lobanov@rosalinux.ru
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADXL380/ADXL382 is a low noise density, low power, 3-axis
accelerometer with selectable measurement ranges. The ADXL380 supports
the +/-4 g, +/-8 g, and +/-16 g ranges, and the ADXL382 supports
+/-15 g, +/-30 g and +/-60 g ranges.
The ADXL380/ADXL382 offers industry leading noise, enabling precision
applications with minimal calibration. The low noise, and low power
ADXL380/ADXL382 enables accurate measurement in an environment with
high vibration, heart sounds and audio.
In addition to its low power consumption, the ADXL380/ADXL382 has many
features to enable true system level performance. These include a
built-in micropower temperature sensor, single / double / triple tap
detection and a state machine to prevent a false triggering. In
addition, the ADXL380/ADXL382 has provisions for external control of
the sampling time and/or an external clock.
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://patch.msgid.link/20240708104114.29894-2-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan writes:
IIO: 2nd set of new device support, features and cleanup for 6.11
The big one here is we finally have Paul Cercueil's (and others)
DMA buffer support for IIO devices enabling high speed zero
copy transfer of data to and from sensors supported by IIO (and for
example USB). This should aid with upstream support of a range of
higher performance ADCs and DACs.
Two merges from other trees
- spi/spi_devm_optimize used for simplification in ad7944.
- dmaengine/topic_dma_vec to enable the DMABUF series.
One feature with impact outside IIO.
- Richer set of dev_err_probe() like helpers to cover ERR_PTR() cases.
New device support
==================
adi,ad7173
- Add support for AD4111, AD4112, AD4114, AD4115 and ADC4116 pseudo
differential ADCs. Major driver rework was needed to enabled these.
adi,ad7944
- Use devm_spi_optimize_message() to avoid a local devm cleanup
callback. This is the example case from the patch set, others will
follow.
mediatek,mt6359-auxadc
- New driver for this ADC IP found in MT6357, MT6358 and MT6359 PMICs.
st,accel
- Add support for the LIS2DS12 accelerometer
ti,ads1119
- New driver for this 16 bit 2-differential or 4-single ended channel
ADC.
Features
========
dt-bindings
- Introduce new common-mode-channel property to help handle pseudo
differential ADCs where we have something that looks like one side
of differential input, but which is only suited for use with a
slow moving reference.
adi,adf4350
- Support use as a clock provider.
iio-hmwon
- Support reading of labels from IIO devices by their consumers and
use this in the hwmon bridge.
Cleanup and minor fixes
=======================
Treewide
- Use regmap_clear_bits() / regmap_set_bits() to simplify open coded
equivalents.
- Use devm_regulator_get_enable_read_voltage() to replace equivalent
opencoded boilerplate. In some cases enabled complete conversion to
devm handling and removal of explicit remove() callbacks.
- Introduce dev_err_ptr_probe() and other variants and make use of
of them in a couple of examples driver cleanups. Will find use in
many more drivers soon.
adi,ad7192
- Introduce local struct device *dev and use dev_err_probe() to give
more readable code.
adi,adi-axi-adc/dac
- Improved consistency of messages using dev_err_probe()
adi,adis
- Split the trigger handling into cases that needed paging and those that
don't resulting in more readable code.
- Use cleanup.h to simplify error paths via scoped cleanup.
- Add adis specific lock helpers and make use of them in a number of drivers.
adi,ad7192
- Update maintainer (Alisa-Dariana Roman)
adi,ad7606
- dt-binding cleanup.
avago,apds9306
- Add a maintainer entry (Subhajit Ghosh)
linear,ltc2309
- Fix a wrong endian type.
st,stm32-dfsdm
- Fix a missing port property in the dt-binding.
st,sensors
- Relax whoami match failure to a warning print rather than probe failure.
This enables fallback compatibles to existing parts from those that don't
necessarily even exit yet.
* tag 'iio-for-6.11b' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (112 commits)
iio: adc: ad7173: Fix uninitialized symbol is_current_chan
iio: adc: Add support for MediaTek MT6357/8/9 Auxiliary ADC
math.h: Add unsigned 8 bits fractional numbers type
dt-bindings: iio: adc: Add MediaTek MT6359 PMIC AUXADC
iio: common: scmi_iio: convert to dev_err_probe()
iio: backend: make use of dev_err_cast_probe()
iio: temperature: ltc2983: convert to dev_err_probe()
dev_printk: add new dev_err_probe() helpers
iio: xilinx-ams: Add labels
iio: adc: ad7944: use devm_spi_optimize_message()
Documentation: iio: Document high-speed DMABUF based API
iio: buffer-dmaengine: Support new DMABUF based userspace API
iio: buffer-dma: Enable support for DMABUFs
iio: core: Add new DMABUF interface infrastructure
MAINTAINERS: Update AD7192 driver maintainer
iio: adc: ad7192: use devm_regulator_get_enable_read_voltage
iio: st_sensors: relax WhoAmI check in st_sensors_verify_id()
MAINTAINERS: Add AVAGO APDS9306
dt-bindings: iio: adc: adi,ad7606: comment and sort the compatible names
dt-bindings: iio: adc: adi,ad7606: add missing datasheet link
...
Replace the duplicate ACPI "ROTM" data parsing code with the new
shared iio_read_acpi_mount_matrix() helper.
This also removes the limiting of the "ROTM" mount matrix to only ACPI
devices with an ACPI HID (Hardware-ID) of "KIOX000A". If kxcjk-1013 ACPI
devices with another HID have a ROTM method that should still be parsed
and if the method is not there then iio_read_acpi_mount_matrix() will
fail silently.
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240425125754.76010-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add a setup function implementation to the spi module to enable spi-3wire
when specified in the device-tree. If spi-3wire is not specified in the
device-tree, NULL is returned as bus pre-initialization. This behavior
is identical to the i2c initialization, hence the default initialization.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Link: https://lore.kernel.org/r/20240401194906.56810-9-l.rubusch@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>