<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/iio, branch v6.8.4</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.8.4</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.8.4'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-04-03T13:32:08Z</updated>
<entry>
<title>iio: adc: rockchip_saradc: use mask for write_enable bitfield</title>
<updated>2024-04-03T13:32:08Z</updated>
<author>
<name>Quentin Schulz</name>
<email>quentin.schulz@theobroma-systems.com</email>
</author>
<published>2024-02-23T12:45:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4434bd1c5830f5f003c3bd60eae0cd0fba076aa9'/>
<id>urn:sha1:4434bd1c5830f5f003c3bd60eae0cd0fba076aa9</id>
<content type='text'>
[ Upstream commit 5b4e4b72034f85f7a0cdd147d3d729c5a22c8764 ]

Some of the registers on the SARADCv2 have bits write protected except
if another bit is set. This is usually done by having the lowest 16 bits
store the data to write and the highest 16 bits specify which of the 16
lowest bits should have their value written to the hardware block.

The write_enable mask for the channel selection was incorrect because it
was just the value shifted by 16 bits, which means it would only ever
write bits and never clear them. So e.g. if someone starts a conversion
on channel 5, the lowest 4 bits would be 0x5, then starts a conversion
on channel 0, it would still be 5.

Instead of shifting the value by 16 as the mask, let's use the OR'ing of
the appropriate masks shifted by 16.

Note that this is not an issue currently because the only SARADCv2
currently supported has a reset defined in its Device Tree, that reset
resets the SARADC controller before starting a conversion on a channel.
However, this reset is handled as optional by the probe function and
thus proper masking should be used in the event an SARADCv2 without a
reset ever makes it upstream.

Fixes: 757953f8ec69 ("iio: adc: rockchip_saradc: Add support for RK3588")
Signed-off-by: Quentin Schulz &lt;quentin.schulz@theobroma-systems.com&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/20240223-saradcv2-chan-mask-v1-2-84b06a0f623a@theobroma-systems.com
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: adc: rockchip_saradc: fix bitmask for channels on SARADCv2</title>
<updated>2024-04-03T13:32:08Z</updated>
<author>
<name>Quentin Schulz</name>
<email>quentin.schulz@theobroma-systems.com</email>
</author>
<published>2024-02-23T12:45:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2349f90e50e082126053ef0156bfb9d4c3a5b856'/>
<id>urn:sha1:2349f90e50e082126053ef0156bfb9d4c3a5b856</id>
<content type='text'>
[ Upstream commit b0a4546df24a4f8c59b2d05ae141bd70ceccc386 ]

The SARADCv2 on RK3588 (the only SoC currently supported that has an
SARADCv2) selects the channel through the channel_sel bitfield which is
the 4 lowest bits, therefore the mask should be GENMASK(3, 0) and not
GENMASK(15, 0).

Fixes: 757953f8ec69 ("iio: adc: rockchip_saradc: Add support for RK3588")
Signed-off-by: Quentin Schulz &lt;quentin.schulz@theobroma-systems.com&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20240223-saradcv2-chan-mask-v1-1-84b06a0f623a@theobroma-systems.com
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: gts-helper: Fix division loop</title>
<updated>2024-03-26T22:17:29Z</updated>
<author>
<name>Matti Vaittinen</name>
<email>mazziesaccount@gmail.com</email>
</author>
<published>2024-02-12T11:20:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f8ca7ac74370e151c20199d0a06618a03301f146'/>
<id>urn:sha1:f8ca7ac74370e151c20199d0a06618a03301f146</id>
<content type='text'>
[ Upstream commit bb76cc45dcdfcd962a5994b8fe19ab74fc6c3c3a ]

The loop based 64bit division may run for a long time when dividend is a
lot bigger than the divider. Replace the division loop by the
div64_u64() which implementation may be significantly faster.

Tested-by: Subhajit Ghosh &lt;subhajit.ghosh@tweaklogic.com&gt;
Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers")
Link: https://lore.kernel.org/r/Zcn-6e-0-nh2WcfU@drtxq0yyyyyyyyyyyyyby-3.rev.dnainternet.fi
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: pressure: mprls0025pa fix off-by-one enum</title>
<updated>2024-03-26T22:17:28Z</updated>
<author>
<name>Petre Rodan</name>
<email>petre.rodan@subdimension.ro</email>
</author>
<published>2023-12-29T09:24:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ebf5db13510a922bead1214752f5c65e16c3baae'/>
<id>urn:sha1:ebf5db13510a922bead1214752f5c65e16c3baae</id>
<content type='text'>
[ Upstream commit 9e65506ca9c7ff716c8441a33417820ad61d3a16 ]

Fix off-by-one error in transfer-function property.
The honeywell,transfer-function property takes values between 1-3 so
make sure the proper enum gets used.

Fixes: 713337d9143ed ("iio: pressure: Honeywell mprls0025pa pressure sensor")
Co-developed-by: Andreas Klinger &lt;ak@it-klinger.de&gt;
Signed-off-by: Andreas Klinger &lt;ak@it-klinger.de&gt;
Signed-off-by: Petre Rodan &lt;petre.rodan@subdimension.ro&gt;
Link: https://lore.kernel.org/r/20231229092445.30180-5-petre.rodan@subdimension.ro
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iio: accel: adxl367: fix I2C FIFO data register</title>
<updated>2024-02-25T14:31:14Z</updated>
<author>
<name>Cosmin Tanislav</name>
<email>demonsingur@gmail.com</email>
</author>
<published>2024-02-07T03:36:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=11dadb631007324c7a8bcb2650eda88ed2b9eed0'/>
<id>urn:sha1:11dadb631007324c7a8bcb2650eda88ed2b9eed0</id>
<content type='text'>
As specified in the datasheet, the I2C FIFO data register is
0x18, not 0x42. 0x42 was used by mistake when adapting the
ADXL372 driver.

