<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/iio, branch v4.19.16</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.16</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.16'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-01-13T08:51:08+00:00</updated>
<entry>
<title>iio: dac: ad5686: fix bit shift read register</title>
<updated>2019-01-13T08:51:08+00:00</updated>
<author>
<name>Mircea Caprioru</name>
<email>mircea.caprioru@analog.com</email>
</author>
<published>2018-12-06T13:53:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af7cc8ebab4aade6b2a1860b31bbdda3c9739ecc'/>
<id>urn:sha1:af7cc8ebab4aade6b2a1860b31bbdda3c9739ecc</id>
<content type='text'>
commit 0e76df5c978338f3051e5126fc0c4245c57a307a upstream.

This patch solves the register readback issue with the bit shift. When the
dac resolution was lower than the register size (ex. 12 bits out of 16
bits) the readback value was not shifted with the difference in bits and
the value was higher. Also a mask is applied on the read value in order to
get the value relative to the actual bit size.

Fixes: 0357e488b8 ("iio:dac:ad5686: Refactor the driver")
Signed-off-by: Mircea Caprioru &lt;mircea.caprioru@analog.com&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:st_magn: Fix enable device after trigger</title>
<updated>2018-12-05T18:32:13+00:00</updated>
<author>
<name>Martin Kelly</name>
<email>martin@martingkelly.com</email>
</author>
<published>2018-10-29T03:18:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=855f9dc87160f9351291cbe52056fa08529532d3'/>
<id>urn:sha1:855f9dc87160f9351291cbe52056fa08529532d3</id>
<content type='text'>
commit fe5192ac81ad0d4dfe1395d11f393f0513c15f7f upstream.

Currently, we enable the device before we enable the device trigger. At
high frequencies, this can cause interrupts that don't yet have a poll
function associated with them and are thus treated as spurious. At high
frequencies with level interrupts, this can even cause an interrupt storm
of repeated spurious interrupts (~100,000 on my Beagleboard with the
LSM9DS1 magnetometer). If these repeat too much, the interrupt will get
disabled and the device will stop functioning.

To prevent these problems, enable the device prior to enabling the device
trigger, and disable the divec prior to disabling the trigger. This means
there's no window of time during which the device creates interrupts but we
have no trigger to answer them.

Fixes: 90efe055629 ("iio: st_sensors: harden interrupt handling")
Signed-off-by: Martin Kelly &lt;martin@martingkelly.com&gt;
Tested-by: Denis Ciocca &lt;denis.ciocca@st.com&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/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbers</title>
<updated>2018-12-05T18:32:13+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-31T14:20:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ec800c8b028ec5b42dc81421d04a6d4649d44b51'/>
<id>urn:sha1:ec800c8b028ec5b42dc81421d04a6d4649d44b51</id>
<content type='text'>
commit 0145b50566e7de5637e80ecba96c7f0e6fff1aad upstream.

Before this commit sensor_hub_input_attr_get_raw_value() failed to take
the signedness of 16 and 8 bit values into account, returning e.g.
65436 instead of -100 for the z-axis reading of an accelerometer.

This commit adds a new is_signed parameter to the function and makes all
callers pass the appropriate value for this.

While at it, this commit also fixes up some neighboring lines where
statements were needlessly split over 2 lines to improve readability.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&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: adc: at91: fix wrong channel number in triggered buffer mode</title>
<updated>2018-11-13T19:08:47+00:00</updated>
<author>
<name>Eugen Hristev</name>
<email>eugen.hristev@microchip.com</email>
</author>
<published>2018-09-24T07:51:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cf6ab9439838cdcae65d3ad86361fca251786359'/>
<id>urn:sha1:cf6ab9439838cdcae65d3ad86361fca251786359</id>
<content type='text'>
commit aea835f2dc8a682942b859179c49ad1841a6c8b9 upstream.

When channels are registered, the hardware channel number is not the
actual iio channel number.
This is because the driver is probed with a certain number of accessible
channels. Some pins are routed and some not, depending on the description of
the board in the DT.
Because of that, channels 0,1,2,3 can correspond to hardware channels
2,3,4,5 for example.
In the buffered triggered case, we need to do the translation accordingly.
Fixed the channel number to stop reading the wrong channel.

Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard &lt;maxime.ripard@bootlin.com&gt;
Signed-off-by: Eugen Hristev &lt;eugen.hristev@microchip.com&gt;
Acked-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&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: adc: at91: fix acking DRDY irq on simple conversions</title>
<updated>2018-11-13T19:08:47+00:00</updated>
<author>
<name>Eugen Hristev</name>
<email>eugen.hristev@microchip.com</email>
</author>
<published>2018-09-24T07:51:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7e95f41121dcff8d2d61fe31d793b333c82b8a5'/>
<id>urn:sha1:b7e95f41121dcff8d2d61fe31d793b333c82b8a5</id>
<content type='text'>
commit bc1b45326223e7e890053cf6266357adfa61942d upstream.

