<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/iio, branch v4.19.112</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.112</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.112'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-02-01T09:37:04+00:00</updated>
<entry>
<title>iio: st_gyro: Correct data for LSM9DS0 gyro</title>
<updated>2020-02-01T09:37:04+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2019-12-17T17:10:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c1f01628a85ede2baf25480de2edf7e0fee11c1'/>
<id>urn:sha1:3c1f01628a85ede2baf25480de2edf7e0fee11c1</id>
<content type='text'>
commit e825070f697abddf3b9b0a675ed0ff1884114818 upstream.

The commit 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support")
assumes that gyro in LSM9DS0 is the same as others with 0xd4 WAI ID,
but datasheet tells slight different story, i.e. the first scale factor
for the chip is 245 dps, and not 250 dps.

Correct this by introducing a separate settings for LSM9DS0.

Fixes: 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support")
Depends-on: 45a4e4220bf4 ("iio: gyro: st_gyro: fix L3GD20H support")
Cc: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Cc: Lorenzo Bianconi &lt;lorenzo.bianconi83@gmail.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: dac: ad5380: fix incorrect assignment to val</title>
<updated>2020-01-27T13:51:09+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-08-15T11:58:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e706ece1148f8ba3457578ad1d3a5ed65f4688b0'/>
<id>urn:sha1:e706ece1148f8ba3457578ad1d3a5ed65f4688b0</id>
<content type='text'>
[ Upstream commit b1e18768ef1214c0a8048327918a182cabe09f9d ]

Currently the pointer val is being incorrectly incremented
instead of the value pointed to by val. Fix this by adding
in the missing * indirection operator.

Addresses-Coverity: ("Unused value")
Fixes: c03f2c536818 ("staging:iio:dac: Add AD5380 driver")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&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: tsl2772: Use devm_add_action_or_reset for tsl2772_chip_off</title>
<updated>2020-01-27T13:51:03+00:00</updated>
<author>
<name>Chuhong Yuan</name>
<email>hslester96@gmail.com</email>
</author>
<published>2019-08-01T07:36:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ba099d4df90a40ffb38df0187c5372ba0ff7660'/>
<id>urn:sha1:5ba099d4df90a40ffb38df0187c5372ba0ff7660</id>
<content type='text'>
[ Upstream commit 338084135aeddb103624a6841972fb8588295cc6 ]

Use devm_add_action_or_reset to call tsl2772_chip_off
when the device is removed.
This also fixes the issue that the chip is turned off
before the device is unregistered.

Not marked for stable as fairly hard to hit the bug and
this is in the middle of a set making other cleanups
to the driver.  Hence will probably need explicit backporting.

Signed-off-by: Chuhong Yuan &lt;hslester96@gmail.com&gt;
Fixes: c06c4d793584 ("staging: iio: tsl2x7x/tsl2772: move out of staging")
Reviewed-by: Brian Masney &lt;masneyb@onstation.org&gt;
Tested-by: Brian Masney &lt;masneyb@onstation.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: buffer: align the size of scan bytes to size of the largest element</title>
<updated>2020-01-23T07:21:27+00:00</updated>
<author>
<name>Lars Möllendorf</name>
<email>lars.moellendorf@plating.de</email>
</author>
<published>2019-12-13T13:50:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5d1fe944803f619dc3b2a93584c8f935a86f507'/>
<id>urn:sha1:e5d1fe944803f619dc3b2a93584c8f935a86f507</id>
<content type='text'>
commit 883f616530692d81cb70f8a32d85c0d2afc05f69 upstream.

Previous versions of `iio_compute_scan_bytes` only aligned each element
to its own length (i.e. its own natural alignment). Because multiple
consecutive sets of scan elements are buffered this does not work in
case the computed scan bytes do not align with the natural alignment of
the first scan element in the set.

This commit fixes this by aligning the scan bytes to the natural
alignment of the largest scan element in the set.

Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.")
Signed-off-by: Lars Möllendorf &lt;lars.moellendorf@plating.de&gt;
Reviewed-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: imu: adis16480: assign bias value only if operation succeeded</title>
<updated>2020-01-17T18:47:05+00:00</updated>
<author>
<name>Alexandru Ardelean</name>
<email>alexandru.ardelean@analog.com</email>
</author>
<published>2019-11-01T09:35:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=48e5b2ceaf0e8fb89b6592b778baa199f3df11d0'/>
<id>urn:sha1:48e5b2ceaf0e8fb89b6592b778baa199f3df11d0</id>
<content type='text'>
commit 9b742763d9d4195e823ae6ece760c9ed0500c1dc upstream.

This was found only after the whole thing with the inline functions, but
the compiler actually found something. The value of the `bias` (in
adis16480_get_calibbias()) should only be set if the read operation was
successful.

No actual known problem occurs as users of this function all
ultimately check the return value.  Hence probably not stable material.

Fixes: 2f3abe6cbb6c9 ("iio:imu: Add support for the ADIS16480 and similar IMUs")
Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: max9611: Fix too short conversion time delay</title>
<updated>2020-01-09T09:18:55+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2019-12-02T08:55:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=346812c25f75b145942ef034542974c6da977afe'/>
<id>urn:sha1:346812c25f75b145942ef034542974c6da977afe</id>
<content type='text'>
[ Upstream commit 9fd229c478fbf77c41c8528aa757ef14210365f6 ]

