kernel/linux.git/drivers/iio/inkern.c, branch linux-7.1.y

iio: Fix iio_multiply_value use in iio_read_channel_processed_scale

2026-04-28T15:36:09+00:00

The function iio_multiply_value returns IIO_VAL_INT (1) on success or a negative error number on failure, while iio_read_channel_processed_scale should return an error code or 0. This creates a situation where the expected result is treated as an error. Fix this by checking the iio_multiply_value result separately, instead of passing it as a return value. Fixes: 05f958d003c9 ("iio: Improve iio_read_channel_processed_scale() precision") Signed-off-by: Svyatoslav Ryhel Reviewed-by: Hans de Goede Cc: Signed-off-by: Jonathan Cameron

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

iio: Improve iio_read_channel_processed_scale() precision

2025-09-10T18:47:04+00:00

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. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250831104825.15097-5-hansg@kernel.org Signed-off-by: Jonathan Cameron

iio: consumers: Add an iio_multiply_value() helper function

2025-09-10T18:47:04+00:00

The channel-scale handling in iio_convert_raw_to_processed() in essence does the following: processed = raw * caller-provided-scale * channel-scale Which can also be written as: multiplier = raw * caller-provided-scale iio-value = channel-scale processed = multiplier * iio-value 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(). Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250831104825.15097-4-hansg@kernel.org Signed-off-by: Jonathan Cameron

iio: consumers: Fix offset handling in iio_convert_raw_to_processed()

2025-09-10T18:47:04+00:00

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 Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250831104825.15097-3-hansg@kernel.org Signed-off-by: Jonathan Cameron

iio: consumers: Fix handling of negative channel scale in iio_convert_raw_to_processed()

2025-09-10T18:47:04+00:00

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: *processed += div_s64(raw64 * (s64)scale_val2 * scale, 1000000LL); Things will break however for scale values < -1.0. Lets for example say that raw = 2, (caller-provided)scale = 10 and (channel)scale_val = -1.5. The result should then be 2 * 10 * -1.5 = -30. channel-scale = -1.5 means scale_val = -1 and scale_val2 = 500000, now lets see what gets stored in processed: 1. *processed = raw64 * scale_val * scale; 2. *processed += raw64 * scale_val2 * scale / 1000000LL; 1. Sets processed to 2 * -1 * 10 = -20 2. Adds 2 * 500000 * 10 / 1000000 = 10 to processed 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 Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250831104825.15097-2-hansg@kernel.org Signed-off-by: Jonathan Cameron

Merge 6.13-rc4 into char-misc-next

2025-01-13T05:17:49+00:00

We need the IIO fixes in here as well, and it resolves a merge conflict in: drivers/iio/adc/ti-ads1119.c Reported-by: Stephen Rothwell Signed-off-by: Greg Kroah-Hartman

iio: consumers: ensure read buffers for labels and ext_info are page aligned

2024-12-11T19:20:49+00:00

Attributes of iio providers are exposed via sysfs. Typically, providers pass attribute values to the iio core, which handles formatting and printing to sysfs. However, some attributes, such as labels or extended info, are directly formatted and printed to sysfs by provider drivers using sysfs_emit() and sysfs_emit_at(). These helpers assume the read buffer, allocated by sysfs fop, is page-aligned. When these attributes are accessed by consumer drivers, the read buffer is allocated by the consumer and may not be page-aligned, leading to failures in the provider's callback that utilizes sysfs_emit*. Add a check to ensure that read buffers for labels and external info attributes are page-aligned. Update the prototype documentation as well. Signed-off-by: Matteo Martelli Link: https://patch.msgid.link/20241202-iio-kmalloc-align-v1-1-aa9568c03937@gmail.com Signed-off-by: Jonathan Cameron

iio: inkern: call iio_device_put() only on mapped devices

2024-12-08T16:49:09+00:00

In the error path of iio_channel_get_all(), iio_device_put() is called on all IIO devices, which can cause a refcount imbalance. Fix this error by calling iio_device_put() only on IIO devices whose refcounts were previously incremented by iio_device_get(). Fixes: 314be14bb893 ("iio: Rename _st_ functions to loose the bit that meant the staging version.") Signed-off-by: Joe Hattori Link: https://patch.msgid.link/20241204111342.1246706-1-joe@pf.is.s.u-tokyo.ac.jp Cc: Signed-off-by: Jonathan Cameron