linux-stable.git/drivers/iio/temperature, branch linux-6.6.y Linux kernel stable tree iio: temperature: tsys01: fix broken PROM checksum validation 2026-06-19T11:39:17+00:00 Salah Triki salah.triki@gmail.com 2026-05-05T07:10:24+00:00 c43741113cd6e5e856a10ec0a80f048702117cfc commit 4701e471c16866e7aa8f5e6a3a6b0d31e097e2c9 upstream. The current implementation of tsys01_crc_valid() incorrectly sums the first word (n_prom[0]) repeatedly instead of iterating over the 8 words retrieved from the PROM. This leads to a checksum mismatch and probe failure on hardware. According to the TSYS01 datasheet, the PROM consists of 8 words. A valid check must iterate through all 8 words to verify the integrity of the calibration data. The current driver only checks the first word 8 times. Note: This fix was identified during a code audit and is based on datasheet specifications. It has not been tested on real hardware. Fixes: 43e53407f680 ("Add tsys01 meas-spec driver support") Signed-off-by: Salah Triki <salah.triki@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4701e471c16866e7aa8f5e6a3a6b0d31e097e2c9 upstream.

The current implementation of tsys01_crc_valid() incorrectly sums the
first word (n_prom[0]) repeatedly instead of iterating over the 8 words
retrieved from the PROM. This leads to a checksum mismatch and probe
failure on hardware.

According to the TSYS01 datasheet, the PROM consists of 8 words. A valid
check must iterate through all 8 words to verify the integrity of the
calibration data. The current driver only checks the first word 8 times.

Note: This fix was identified during a code audit and is based on
datasheet specifications. It has not been tested on real hardware.

Fixes: 43e53407f680 ("Add tsys01 meas-spec driver support")
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: temperature: maxim_thermocouple: use DMA-safe buffer for spi_read() 2025-08-28T14:28:47+00:00 David Lechner dlechner@baylibre.com 2025-08-24T13:01:40+00:00 f13768b9b8293c9eb723f8068a8b6b3865e54135 [ Upstream commit ae5bc07ec9f73a41734270ef3f800c5c8a7e0ad3 ] Replace using stack-allocated buffers with a DMA-safe buffer for use with spi_read(). This allows the driver to be safely used with DMA-enabled SPI controllers. The buffer array is also converted to a struct with a union to make the usage of the memory in the buffer more clear and ensure proper alignment. Fixes: 1f25ca11d84a ("iio: temperature: add support for Maxim thermocouple chips") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250721-iio-use-more-iio_declare_buffer_with_ts-3-v2-1-0c68d41ccf6c@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [ iio_push_to_buffers_with_ts() => iio_push_to_buffers_with_timestamp() ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit ae5bc07ec9f73a41734270ef3f800c5c8a7e0ad3 ]

Replace using stack-allocated buffers with a DMA-safe buffer for use
with spi_read(). This allows the driver to be safely used with
DMA-enabled SPI controllers.

The buffer array is also converted to a struct with a union to make the
usage of the memory in the buffer more clear and ensure proper alignment.

