<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/iio, branch v7.1.6</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.1.6</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.1.6'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-24T14:21:24+00:00</updated>
<entry>
<title>iio: hid-sensor-rotation: Fix stale or zero output when reading raw values</title>
<updated>2026-07-24T14:21:24+00:00</updated>
<author>
<name>Zhang Lixu</name>
<email>lixu.zhang@intel.com</email>
</author>
<published>2026-07-13T17:53:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b80d602496863df573863165e8d6c92ce2f8279a'/>
<id>urn:sha1:b80d602496863df573863165e8d6c92ce2f8279a</id>
<content type='text'>
[ Upstream commit 3ce8d099e0afc5a7da75a2007a67f67c4f5a4af1 ]

When reading the raw quaternion attribute (in_rot_quaternion_raw), the
driver currently returns either all zeros (if the sensor was never enabled)
or stale data (if the sensor was previously enabled) because it reads from
the internal buffer without explicitly requesting a new sample from the
sensor.

To fix this, power up the sensor, call sensor_hub_input_attr_read_values()
to issue a synchronous GET_REPORT and receive the full quaternion data
directly into a local buffer, then decode the four components.

Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support")
Signed-off-by: Zhang Lixu &lt;lixu.zhang@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@intel.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1 case</title>
<updated>2026-07-24T14:20:40+00:00</updated>
<author>
<name>Ariana Lazar</name>
<email>ariana.lazar@microchip.com</email>
</author>
<published>2026-06-04T13:46:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6706e332151b7f3eba474691088c47af2a820089'/>
<id>urn:sha1:6706e332151b7f3eba474691088c47af2a820089</id>
<content type='text'>
[ Upstream commit e74c0d0eef7e1fa9fd387b81b2787b4581e0b11c ]

Ensure that if a device has Vref1 but reading the regulator returns an
error, mcp47feb02_init_ctrl_regs() is not called with an uninitialized
vref1_uV value. Also add a device_property_present() check for the Vref1
supply before reading the regulator.

Fixes: dd154646d292 ("iio: dac: mcp47feb02: Fix Vref validation [1-999] case")
Reported-by: Dan Carpenter &lt;error27@gmail.com&gt;
Closes: https://lore.kernel.org/all/adiPnla0M5EzvgD-@stanley.mountain/
Signed-off-by: Ariana Lazar &lt;ariana.lazar@microchip.com&gt;
Reviewed-by: David Lechner &lt;dlechner@baylibre.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: tcs3472: power down chip on probe failure</title>
<updated>2026-07-24T14:20:03+00:00</updated>
<author>
<name>Aldo Conte</name>
<email>aldocontelk@gmail.com</email>
</author>
<published>2026-05-22T12:34:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c00cabb19824fe108f83401117b356eaade97ec'/>
<id>urn:sha1:8c00cabb19824fe108f83401117b356eaade97ec</id>
<content type='text'>
[ Upstream commit b39f3bb9f5580d19bc0c10dea9224d75fed45f1d ]

If tcs3472_probe() fails after enabling the chip (by writing PON | AEN
to the ENABLE register), the error paths return without powering down
the device.

Add an 'error_powerdown' label at the end of the cleanup chain that
calls tcs3472_powerdown() to power down the chip. The existing label
cascade is rerouted to fall through to the new label.

Move tcs3472_powerdown() above tcs3472_probe() so the probe can call
it without a forward declaration.

Found by code inspection while reviewing the probe error paths in
preparation for the devm_ conversion.

Fixes: eb869ade30a6 ("iio: Add tcs3472 color light sensor driver")
Signed-off-by: Aldo Conte &lt;aldocontelk@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: accel: mma8452: handle I2C read error(s) in mma8452_read()</title>
<updated>2026-07-24T14:20:03+00:00</updated>
<author>
<name>Sanjay Chitroda</name>
<email>sanjayembeddedse@gmail.com</email>
</author>
<published>2026-05-05T17:46:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f3d413e701c5e54bef736b638967724dda880365'/>
<id>urn:sha1:f3d413e701c5e54bef736b638967724dda880365</id>
<content type='text'>
[ Upstream commit 5bdff291d20c31b365d9ddfe9c426fbfb41da5bb ]

Currently, If i2c_smbus_read_i2c_block_data() fails but
mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0.

As a result, the caller mma8452_read_raw() assumes the read was
successful and proceeds to use a buffer containing uninitialized
stack memory.

Add proper checking of the I2C read return value and propagate errors
to the caller.

Fixes: 96c0cb2bbfe0 ("iio: mma8452: add support for runtime power management")
Signed-off-by: Sanjay Chitroda &lt;sanjayembeddedse@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling</title>
<updated>2026-07-24T14:20:03+00:00</updated>
<author>
<name>Guilherme Ivo Bozi</name>
<email>guilherme.bozi@usp.br</email>
</author>
<published>2026-05-13T00:31:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c374d33f1338dbb5676919c5194caa9c5aa1631'/>
<id>urn:sha1:3c374d33f1338dbb5676919c5194caa9c5aa1631</id>
<content type='text'>
[ Upstream commit 947eb6f0a274f8b15a0248051a65b069effd5057 ]

ams_event_to_channel() may return a pointer past the end of
dev-&gt;channels when no matching scan_index is found. This can lead
to invalid memory access in ams_handle_event().

