David Lechner [Thu, 11 Sep 2025 21:42:03 +0000 (16:42 -0500)]
iio: adc: ad7124: support fractional sampling_frequency
Modify the attribute read/write functions for sampling_frequency and
filter_low_pass_3db_frequency to return fractional values.
These ADCs support output data rates in the single digits, so being
able to specify fractional values is necessary to use all possible
sampling frequencies.
Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Thu, 11 Sep 2025 21:42:02 +0000 (16:42 -0500)]
iio: adc: ad7124: use guard(mutex) to simplify return paths
Use guard(mutex) in a couple of functions to allow direct returns. This
simplifies the code a bit and will make later changes easier.
cleanup.h was already included for prior use of __free()
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Thu, 11 Sep 2025 21:42:01 +0000 (16:42 -0500)]
iio: adc: ad7124: use read_avail() for scale_available
Replace custom attribute with the standard IIO read_avail() callback
to provide in_voltage_scale_available attribute.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Thu, 11 Sep 2025 21:42:00 +0000 (16:42 -0500)]
iio: adc: ad7124: use clamp()
Use clamp() instead of open-coding clamping.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
David Lechner [Wed, 10 Sep 2025 17:33:29 +0000 (12:33 -0500)]
iio: adc: ad7124: fix sample rate for multi-channel use
Change how the FS[10:0] field of the FILTER register is calculated to
get consistent sample rates when only one channel is enabled vs when
multiple channels are enabled in a buffered read.
By default, the AD7124 allows larger sampling frequencies when only one
channel is enabled. It assumes that you will discard the first sample or
so to allow for settling time and then no additional settling time is
needed between samples because there is no multiplexing due to only one
channel being enabled. The conversion formula to convert between the
sampling frequency and the FS[10:0] field is:
fADC = fCLK / (FS[10:0] x 32)
which is what the driver has been using.
On the other hand, when multiple channels are enabled, there is
additional settling time needed when switching between channels so the
calculation to convert between becomes:
fADC = fCLK / (FS[10:0] x 32 x N)
where N depends on if SINGLE_CYCLE is set, the selected filter type and,
in some cases, the power mode.
The FILTER register has a SINGLE_CYCLE bit that can be set to force the
single channel case to use the same timing as the multi-channel case.
Before this change, the first formula was always used, so if all of the
in_voltageY_sampling_frequency attributes were set to 10 Hz, then doing
a buffered read with 1 channel enabled would result in the requested
sampling frequency of 10 Hz. But when more than one channel was
enabled, the actual sampling frequency would be 2.5 Hz per channel,
which is 1/4 of the requested frequency.
After this change, the SINGLE_CYCLE flag is now always enabled and the
multi-channel formula is now always used. This causes the sampling
frequency to be consistent regardless of the number of channels enabled.
For now, we are hard-coding N = 4 since the driver doesn't yet support
other filter types other than the default sinc4 filter.
The AD7124_FILTER_FS define is moved while we are touching this to
keep the bit fields in descending order to be consistent with the rest
of the file.
Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add documentation for ade9000 driver which describes the driver
device files and shows how the user may use the ABI for various
scenarios (configuration, measurement, etc.).
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add new IIO modifiers to support power and energy measurement devices:
Power modifiers:
- IIO_MOD_ACTIVE: Real power consumed by the load
- IIO_MOD_REACTIVE: Power that oscillates between source and load
- IIO_MOD_APPARENT: Magnitude of complex power
Signal quality modifiers:
- IIO_MOD_RMS: Root Mean Square value
Additionally adds:
- IIO_CHAN_INFO_POWERFACTOR: Power factor channel info type for
representing the ratio of active power to apparent power
These modifiers enable proper representation of power measurement
devices like energy meters and power analyzers.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for IIO_ALTCURRENT channel type to distinguish AC current
measurements from DC current measurements. This follows the same pattern
as IIO_VOLTAGE and IIO_ALTVOLTAGE.
Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Implement runtime power management for the LTR390 sensor. The device
autosuspends after 1s of idle time, reducing current consumption from
100 µA in active mode to 1 µA in standby mode as per the datasheet.
Ensure that interrupts continue to be delivered with runtime PM.
Since the LTR390 cannot be used as a wakeup source during runtime
suspend, therefore increment the runtime PM refcount when enabling
events and decrement it when disabling events or powering down.
This prevents event loss while still allowing power savings when IRQs
are unused.
Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Tue, 9 Sep 2025 07:11:11 +0000 (09:11 +0200)]
iio: imu: inv_icm42600: use guard() to release mutexes
Replace explicit mutex_lock() and mutex_unlock() with the guard() macro
for cleaner and safer mutex handling.
Signed-off-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The tmag5273 driver does not advertise IIO_CHAN_INFO_PROCESSED in its
info_mask_* fields, so the corresponding case in read_raw()/write_raw()
is never used.
Drop the dead code to reduce unnecessary branches and improve clarity.
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The als31300 driver does not advertise IIO_CHAN_INFO_PROCESSED in its
info_mask_* fields, so the corresponding case in read_raw() is never used.
Drop the dead code to reduce unnecessary branches and improve clarity.
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Mon, 1 Sep 2025 07:49:16 +0000 (09:49 +0200)]
iio: imu: inv_icm42600: Use devm_regulator_get_enable() for vdd regulator
The vdd regulator is not used for runtime power management, so it does
not need explicit enable/disable handling.
Use devm_regulator_get_enable() to let the regulator be managed
automatically by devm.
This simplifies the code by removing the manual enable and cleanup
logic.
Sean Nyekjaer [Mon, 1 Sep 2025 07:49:15 +0000 (09:49 +0200)]
iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended
Do as in suspend, skip resume configuration steps if the device is already
pm_runtime suspended. This avoids reconfiguring a device that is already
in the correct low-power state and ensures that pm_runtime handles the
power state transitions properly.
Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-3-ef1336246960@geanix.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Mon, 1 Sep 2025 07:49:14 +0000 (09:49 +0200)]
iio: imu: inv_icm42600: Drop redundant pm_runtime reinitialization in resume
Remove unnecessary calls to pm_runtime_disable(), pm_runtime_set_active(),
and pm_runtime_enable() from the resume path. These operations are not
required here and can interfere with proper pm_runtime state handling,
especially when resuming from a pm_runtime suspended state.
Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-2-ef1336246960@geanix.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sean Nyekjaer [Mon, 1 Sep 2025 07:49:13 +0000 (09:49 +0200)]
iio: imu: inv_icm42600: Simplify pm_runtime setup
Rework the power management in inv_icm42600_core_probe() to use
devm_pm_runtime_set_active_enabled(), which simplifies the runtime PM
setup by handling activation and enabling in one step.
Remove the separate inv_icm42600_disable_pm callback, as it's no longer
needed with the devm-managed approach.
Using devm_pm_runtime_enable() also fixes the missing disable of
autosuspend.
Update inv_icm42600_disable_vddio_reg() to only disable the regulator if
the device is not suspended i.e. powered-down, preventing unbalanced
disables.
Also remove redundant error msg on regulator_disable(), the regulator
framework already emits an error message when regulator_disable() fails.
This simplifies the PM setup and avoids manipulating the usage counter
unnecessarily.
Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-1-ef1336246960@geanix.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The current-sense-amplifier 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.
Dixit Parmar [Sat, 6 Sep 2025 08:37:57 +0000 (14:07 +0530)]
iio: magnetometer: add support for Infineon TLV493D 3D Magentic sensor
The Infineon TLV493D is a Low-Power 3D Magnetic Sensor. The Sensor
applications includes joysticks, control elements (white goods,
multifunction knops), or electric meters (anti tampering) and any
other application that requires accurate angular measurements at
low power consumptions.
The Sensor is configured over I2C, and as part of Sensor measurement
data it provides 3-Axis magnetic fields and temperature core measurement.
The driver supports raw value read and buffered input via external trigger
to allow streaming values with the same sensing timestamp.
While the sensor has an interrupt pin multiplexed with an I2C SCL pin.
But for bus configurations interrupt(INT) is not recommended, unless timing
constraints between I2C data transfers and interrupt pulses are monitored
and aligned.
The Sensor's I2C register map and mode information is described in product
User Manual [1].
Dixit Parmar [Sat, 6 Sep 2025 08:37:56 +0000 (14:07 +0530)]
dt-bindings: iio: magnetometer: Infineon TLV493D 3D Magnetic sensor
Document the bindings for Infineon TLV493D Low-Power 3D Magnetic Sensor
controlled by I2C interface. Main applications includes joysticks, control
elements (white goods, multifunction knops), or electric meters (anti-
tampering).
Drop duplicate entry for infineon,tlv493d from trivial-devices.yaml as
its documented in this separate dt-binding file now.
Datasheet: https://www.infineon.com/assets/row/public/documents/24/49/infineon-tlv493d-a1b6-datasheet-en.pdf Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250906-tlv493d-sensor-v6_16-rc5-v6-1-b1a62d968353@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Sun, 31 Aug 2025 10:48:25 +0000 (12:48 +0200)]
iio: adc: Add Intel Dollar Cove TI PMIC ADC driver
Intel has 2 completely different "Dollar Cove" PMICs for its Bay Trail /
Cherry Trail SoCs. One is made by X-Powers and is called the AXP288.
The AXP288's GPADC is already supported by the X-Powers AXP288 ADC driver.
The other "Dollar Cove" PMIC is made by TI and does not have any clear TI
denomination, its MFD driver calls it the "Intel Dollar Cove TI PMIC".
Add a driver for the Intel Dollar Cove TI PMIC's general purpose ADC,
binding to the "chtdc_ti_adc" MFD cell of the MFD driver.
The "cht" in the cell name comes from Cherry Trail, but it turns out that
just like the AXP288 the Intel Dollar Cove TI PMIC is also used with both
Intel Bay Trail and Intel Cherry Trail SoCs, so this new ADC driver does
not include the cht part in its name.
This is loosely based on kernel/drivers/iio/adc/iio_dc_ti_gpadc.c
from the Acer A1-840 Android kernel source-code archive named:
"App. Guide_Acer_20151221_A_A.zip"
which is distributed by Acer from the Acer A1-840 support page:
https://www.acer.com/us-en/support/product-support/A1-840/downloads
Before this change iio_read_channel_processed_scale() always assumes that
channels which advertise IIO_CHAN_INFO_PROCESSED capability return
IIO_VAL_INT on success.
Ignoring any fractional values from drivers which return
IIO_VAL_INT_PLUS_MICRO / IIO_VAL_INT_PLUS_NANO. These fractional values
might become non fractional after scaling so these should be taken into
account for better precision.
Use the new iio_multiply_value() helper to do proper scaling taking
the fractionional values into account.
Where iio-value is a set of IIO_VAL_* type + val + val2 integers, being
able to handle multiplication of iio-values like this is something
which is useful to have in general and, as previous bugfixes to
iio_convert_raw_to_processed() have shown, also tricky to implement.
Split the iio-value multiplication code from iio_convert_raw_to_processed()
out into a new iio_multiply_value() helper. This serves multiple purposes:
1. Having this split out allows writing a KUnit test for this.
2. Having this split out allows re-use to get better precision
when scaling values in iio_read_channel_processed_scale().
Hans de Goede [Sun, 31 Aug 2025 10:48:21 +0000 (12:48 +0200)]
iio: consumers: Fix offset handling in iio_convert_raw_to_processed()
Fix iio_convert_raw_to_processed() offset handling for channels without
a scale attribute.
The offset has been applied to the raw64 value not to the original raw
value. Use the raw64 value so that the offset is taken into account.
Fixes: 14b457fdde38 ("iio: inkern: apply consumer scale when no channel scale is available") Cc: Liam Beguin <liambeguin@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://patch.msgid.link/20250831104825.15097-3-hansg@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Sun, 31 Aug 2025 10:48:20 +0000 (12:48 +0200)]
iio: consumers: Fix handling of negative channel scale in iio_convert_raw_to_processed()
There is an issue with the handling of negative channel scales
in iio_convert_raw_to_processed_unlocked() when the channel-scale
is of the IIO_VAL_INT_PLUS_[MICRO|NANO] type:
Things work for channel-scale values > -1.0 and < 0.0 because of
the use of signed values in:
And the end result is processed = -20 + 10 = -10, which is not correct.
Fix this by always using the abs value of both scale_val and scale_val2
and if either is negative multiply the end-result by -1.
Note there seems to be an unwritten rule about negative
IIO_VAL_INT_PLUS_[MICRO|NANO] values that:
i. values > -1.0 and < 0.0 are written as val=0 val2=-xxx
ii. values <= -1.0 are written as val=-xxx val2=xxx
But iio_format_value() will also correctly display a third option:
iii. values <= -1.0 written as val=-xxx val2=-xxx
Since iio_format_value() uses abs(val) when val2 < 0.
This fix also makes iio_convert_raw_to_processed() properly handle
channel-scales using this third option.
Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value") Cc: Matteo Martelli <matteomartelli3@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://patch.msgid.link/20250831104825.15097-2-hansg@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
dt-bindings: iio: adc: samsung,exynos: Drop touchscreen support
With last user of touchscreen via ADC (S3C24xx SoC) gone, drop the
unused has-touchscreen property and optional touchscreen interrupt for
samsung,s3c6410-adc. The samsung,s5pv210-adc is the only platform
having two interrupts, so add a constrain for that.
dt-bindings: iio: adc: samsung,exynos: Drop S3C2410
Samsung S3C24xx family of SoCs was removed the Linux kernel in the
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support"), in January
2023. There are no in-kernel users of remaining S3C24xx compatibles.
Samsung S3C24xx family of SoCs was removed from the Linux kernel in the
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support"), in January
2023. There are no in-kernel users of its compatibles.
Ioana Risteiu [Mon, 25 Aug 2025 22:13:49 +0000 (01:13 +0300)]
iio: adc: adi-axi-adc: add axi_adc_num_lanes_set
Assign num_lanes_set in the adi_axi_adc_ops to axi_adc_num_lanes_set()
to support setting number of lanes used by AXI ADC. This operation is
included in the generic structure because the number of lanes is a
configurable parameter of the generic AXI ADC IP core, not specific to
a device.
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-redundant explicit call to
pm_runtime_mark_last_busy().
Also clean up error handling in stm32_dac_set_enable_state().
David Lechner [Thu, 28 Aug 2025 21:54:55 +0000 (16:54 -0500)]
iio: adc: ad7124: add clock output support
Add support for the AD7124's internal clock output. If the #clock-cells
property is present, turn on the internal clock output during probe.
If both the clocks and #clock-names properties are present (not allowed
by devicetree bindings), assume that an external clock is being used so
that we don't accidentally have two outputs fighting each other.
David Lechner [Thu, 28 Aug 2025 21:54:54 +0000 (16:54 -0500)]
iio: adc: ad7124: add external clock support
Add support for an external clock source to the AD7124 ADC driver.
Previously, the driver only supported using the internal clock and had
bad devicetree bindings that used a fake clock to essentially select
the power mode. This is preserved for backwards compatibility.
If the clock is not named "mclk", then we know that the devicetree is
using the correct bindings and we can configure the chip to use an
external clock source rather than internal.
Also drop a redundant comment when configuring the register fields
instead of adding more.
David Lechner [Thu, 28 Aug 2025 21:54:53 +0000 (16:54 -0500)]
iio: adc: ad7124: do not require mclk
Make the "mclk" clock optional in the ad7124 driver. The MCLK is an
internal counter on the ADC, so it is not something that should be
coming from the devicetree. However, existing users may be using this
to essentially select the power mode of the ADC from the devicetree.
In order to not break those users, we have to keep the existing "mclk"
handling, but now it is optional.
Now, when the "mclk" clock is omitted from the devicetree, the driver
will default to the full power mode. Support for an external clock
and dynamic power mode switching can be added later if needed.
Use correct clocks properties for the AD7124 family of ADCs.
These ADCs have an internal clock along with an optional external clock
that can be connected to the CLK pin. This pin can be wired up 3 ways:
1. Not connected - the internal clock is used.
2. Connected to an external clock (input) - the external clock is used.
3. Connected to the CLK pin on another ADC (output) - the internal clock
is used on one and the other is configured for an external clock.
The new bindings describe these 3 cases by picking one of the following:
1. Omit both clocks and #clock-cells properties.
2. Include only the clocks property with a phandle to the external clock.
3. Include only the #clock-cells property on the ADC providing the output.
The clock-names property is now deprecated and should not be used. The
MCLK signal that it refers to is an internal counter in the ADC and
therefore does not make sense as a devicetree property as it can't be
connected to anything external to the ADC. Since there is only one
possible external clock, the clock-names property is not needed anyway.
Based on the implementation of the Linux driver, it looks like the
"mclk" clock was basically being used as a control to select the power
mode of the ADC, which is not something that should be done in the
devicetree.
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Also drop checking for errors on pm_runtime_put_autosuspend() in
bmc150_magn_set_power_state().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://patch.msgid.link/20250825135401.1765847-7-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Jonathan Santos [Sun, 24 Aug 2025 04:10:03 +0000 (01:10 -0300)]
iio: adc: ad7768-1: use devm_regulator_get_enable_read_voltage()
Use devm_regulator_get_enable_read_voltage() function as a standard and
concise way of reading the voltage from the regulator and keep the
regulator enabled. Replace the regulator descriptor with the direct
voltage value in the device struct.
Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> Link: https://patch.msgid.link/20250824041003.9727-1-Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Junjie Cao [Wed, 20 Aug 2025 00:47:55 +0000 (08:47 +0800)]
iio: core: switch info_mask fields to unsigned long to match find_bit helpers
for_each_set_bit()/find_*_bit() expect arrays of unsigned long (see
include/linux/find.h), but industrialio-core passed const long * into
iio_device_add_info_mask_type{,_avail}().
These masks are used purely as bit arrays and are populated via BIT()
(1UL << n). Switch the info_mask_* fields and the corresponding function
parameters to unsigned long so the types match the helpers. This removes
sparse warnings about signedness mismatches (seen with 'make C=1'
CF='-Wsparse-all') without changing behavior or struct layout.
No functional change intended.
Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250820004755.69627-1-junjie.cao@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add #io-channel-cells property with a constant value of 1 because it is
multi-channel ADC.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/ls/ls1021a-iot.dtb: adc@35 (maxim,max1239): '#io-channel-cells' does not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/iio/adc/maxim,max1238.yaml#
iio: imu: bmi270: Match PNP ID found on newer GPD firmware
GPD devices originally used BMI160 sensors with the "BMI0160" PNP ID.
When they switched to BMI260 sensors in newer hardware, they reused
the existing Windows driver which accepts both "BMI0160" and "BMI0260"
IDs. Consequently, they kept "BMI0160" in DSDT tables for new BMI260
devices, causing driver mismatches in Linux.
1. GPD updated BIOS v0.40+[1] for newer devices to report "BMI0260" for
BMI260 sensors to avoid loading the bmi160 driver on Linux. While this
isn't Bosch's VID;
2. Bosch's official Windows driver uses "BMI0260" as a compatible ID
3. We're seeing real devices shipping with "BMI0260" in DSDT
The DSDT excerpt of GPD G1619-04 with BIOS v0.40:
Scope (_SB.I2CC)
{
Device (BMA2)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "BMI0260") // _HID: Hardware ID
Name (_CID, "BMI0260") // _CID: Compatible ID
Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2CC",
0x00, ResourceConsumer, , Exclusive,
)
})
Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */
}
# omit some noise
}
}
Qianfeng Rong [Tue, 19 Aug 2025 12:50:17 +0000 (20:50 +0800)]
iio: common: scmi_iio: use kcalloc() instead of kzalloc()
Replace calls of devm_kzalloc() with devm_kcalloc() in scmi_alloc_iiodev()
and scmi_iio_set_sampling_freq_avail() for safer memory allocation with
built-in overflow protection.
Similarly, use array_size() instead of explicit multiplication for
'sensor->sensor_info->intervals.count * 2'.
Ben Collins [Fri, 22 Aug 2025 13:23:52 +0000 (09:23 -0400)]
iio: mcp9600: White space and fixed width cleanup
Make tabs consistent for register definitions and also fix width
to byte size.
Signed-off-by: Ben Collins <bcollins@watter.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <abdy@kernel.org> Reviewed-by: David Lechner <dlechner@baylibrc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20250822-upstream-changes-v8-3-40bb1739e3e2@watter.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ben Collins [Fri, 22 Aug 2025 13:23:51 +0000 (09:23 -0400)]
dt-bindings: iio: mcp9600: Add microchip,mcp9601 and add constraints
Add microchip,mcp9601 compatible in addition to the original
microchip,mcp9600 to designate support between these two chips.
The current dt-binding has open-circuit and short-circuit as interrupt
names, but these are only supported in mcp9601.
The OC and SC detection requires that mcp9601 VSENSE be wired up, which
not only enables the OC SC interrupts, but also the OC and SC status
register bits.
Add a microchip,vsense boolean to show the chip is wired for this
support.
Add constraints so this feature only applies if the mcp9601 compatible
is selected.
Xichao Zhao [Thu, 21 Aug 2025 08:06:51 +0000 (16:06 +0800)]
iio: temperature: mlx90635: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Xichao Zhao [Thu, 21 Aug 2025 08:06:50 +0000 (16:06 +0800)]
iio: proximity: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Xichao Zhao [Thu, 21 Aug 2025 08:06:49 +0000 (16:06 +0800)]
iio: light: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Xichao Zhao [Thu, 21 Aug 2025 08:06:48 +0000 (16:06 +0800)]
iio: imu: bmi323: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Xichao Zhao [Thu, 21 Aug 2025 08:06:47 +0000 (16:06 +0800)]
iio: chemical: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Gustavo Silva <gustavograzs@gmail.com> # for ens160 Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-4-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Xichao Zhao [Thu, 21 Aug 2025 08:06:46 +0000 (16:06 +0800)]
iio: adc: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # meson_saradc Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-3-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Xichao Zhao [Thu, 21 Aug 2025 08:06:45 +0000 (16:06 +0800)]
iio: accel: msa311: Remove dev_err_probe() if error is -ENOMEM
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Salah Triki [Tue, 19 Aug 2025 15:00:53 +0000 (16:00 +0100)]
staging: iio: adc: ad7816: Drop unnecessary dev_set_drvdata() call
Remove the call to `dev_set_drvdata()` and the associated comment
since private data is never read.
Signed-off-by: Salah Triki <salah.triki@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/aKSRpTuwA0P-ZaUS@pc Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Dan Carpenter [Tue, 19 Aug 2025 15:02:53 +0000 (18:02 +0300)]
iio: proximity: vl53l0x-i2c: Fix error code in probe()
Commit 65e8202f0322 ("iio: Remove error prints for
devm_add_action_or_reset()") accidentally introduced a bug where we
returned "ret" but the error code was stored in "error" if
devm_add_action_or_reset() failed. Using two variables to store error
codes is unnecessary and confusing. Delete the "error" variable and use
"ret" everywhere instead.
Fixes: 65e8202f0322 ("iio: Remove error prints for devm_add_action_or_reset()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/aKSSHTdJf5QoYiRx@stanley.mountain Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Matti Vaittinen [Mon, 18 Aug 2025 08:13:05 +0000 (11:13 +0300)]
iio: adc: adc128s052: Support ROHM BD7910[0,1,2,3]
The ROHM BD79100, BD79101, BD79102, BD79103 are very similar ADCs as the
ROHM BD79104. The BD79100 has only 1 channel. BD79101 has 2 channels and
the BD79102 has 4 channels. Both BD79103 and BD79104 have 4 channels,
and, based on the data sheets, they seem identical from the software
point-of-view.
Matti Vaittinen [Mon, 18 Aug 2025 08:12:52 +0000 (11:12 +0300)]
iio: adc: adc128s052: Rename channel structs
The adc128s052 can be used to drive a few other ADCs but the TI's ADCs
it was originally intended for. The TI's IC variants model numbers don't
(trivially) explain the channel configuration (for a reader working with
other than TI's ICs).
Rename the channel configuration structures to explicitly explain they
are used for simple ADCs, having 2, 4 or 8 channels.
Matti Vaittinen [Mon, 18 Aug 2025 08:12:39 +0000 (11:12 +0300)]
iio: adc: adc128s052: Simplify matching chip_data
The adc128s052 driver supports a few different ICs. IC specific
configuration data is stored in an array. IC data, residing in a
specific point of the array, is pointed from the SPI device match data.
There is no need to have the chip config data structures in an array
and splitting them out of an array has at least following benefits:
- Chip-specific structures can be named after the chips they support.
This makes referring them a tad cleaner, compared to using a generic
array name with a numerical index.
- Avoid all potential 'out of bounds' errors which can result if the
array is changed.
Split the chip configuration data array to individual structures.
Matti Vaittinen [Mon, 18 Aug 2025 08:12:22 +0000 (11:12 +0300)]
dt-bindings: iio: adc: Add BD7910[0,1,2,3]
The ROHM BD79100, BD79101, BD79102, BD79103 are very similar ADCs as the
ROHM BD79104. The BD79100 has only 1 channel. BD79101 has 2 channels and
the BD79102 has 4 channels. Both BD79103 and BD79104 have 4 channels,
and, based on the data sheets, they seem identical from the software
point-of-view.
The clamp macro returns a value within the specified range.
In ad7768_set_freq(), the value returned from clamp() is checked against
zero, which is not possible since the value would always be between
50 and 1024000.
Removed the 'if' check.
This issue was reported by static coverity analyser as logically
dead code.
iio: light: Simple conversions to iio_push_to_buffers_with_ts()
This new function allows for runtime checks on the provided source buffer
being of sufficient size to accommodate the enabled channel data layout and
the naturally aligned s64 timestamp (which is non obvious and a frequent
source of bugs in the past).
This patch includes the remaining simple cases for light sensor drivers.
Cc: Mudit Sharma <muditsharma.info@gmail.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Javier Carrasco <javier.carrasco.cruz@gmail.com> Cc: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250802164436.515988-17-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
projects / thirdparty / linux.git / log