When doing simple conversions, the driver did not acknowledge the DRDY irq.
If this irq status is not acked, it will be left pending, and as soon as a
trigger is enabled, the irq handler will be called, it doesn't know why
this status has occurred because no channel is pending, and then it will go
int a irq loop and board will hang.
To avoid this situation, read the LCDR after a raw conversion is done.

Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard &lt;maxime.ripard@bootlin.com&gt;
Signed-off-by: Eugen Hristev &lt;eugen.hristev@microchip.com&gt;
Acked-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&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: adc: imx25-gcq: Fix leak of device_node in mx25_gcq_setup_cfgs()</title>
<updated>2018-11-13T19:08:47+00:00</updated>
<author>
<name>Alexey Khoroshilov</name>
<email>khoroshilov@ispras.ru</email>
</author>
<published>2018-09-21T21:58:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f809deba3e5771b177695edc572232969744c226'/>
<id>urn:sha1:f809deba3e5771b177695edc572232969744c226</id>
<content type='text'>
commit d3fa21c73c391975488818b085b894c2980ea052 upstream.

Leaving for_each_child_of_node loop we should release child device node,
if it is not stored for future use.

Found by Linux Driver Verification project (linuxtesting.org).

JC: I'm not sending this as a quick fix as it's been wrong for years,
but good to pick up for stable after the merge window.

Signed-off-by: Alexey Khoroshilov &lt;khoroshilov@ispras.ru&gt;
Fixes: 6df2e98c3ea56 ("iio: adc: Add imx25-gcq ADC driver")
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: ad5064: Fix regulator handling</title>
<updated>2018-11-13T19:08:47+00:00</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2018-09-28T09:23:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57629351f0a627101ac85419bb7b25c4af743809'/>
<id>urn:sha1:57629351f0a627101ac85419bb7b25c4af743809</id>
<content type='text'>
commit 8911a43bc198877fad9f4b0246a866b26bb547ab upstream.

The correct way to handle errors returned by regualtor_get() and friends is
to propagate the error since that means that an regulator was specified,
but something went wrong when requesting it.

For handling optional regulators, e.g. when the device has an internal
vref, regulator_get_optional() should be used to avoid getting the dummy
regulator that the regulator core otherwise provides.

Signed-off-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>Merge tag 'iio-fixes-4.19a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus</title>
<updated>2018-09-09T07:33:29+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-09-09T07:33:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eca743dc37e1018decfb307d564387477c1ac4fd'/>
<id>urn:sha1:eca743dc37e1018decfb307d564387477c1ac4fd</id>
<content type='text'>
Jonathan writes:

First set of IIO fixes for the 4.19 cycle.

* ad9523
  - sysfs write should return the number of characters used or an error, not
    0 which could result in an infinite loop in userspace.
* lsm6dsx
  - Fix computation of length when updating the watermark to include
    timestamps avoiding the watermark being set earlier than intended.
* maxim_thermocouple
  - Revert a patch adding the max31856 as it's not actually compatible with
    the register set that this driver supports.
* si1133
  - Fix an impossible value check so we don't always error out whether the
    passed in value is good or bad.
</content>
</entry>
<entry>
<title>iio: imu: st_lsm6dsx: take into account ts samples in wm configuration</title>
<updated>2018-09-02T20:19:53+00:00</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo.bianconi@redhat.com</email>
</author>
<published>2018-08-31T08:51:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a13bf65f3f2e36008ea60b49d3bda2527e09fd9c'/>
<id>urn:sha1:a13bf65f3f2e36008ea60b49d3bda2527e09fd9c</id>
<content type='text'>
Take into account hw timer samples in pattern length computation done
in st_lsm6dsx_update_watermark routine for watermark configuration.
Moreover use samples in pattern (sip) already computed in
st_lsm6dsx_update_decimators routine

Fixes: 213451076bd3 ("iio: imu: st_lsm6dsx: add hw timestamp support")
Signed-off-by: Lorenzo Bianconi &lt;lorenzo.bianconi@redhat.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>Revert "iio: temperature: maxim_thermocouple: add MAX31856 part"</title>
<updated>2018-09-02T09:13:06+00:00</updated>
<author>
<name>Matt Ranostay</name>
<email>matt.ranostay@konsulko.com</email>
</author>
<published>2018-08-25T09:00:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=65099ea85e885c3ea1272eca8774b771419d8ce8'/>
<id>urn:sha1:65099ea85e885c3ea1272eca8774b771419d8ce8</id>
<content type='text'>
This reverts commit 535fba29b3e1afef4ba201b3c69a6992583ec0bd.

Seems the submitter (er me, hang head in shame) didn't look at the datasheet
enough to see that the registers are quite different.

This needs to be reverted because a) would never work b) to open it  be added
to a Maxim RTDs (Resistance Temperature Detectors) under development by author

Signed-off-by: Matt Ranostay &lt;matt.ranostay@konsulko.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
</feed>