Add a bounds check in ams_event_to_channel() and return NULL when
no channel is found. Also guard the caller to safely handle this
case.

Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
Signed-off-by: Guilherme Ivo Bozi &lt;guilherme.bozi@usp.br&gt;
Reviewed-by: Salih Erim &lt;salih.erim@amd.com&gt;
Tested-by: Salih Erim &lt;salih.erim@amd.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: magnetometer: ak8975: fix potential kernel stack memory leak</title>
<updated>2026-07-24T14:20:03+00:00</updated>
<author>
<name>Joshua Crofts</name>
<email>joshua.crofts1@gmail.com</email>
</author>
<published>2026-05-15T10:28:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fb27ebf81136e796c7b719303ef6fd7e1ae5d488'/>
<id>urn:sha1:fb27ebf81136e796c7b719303ef6fd7e1ae5d488</id>
<content type='text'>
[ Upstream commit a9a00d727b7bbc5e913a919530a9dd468935bf95 ]

Currently in the AK8975 driver there are four instances where potential
uninitialized kernel stack memory leaks can occur. If
i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than
the size of the buffer, uninitialized bytes are retained in the buffer
and later the buffer is passed on to IIO buffers, potentially leaking
memory to userspace.

Fix this by adding checks whether the return value of the function is
equal to the size of the buffer and subsequently if the value is
lesser than zero to distinguish from a returned error code.

Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
Reported-by: Sashiko &lt;sashiko-bot@kernel.org&gt;
Closes: https://sashiko.dev/#/patchset/20260513-ak8975-fix-v1-1-104ea605dd54%40gmail.com
Signed-off-by: Joshua Crofts &lt;joshua.crofts1@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: light: si1133: prevent race condition on timeout</title>
<updated>2026-07-24T14:20:03+00:00</updated>
<author>
<name>Joshua Crofts</name>
<email>joshua.crofts1@gmail.com</email>
</author>
<published>2026-05-05T07:31:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7f167853ef3c04a1cf303bd743de303381ac1b60'/>
<id>urn:sha1:7f167853ef3c04a1cf303bd743de303381ac1b60</id>
<content type='text'>
[ Upstream commit 8c50a95ceb230d17801758a9e41ffbbbe46f8b4d ]

Sashiko reported a bug where the si1133_command exits on timeout
without halting the sensor or masking the interrupt. If the sensor
completes the command later, any subsequent command to the sensor
will cause the IRQ handler to complete immediately, returning stale
data to the driver all while the command hasn't finished yet, shifting
all potential reads in the future.

Fix this by masking the IRQ if wait_for_completion_timeout() fails.
When initiating a new command, do a dummy read of the IRQ_STATUS
register and turn the IRQ back on.

Fixes: e01e7eaf37d8 ("iio: light: introduce si1133")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://sashiko.dev/#/message/20260428-si1133-checkup-v2-5-70ad14bfefe2%40gmail.com
Assisted-by: gemini:gemini-3.1-pro-preview
Signed-off-by: Joshua Crofts &lt;joshua.crofts1@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: light: si1133: reset counter to prevent race condition</title>
<updated>2026-07-24T14:20:03+00:00</updated>
<author>
<name>Joshua Crofts</name>
<email>joshua.crofts1@gmail.com</email>
</author>
<published>2026-05-05T07:31:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2413ede67e398e2a3b953b8c7bb65f5ebfba631e'/>
<id>urn:sha1:2413ede67e398e2a3b953b8c7bb65f5ebfba631e</id>
<content type='text'>
[ Upstream commit 0a5f45ed2342aabae1e32c72558d15be28940a95 ]

Sashiko reported a potential race condition happening when the driver
returns an errno after a timeout in the si1133_command() function. The
premature exit causes the hardware and software counters to become out
of sync by not updating data-&gt;rsp_seq, therefore the internal hardware
counter keeps incrementing.

Fix this by adding a call to si1133_cmd_reset_counter() before returning
from timeout.

Fixes: e01e7eaf37d8 ("iio: light: introduce si1133")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://sashiko.dev/#/message/20260428-si1133-checkup-v2-5-70ad14bfefe2%40gmail.com
Assisted-by: gemini:gemini-3.1-pro-preview
Signed-off-by: Joshua Crofts &lt;joshua.crofts1@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: light: acpi-als: Check ACPI_COMPANION() against NULL</title>
<updated>2026-07-24T14:20:00+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2026-05-12T16:28:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=abdfdb8e6220ab9ec50822ba5f5416f2d674668a'/>
<id>urn:sha1:abdfdb8e6220ab9ec50822ba5f5416f2d674668a</id>
<content type='text'>
[ Upstream commit ff29241030eb6f4505d903d87c29f51c1866a95d ]

Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.

Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
acpi-als IIO driver.

Fixes: d4243cb08a27 ("iio: light: acpi-als: Convert ACPI driver to a platform one")
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: temperature: tmp006: use devm_iio_trigger_register</title>
<updated>2026-07-18T14:55:20+00:00</updated>
<author>
<name>Stepan Ionichev</name>
<email>sozdayvek@gmail.com</email>
</author>
<published>2026-05-17T18:26:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d90f868f56a16e10eedc6552f48d99dff4d275b7'/>
<id>urn:sha1:d90f868f56a16e10eedc6552f48d99dff4d275b7</id>
<content type='text'>
commit 3c5eed894efd93d68d7f6a359a81ddef0e928774 upstream.

tmp006_probe() allocates the DRDY trigger with devm_iio_trigger_alloc()
but registers it with plain iio_trigger_register(). The driver has no
.remove() callback, so on module unload the trigger stays in the global
trigger list while its memory is freed by devm, leaving a dangling
entry.

Switch to devm_iio_trigger_register() so the registration is undone in
the same devm scope as the allocation.

Fixes: 91f75ccf9f03 ("iio: temperature: tmp006: add triggered buffer support")
Cc: stable@vger.kernel.org
Signed-off-by: Stepan Ionichev &lt;sozdayvek@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