Fixes: 1f25ca11d84a ("iio: temperature: add support for Maxim thermocouple chips")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20250721-iio-use-more-iio_declare_buffer_with_ts-3-v2-1-0c68d41ccf6c@baylibre.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[ iio_push_to_buffers_with_ts() => iio_push_to_buffers_with_timestamp() ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer. 2025-05-18T06:24:09+00:00 Jonathan Cameron Jonathan.Cameron@huawei.com 2025-04-13T10:34:36+00:00 85d430aef40ad5c426ec21a9e2f98ca6e401ea36 [ Upstream commit f79aeb6c631b57395f37acbfbe59727e355a714c ] The trick of using __aligned(IIO_DMA_MINALIGN) ensures that there is no overlap between buffers used for DMA and those used for driver state storage that are before the marking. It doesn't ensure anything above state variables found after the marking. Hence move this particular bit of state earlier in the structure. Fixes: 10897f34309b ("iio: temp: maxim_thermocouple: Fix alignment for DMA safety") Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-14-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f79aeb6c631b57395f37acbfbe59727e355a714c ]

The trick of using __aligned(IIO_DMA_MINALIGN) ensures that there is
no overlap between buffers used for DMA and those used for driver
state storage that are before the marking. It doesn't ensure
anything above state variables found after the marking. Hence
move this particular bit of state earlier in the structure.

Fixes: 10897f34309b ("iio: temp: maxim_thermocouple: Fix alignment for DMA safety")
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250413103443.2420727-14-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
iio: adc: Explicitly include correct DT includes 2023-07-23T12:38:13+00:00 Rob Herring robh@kernel.org 2023-07-14T17:46:26+00:00 1240c94ce81958f1e2962f6140081b082d013ba9 The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20230714174628.4057920-1-robh@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20230714174628.4057920-1-robh@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: temperature: tmp006: Add OF device matching support 2023-05-28T19:22:03+00:00 Anup Sharma anupnewsmail@gmail.com 2023-05-20T10:55:38+00:00 12a875055c15279c4f2db14cb0b593d81d16fc0b Adds an of_device_id table entry to the driver, enabling device matching through device tree. With this update, the driver can now match devices using both the i2c_device_id entry and the newly added of_device_id table. Signed-off-by: Anup Sharma <anupnewsmail@gmail.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/72746bdfd8f74171943e41759b891c7af40627ec.1684579603.git.anupnewsmail@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Adds an of_device_id table entry to the driver, enabling
device matching through device tree. With this update, the driver
can now match devices using both the i2c_device_id entry and the
newly added of_device_id table.

Signed-off-by: Anup Sharma <anupnewsmail@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/72746bdfd8f74171943e41759b891c7af40627ec.1684579603.git.anupnewsmail@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: mlx90614: Add MLX90615 support 2023-05-23T20:20:17+00:00 Marek Vasut marex@denx.de 2023-05-10T10:22:51+00:00 7699e975e54a47de79de9fcc4b83df61ecd86cd5 Add support for MLX90615 Infra Red Thermometer, which seems to be the predecesor of MLX90614 . There are significant differences in the register layout compared to MLX90614, but the functionality of the device is virtually identical. The following differences have been identified: - RAM/EEPROM/SLEEP access opcodes are different - RAM/EEPROM registers are at different offsets - EEPROM emissivity and configuration registers are at different offsets - EEPROM configuration register bits are shuffled around - EEPROM emissivity settings are 14 bit on MLX90615 , 16 bit on MLX90614 - MLX90615 can only ever support one sensor, MLX90614 could support two - FIR filter is set to fixed settings on MLX90615 - IIR filter coefficients are different This patch fills in the MLX90615 specific description and quirk handling. The IIR filter coefficients were provided by Melexis as follows: 0b0000 - Forbidden value 0b0001 - 100% - settling time = refresh rate = 205ms (around 5Hz) 0b0010 - 50% - settling time = 2050ms (around 0.5Hz) 0b0011 - 33% - settling time = 36900ms (around 0.3Hz) 0b0100 - 25% - settling time = 5125ms (around 0.2Hz) 0b0101 - 20% - settling time = 6355ms (around 0.15Hz) 0b0110 - 17% - settling time = 7790ms (around 0.13Hz) 0b0111 - 14% - settling time = 9225ms (around 0.1Hz) Signed-off-by: Marek Vasut <marex@denx.de> Acked-by: Crt Mori <cmo@melexis.com> Link: https://lore.kernel.org/r/20230510102251.10118-6-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Add support for MLX90615 Infra Red Thermometer, which seems to be
the predecesor of MLX90614 . There are significant differences in
the register layout compared to MLX90614, but the functionality
of the device is virtually identical.

The following differences have been identified:
- RAM/EEPROM/SLEEP access opcodes are different
- RAM/EEPROM registers are at different offsets
- EEPROM emissivity and configuration registers are at different offsets
- EEPROM configuration register bits are shuffled around
- EEPROM emissivity settings are 14 bit on MLX90615 , 16 bit on MLX90614
- MLX90615 can only ever support one sensor, MLX90614 could support two
- FIR filter is set to fixed settings on MLX90615
- IIR filter coefficients are different

This patch fills in the MLX90615 specific description and quirk handling.

The IIR filter coefficients were provided by Melexis as follows:
0b0000 - Forbidden value
0b0001 - 100% - settling time = refresh rate = 205ms (around 5Hz)
0b0010 - 50% - settling time = 2050ms (around 0.5Hz)
0b0011 - 33% - settling time = 36900ms (around 0.3Hz)
0b0100 - 25% - settling time = 5125ms (around 0.2Hz)
0b0101 - 20% - settling time = 6355ms (around 0.15Hz)
0b0110 - 17% - settling time = 7790ms (around 0.13Hz)
0b0111 - 14% - settling time = 9225ms (around 0.1Hz)

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Crt Mori <cmo@melexis.com>
Link: https://lore.kernel.org/r/20230510102251.10118-6-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: mlx90614: Factor our register IO and constants into model specific descriptor 2023-05-23T20:20:17+00:00 Marek Vasut marex@denx.de 2023-05-10T10:22:50+00:00 3d5ead238bc85ecca115481a91b63548f156a7f7 Factor out all the differences between MLX90614 and other similar chips into a structure which describes the chip and allows abstracting out the differences from the driver code. No functional change. This patch moves all the RAM and EEPROM IO opcodes into the descriptor structure and combines them, instead of combining the opcode and offset in macros. Acked-by: Crt Mori <cmo@melexis.com> Tested-by: Crt Mori <cmo@melexis.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230510102251.10118-5-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Factor out all the differences between MLX90614 and other similar chips
into a structure which describes the chip and allows abstracting out the
differences from the driver code. No functional change.

This patch moves all the RAM and EEPROM IO opcodes into the descriptor
structure and combines them, instead of combining the opcode and offset
in macros.

Acked-by: Crt Mori <cmo@melexis.com>
Tested-by: Crt Mori <cmo@melexis.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230510102251.10118-5-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: mlx90614: Drop MLX90614_CONST_EMISSIVITY_RESOLUTION 2023-05-23T20:20:16+00:00 Marek Vasut marex@denx.de 2023-05-10T10:22:49+00:00 8a0377bf671da3a4737d5bff2a974c3049cedbfe The MLX90614_CONST_EMISSIVITY_RESOLUTION can be calculated from MLX90614_CONST_RAW_EMISSIVITY_MAX, perform the calculation inline and drio the MLX90614_CONST_EMISSIVITY_RESOLUTION. Signed-off-by: Marek Vasut <marex@denx.de> Acked-by: Crt Mori <cmo@melexis.com> Link: https://lore.kernel.org/r/20230510102251.10118-4-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
The MLX90614_CONST_EMISSIVITY_RESOLUTION can be calculated from
MLX90614_CONST_RAW_EMISSIVITY_MAX, perform the calculation inline
and drio the MLX90614_CONST_EMISSIVITY_RESOLUTION.

Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Crt Mori <cmo@melexis.com>
Link: https://lore.kernel.org/r/20230510102251.10118-4-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: mlx90614: Drop unused register macros 2023-05-23T20:20:16+00:00 Marek Vasut marex@denx.de 2023-05-10T10:22:48+00:00 02214837287640f94f5fb7d1bf3e696101230507 To simplify addition of support for new parts, drop unused register macros. No functional change. Acked-by: Crt Mori <cmo@melexis.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230510102251.10118-3-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
To simplify addition of support for new parts, drop unused register macros.
No functional change.

Acked-by: Crt Mori <cmo@melexis.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230510102251.10118-3-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: mlx90614: Sort headers 2023-05-23T20:20:16+00:00 Marek Vasut marex@denx.de 2023-05-10T10:22:47+00:00 4c077429b42245f9aae855027758c9e6d05bcf33 Sort the headers alphabetically. No functional change. Acked-by: Crt Mori <cmo@melexis.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230510102251.10118-2-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Sort the headers alphabetically. No functional change.

Acked-by: Crt Mori <cmo@melexis.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230510102251.10118-2-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>