Fix this mistake.

Fixes: cbab791c5e2a ("iio: accel: add ADXL367 driver")
Signed-off-by: Cosmin Tanislav &lt;demonsingur@gmail.com&gt;
Reviewed-by: Nuno Sa &lt;nuno.sa@analog.com&gt;
Link: https://lore.kernel.org/r/20240207033657.206171-2-demonsingur@gmail.com
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: accel: adxl367: fix DEVID read after reset</title>
<updated>2024-02-25T14:30:45Z</updated>
<author>
<name>Cosmin Tanislav</name>
<email>demonsingur@gmail.com</email>
</author>
<published>2024-02-07T03:36:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1b926914bbe4e30cb32f268893ef7d82a85275b8'/>
<id>urn:sha1:1b926914bbe4e30cb32f268893ef7d82a85275b8</id>
<content type='text'>
regmap_read_poll_timeout() will not sleep before reading,
causing the first read to return -ENXIO on I2C, since the
chip does not respond to it while it is being reset.

The datasheet specifies that a soft reset operation has a
latency of 7.5ms.

Add a 15ms sleep between reset and reading the DEVID register,
and switch to a simple regmap_read() call.

Fixes: cbab791c5e2a ("iio: accel: add ADXL367 driver")
Signed-off-by: Cosmin Tanislav &lt;demonsingur@gmail.com&gt;
Reviewed-by: Nuno Sa &lt;nuno.sa@analog.com&gt;
Link: https://lore.kernel.org/r/20240207033657.206171-1-demonsingur@gmail.com
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: pressure: dlhl60d: Initialize empty DLH bytes</title>
<updated>2024-02-25T12:11:31Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2024-02-23T17:29:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a1c9f508db2543aae59ea2378b07a026f6c917cf'/>
<id>urn:sha1:a1c9f508db2543aae59ea2378b07a026f6c917cf</id>
<content type='text'>
3 bytes were being read but 4 were being written. Explicitly initialize
the unused bytes to 0 and refactor the loop to use direct array
indexing, which appears to silence a Clang false positive warning[1].

Indent improvement included for readability of the fixed code.

Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1]
Fixes: ac78c6aa4a5d ("iio: pressure: Add driver for DLH pressure sensors")
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240223172936.it.875-kees@kernel.org
Cc: &lt;Stable@vger.kerenl.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: imu: inv_mpu6050: fix frequency setting when chip is off</title>
<updated>2024-02-25T11:42:12Z</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2024-02-19T15:47:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=daec424cc57b33a28f8621eb7ac85f8bd327bd6b'/>
<id>urn:sha1:daec424cc57b33a28f8621eb7ac85f8bd327bd6b</id>
<content type='text'>
Track correctly FIFO state and apply ODR change before starting
the chip. Without the fix, you cannot change ODR more than 1 time
when data buffering is off. This restriction on a single pending ODR
change should only apply when the FIFO is on.

Fixes: 111e1abd0045 ("iio: imu: inv_mpu6050: use the common inv_sensors timestamp module")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Link: https://lore.kernel.org/r/20240219154741.90601-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: pressure: Fixes BMP38x and BMP390 SPI support</title>
<updated>2024-02-24T17:57:07Z</updated>
<author>
<name>Vasileios Amoiridis</name>
<email>vassilisamir@gmail.com</email>
</author>
<published>2024-02-19T19:13:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a9dd9ba323114f366eb07f1d9630822f8df6cbb2'/>
<id>urn:sha1:a9dd9ba323114f366eb07f1d9630822f8df6cbb2</id>
<content type='text'>
According to the datasheet of BMP38x and BMP390 devices, for an SPI
read operation the first byte that is returned needs to be dropped,
and the rest of the bytes are the actual data returned from the
sensor.

Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Fixes: 8d329309184d ("iio: pressure: bmp280: Add support for BMP380 sensor family")
Signed-off-by: Vasileios Amoiridis &lt;vassilisamir@gmail.com&gt;
Acked-by: Angel Iglesias &lt;ang.iglesiasg@gmail.com&gt;
Link: https://lore.kernel.org/r/20240219191359.18367-1-vassilisamir@gmail.com
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: imu: inv_mpu6050: fix FIFO parsing when empty</title>
<updated>2024-02-24T16:25:24Z</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2024-02-19T15:48:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=60caa8b33bd682a9ed99d1fc3f91d74e1acc9922'/>
<id>urn:sha1:60caa8b33bd682a9ed99d1fc3f91d74e1acc9922</id>
<content type='text'>
Now that we are reading the full FIFO in the interrupt handler,
it is possible to have an emply FIFO since we are still receiving
1 interrupt per data. Handle correctly this case instead of having
an error causing a reset of the FIFO.

Fixes: 0829edc43e0a ("iio: imu: inv_mpu6050: read the full fifo when processing data")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Link: https://lore.kernel.org/r/20240219154825.90656-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
</feed>
