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>
Akshay Bansod [Mon, 11 Aug 2025 16:56:40 +0000 (22:26 +0530)]
iio: st_lsm6dsx: Replace scnprintf() with sysfs_emit()
Update the sysfs interface for sampling frequency and scale attributes.
Replace `scnprintf()` with `sysfs_emit_at()` which is PAGE_SIZE-aware
and recommended for use in sysfs.
Haibo Chen [Tue, 12 Aug 2025 08:04:23 +0000 (16:04 +0800)]
iio: adc: imx93_adc: load calibrated values even calibration failed
ADC calibration might fail because of the noise on reference voltage.
To avoid calibration fail, need to meet the following requirement:
ADC reference voltage Noise < 1.8V * 1/2^ENOB
For the case which the ADC reference voltage on board do not meet
the requirement, still load the calibrated values, so ADC can also
work but maybe not that accurate.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Primoz Fiser <primoz.fiser@norik.com> Link: https://patch.msgid.link/20250812-adc-v2-2-0260833f13b8@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Haibo Chen [Tue, 12 Aug 2025 08:04:22 +0000 (16:04 +0800)]
iio: adc: imx93_adc: keep one style of the hex values
Use capital letters consistently for hex values.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250812-adc-v2-1-0260833f13b8@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ben Collins [Tue, 12 Aug 2025 11:12:58 +0000 (07:12 -0400)]
iio: iio_format_list() should set stride=1 for IIO_VAL_CHAR
iio_format_list() sets a stride across the val array of 1 for INT
type, and 2 for all others. Add IIO_VAL_CHAR so it also gets a
stride of 1 assuming val is an array of integers with char type
values.
No drivers currently use this, but I found this issue adding an
avail callback for IIO_INFO_THERMOCOUPLE_TYPE for a driver I'm
working on.
Xichao Zhao [Wed, 13 Aug 2025 07:55:56 +0000 (15:55 +0800)]
iio: adc: ti-tsc2046: use us_to_ktime() where appropriate
Given scan_interval_us and time_per_scan_us are both in usecs, it
makes more sense to use us_to_ktime() helper rather than converting
to nanosecs as needed for ns_to_ktime().
Andrew Davis [Wed, 13 Aug 2025 22:58:38 +0000 (17:58 -0500)]
iio: health: afe4404: Do not store dev pointer in device struct
The device *dev is only used in probe(), so no need to store it
in the device local data struct. In all the places in probe()
we did use that, just use a new local variable for the same.
Andrew Davis [Wed, 13 Aug 2025 22:58:35 +0000 (17:58 -0500)]
iio: health: afe4403: Do not store dev pointer in device struct
The device *dev is only used in probe(), so no need to store it
in the device local data struct. In all the places in probe()
we did use that, just use a new local variable for the same.
The ROHM BD79105 is a simple 16-bit ADC accessible via SPI*.
The BD79105 has a CONVSTART pin, which must be set high to start the ADC
conversion. Unlike with the ad7091 and ad7091r which also have a
CONVSTART pin, the BD79105 requires that the pin must remain high also
for the duration of the SPI access.
(*) Couple of words about the SPI. The BD79105 has pins named as
CONVSTART, SCLK, DIN and DOUT. For the curious reader, DIN is not SPI
ISO.
DIN is a signal which can be used as a chip-select. When DIN is pulled
low, the ADC will output the completed measurement via DOUT as SCLK is
clocked. According to the data-sheet, the DIN can also be used for
daisy-chaining multiple ADCs. Furthermore, DOUT can be used also for a
'data-ready' -IRQ. These modes aren't supported by this driver.
Support reading ADC scale and data from the BD79105 using SPI, when DIN
is used as a chip-select.
The ROHM BD79105 is a simple, 16-bit, 1-channel ADC with a 'CONVSTART'
pin used to start the ADC conversion. Other than the 'CONVSTART', there
are 3 supply pins (one used as a reference), analog inputs, ground and
communication pins. It's worth noting that the pin somewhat confusingly
labeled as 'DIN', is a pin which should be used as a chip-select. The IC
does not have any writable registers.
The device is designed so that the output pin can, in addition to
outputting the data, be used as a 'data-ready'-IRQ. There are cases
where the IRQ can't be used (because it is delivered via SPI data-line).
Hence, some systems may use a GPIO for polling the data readiness.
Add a compatible for the bd79105 and add the data-ready GPIO to the
binding.
Matti Vaittinen [Mon, 11 Aug 2025 08:51:50 +0000 (11:51 +0300)]
dt-bindings: iio: adc: ad7476: Drop redundant prop: true
The ad7476 supports a few variants with different power-supplies and
control GPIOs. The binding first unconditionally introduces all the
properties, and later sets them 'true' or 'false' based on the
combatible.
The 'true' seems to be implied by the initial property introduction so
the 'true' -branches in later conditional handling (based on the
compatible) can be omitted.
Matti Vaittinen [Mon, 11 Aug 2025 08:51:39 +0000 (11:51 +0300)]
iio: adc: ad7476: Conditionally call convstart
The ad7476 supports two IC variants which may have a 'convstart' -GPIO
for starting the conversion. Currently the driver calls a function which
tries to access the GPIO for all of the IC variants, whether they
support 'convstart' or not. This is not an error because this function
returns early if GPIO information is not populated.
We can do a tad better by calling this function only for the ICs which
have the 'convstart' by providing a function pointer to the convstart
function from the chip_info structure, and calling this function only
for the ICs which have the function pointer set.
This does also allow to support ICs which require different convstart
handling than the currently supported ICs.
Call convstart function only on the ICs which can support it and allow
IC-specific convstart functions for the ICs which require different
handling.
projects / thirdparty / kernel / stable.git / log