As of commit b9ddd5091160793e ("iio: adc: max9611: Fix temperature
reading in probe"), max9611 initialization sometimes fails on the
Salvator-X(S) development board with:

    max9611 4-007f: Invalid value received from ADC 0x8000: aborting
    max9611: probe of 4-007f failed with error -5

The max9611 driver tests communications with the chip by reading the die
temperature during the probe function, which returns an invalid value.

According to the datasheet, the typical ADC conversion time is 2 ms, but
no minimum or maximum values are provided.  Maxim Technical Support
confirmed this was tested with temperature Ta=25 degreeC, and promised
to inform me if a maximum/minimum value is available (they didn't get
back to me, so I assume it is not).

However, the driver assumes a 1 ms conversion time.  Usually the
usleep_range() call returns after more than 1.8 ms, hence it succeeds.
When it returns earlier, the data register may be read too early, and
the previous measurement value will be returned.  After boot, this is
the temperature POR (power-on reset) value, causing the failure above.

Fix this by increasing the delay from 1000-2000 µs to 3000-3300 µs.

Note that this issue has always been present, but it was exposed by the
aformentioned commit.

Fixes: 69780a3bbc0b1e7e ("iio: adc: Add Maxim max9611 ADC driver")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Jacopo Mondi &lt;jacopo+renesas@jmondi.org&gt;
Reviewed-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&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: dac: ad5446: Add support for new AD5600 DAC</title>
<updated>2019-12-31T15:36:00+00:00</updated>
<author>
<name>Stefan Popa</name>
<email>stefan.popa@analog.com</email>
</author>
<published>2019-11-06T09:47:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e6e50631793e5b85c2761a24cb4563c500b733ec'/>
<id>urn:sha1:e6e50631793e5b85c2761a24cb4563c500b733ec</id>
<content type='text'>
[ Upstream commit 6376cbe549fffb378403cee78efd26b8a2c8e450 ]

The AD5600 is a single channel, 16-bit resolution, voltage output digital
to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is
part of the AD5541 family of DACs.

The ad5446 IIO driver implements support for some of these DACs (in the
AD5441 family), so the change is a simple entry in this driver.

Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf

Signed-off-by: Stefan Popa &lt;stefan.popa@analog.com&gt;
Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&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: dln2-adc: fix iio_triggered_buffer_postenable() position</title>
<updated>2019-12-31T15:35:33+00:00</updated>
<author>
<name>Alexandru Ardelean</name>
<email>alexandru.ardelean@analog.com</email>
</author>
<published>2019-10-23T08:26:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=77a6a2656c81f2d2e165cb3208a63d2c5f186de8'/>
<id>urn:sha1:77a6a2656c81f2d2e165cb3208a63d2c5f186de8</id>
<content type='text'>
[ Upstream commit a7bddfe2dfce1d8859422124abe1964e0ecd386e ]

The iio_triggered_buffer_postenable() hook should be called first to
attach the poll function. The iio_triggered_buffer_predisable() hook is
called last (as is it should).

This change moves iio_triggered_buffer_postenable() to be called first. It
adds iio_triggered_buffer_predisable() on the error paths of the postenable
hook.
For the predisable hook, some code-paths have been changed to make sure
that the iio_triggered_buffer_predisable() hook gets called in case there
is an error before it.

Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&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: max1027: Reset the device at probe time</title>
<updated>2019-12-31T15:35:17+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2019-10-11T14:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eec8f08dc8b3fa8a3ed1e1c88187b7694e640c40'/>
<id>urn:sha1:eec8f08dc8b3fa8a3ed1e1c88187b7694e640c40</id>
<content type='text'>
[ Upstream commit db033831b4f5589f9fcbadb837614a7c4eac0308 ]

All the registers are configured by the driver, let's reset the chip
at probe time, avoiding any conflict with a possible earlier
configuration.

Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&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: light: bh1750: Resolve compiler warning and make code more readable</title>
<updated>2019-12-31T15:34:48+00:00</updated>
<author>
<name>Krzysztof Wilczynski</name>
<email>kw@linux.com</email>
</author>
<published>2019-09-13T20:24:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cfcf92d8571d5f447b66d85c0bf5c9ed76f2b880'/>
<id>urn:sha1:cfcf92d8571d5f447b66d85c0bf5c9ed76f2b880</id>
<content type='text'>
[ Upstream commit f552fde983d378e7339f9ea74a25f918563bf0d3 ]

Separate the declaration of struct bh1750_chip_info from definition
of bh1750_chip_info_tbl[] in a single statement as it makes the code
hard to read, and with the extra newline it makes it look as if the
bh1750_chip_info_tbl[] had no explicit type.

This change also resolves the following compiler warning about the
unusual position of the static keyword that can be seen when building
with warnings enabled (W=1):

drivers/iio/light/bh1750.c:64:1: warning:
  ‘static’ is not at beginning of declaration [-Wold-style-declaration]

Related to commit 3a11fbb037a1 ("iio: light: add support for ROHM
BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors").

Signed-off-by: Krzysztof Wilczynski &lt;kw@linux.com&gt;
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
