<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/iio/adc, branch linux-4.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-10-12T09:56:12Z</updated>
<entry>
<title>iio: adc: mcp320x: Fix oops on module unload</title>
<updated>2017-10-12T09:56:12Z</updated>
<author>
<name>Lukas Wunner</name>
</author>
<published>2017-08-22T13:33:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c1a48628ca064938425b063314778a4ffa467b03'/>
<id>urn:sha1:c1a48628ca064938425b063314778a4ffa467b03</id>
<content type='text'>
commit 0964e40947a630a2a6f724e968246992f97bcf1c upstream.

The driver calls spi_get_drvdata() in its -&gt;remove hook even though it
has never called spi_set_drvdata().  Stack trace for posterity:

Unable to handle kernel NULL pointer dereference at virtual address 00000220
Internal error: Oops: 5 [#1] SMP ARM
[&lt;8072f564&gt;] (mutex_lock) from [&lt;7f1400d0&gt;] (iio_device_unregister+0x24/0x7c [industrialio])
[&lt;7f1400d0&gt;] (iio_device_unregister [industrialio]) from [&lt;7f15e020&gt;] (mcp320x_remove+0x20/0x30 [mcp320x])
[&lt;7f15e020&gt;] (mcp320x_remove [mcp320x]) from [&lt;8055a8cc&gt;] (spi_drv_remove+0x2c/0x44)
[&lt;8055a8cc&gt;] (spi_drv_remove) from [&lt;805087bc&gt;] (__device_release_driver+0x98/0x134)
[&lt;805087bc&gt;] (__device_release_driver) from [&lt;80509180&gt;] (driver_detach+0xdc/0xe0)
[&lt;80509180&gt;] (driver_detach) from [&lt;8050823c&gt;] (bus_remove_driver+0x5c/0xb0)
[&lt;8050823c&gt;] (bus_remove_driver) from [&lt;80509ab0&gt;] (driver_unregister+0x38/0x58)
[&lt;80509ab0&gt;] (driver_unregister) from [&lt;7f15e69c&gt;] (mcp320x_driver_exit+0x14/0x1c [mcp320x])
[&lt;7f15e69c&gt;] (mcp320x_driver_exit [mcp320x]) from [&lt;801a78d0&gt;] (SyS_delete_module+0x184/0x1d0)
[&lt;801a78d0&gt;] (SyS_delete_module) from [&lt;80108100&gt;] (ret_fast_syscall+0x0/0x1c)

Fixes: f5ce4a7a9291 ("iio: adc: add driver for MCP3204/08 12-bit ADC")
Cc: Oskar Andero &lt;oskar.andero@gmail.com&gt;
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&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: mcp320x: Fix readout of negative voltages</title>
<updated>2017-10-12T09:56:12Z</updated>
<author>
<name>Lukas Wunner</name>
</author>
<published>2017-08-22T13:33:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d91dc0183e1427ff8cd50747dcdfb1e4c37bc402'/>
<id>urn:sha1:d91dc0183e1427ff8cd50747dcdfb1e4c37bc402</id>
<content type='text'>
commit e6f4794371ee7cce1339e7ca9542f1e703c5f84a upstream.

Commit f686a36b4b79 ("iio: adc: mcp320x: Add support for mcp3301")
returns a signed voltage from mcp320x_adc_conversion() but neglects that
the caller interprets a negative return value as failure.  Only mcp3301
(and the upcoming mcp3550/1/3) is affected as the other chips are
incapable of measuring negative voltages.

Fix and while at it, add mcp3301 to the list of supported chips at the
top of the file.

Fixes: f686a36b4b79 ("iio: adc: mcp320x: Add support for mcp3301")
Cc: Andrea Galbusera &lt;gizero@gmail.com&gt;
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&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: stm32: fix bad error check on max_channels</title>
<updated>2017-10-12T09:56:12Z</updated>
<author>
<name>Fabrice Gasnier</name>
</author>
<published>2017-09-18T16:24:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff24f487dd3ae03324d0c802161824e6a5554ac7'/>
<id>urn:sha1:ff24f487dd3ae03324d0c802161824e6a5554ac7</id>
<content type='text'>
commit 4fb840c95f82652cece7352be9080884cafb92a0 upstream.

Fix a bad error check when counting 'st,adc-channels' array elements.
This is seen when all channels are in use simultaneously.

Fixes: 64ad7f643 ("iio: adc: stm32: introduce compatible data cfg")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@st.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: ad7793: Fix the serial interface reset</title>
<updated>2017-10-12T09:56:12Z</updated>
<author>
<name>Dragos Bogdan</name>
</author>
<published>2017-09-05T12:16:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=df1ff9f352edc10e29ce8fbea49fa7fa05f247ca'/>
<id>urn:sha1:df1ff9f352edc10e29ce8fbea49fa7fa05f247ca</id>
<content type='text'>
commit 7ee3b7ebcb74714df6d94c8f500f307e1ee5dda5 upstream.

The serial interface can be reset by writing 32 consecutive 1s to the device.
'ret' was initialized correctly but its value was overwritten when
ad7793_check_platform_data() was called. Since a dedicated reset function
is present now, it should be used instead.

Fixes: 2edb769d246e ("iio:ad7793: Add support for the ad7798 and ad7799")
Signed-off-by: Dragos Bogdan &lt;dragos.bogdan@analog.com&gt;
Acked-by: Lars-Peter Clausen &lt;lars@metafoo.de&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: ad_sigma_delta: Implement a dedicated reset function</title>
<updated>2017-10-12T09:56:11Z</updated>
<author>
<name>Dragos Bogdan</name>
</author>
<published>2017-09-05T12:14:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f095f85f204c2d4348efd52ab4dd9eee8d6c5caa'/>
<id>urn:sha1:f095f85f204c2d4348efd52ab4dd9eee8d6c5caa</id>
<content type='text'>
commit 7fc10de8d49a748c476532c9d8e8fe19e548dd67 upstream.

Since most of the SD ADCs have the option of reseting the serial
interface by sending a number of SCLKs with CS = 0 and DIN = 1,
a dedicated function that can do this is usefull.

Needed for the patch:  iio: ad7793: Fix the serial interface reset
Signed-off-by: Dragos Bogdan &lt;dragos.bogdan@analog.com&gt;
Acked-by: Lars-Peter Clausen &lt;lars@metafoo.de&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: twl4030: Disable the vusb3v1 rugulator in the error handling path of 'twl4030_madc_probe()'</title>
<updated>2017-10-12T09:56:11Z</updated>
<author>
<name>Christophe JAILLET</name>
</author>
<published>2017-09-23T06:06:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=53f11858c9bf439206bb27b4afbbb617d5e70c93'/>
<id>urn:sha1:53f11858c9bf439206bb27b4afbbb617d5e70c93</id>
<content type='text'>
commit 7f70be6e4025db0551e6863e7eb9cca07122695c upstream.

Commit 7cc97d77ee8a has introduced a call to 'regulator_disable()' in the
.remove function.
So we should also have such a call in the .probe function in case of
error after a successful 'regulator_enable()' call.

Add a new label for that and use it.

Fixes: 7cc97d77ee8a ("iio: adc: twl4030: Fix ADC[3:6] readings")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&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: twl4030: Fix an error handling path in 'twl4030_madc_probe()'</title>
<updated>2017-10-12T09:56:11Z</updated>
<author>
<name>Christophe JAILLET</name>
</author>
<published>2017-09-23T06:06:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8c912c51c4f1ad54c3633aea7af00c4bdf70ac5d'/>
<id>urn:sha1:8c912c51c4f1ad54c3633aea7af00c4bdf70ac5d</id>
<content type='text'>
commit 245a396a9b1a67ac5c3228737c261b3e48708a2a upstream.

If 'devm_regulator_get()' fails, we should go through the existing error
handling path instead of returning directly, as done is all the other
error handling paths in this function.

Fixes: 7cc97d77ee8a ("iio: adc: twl4030: Fix ADC[3:6] readings")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&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: ti-ads1015: add adequate wait time to get correct conversion</title>
<updated>2017-09-09T15:39:21Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=51a39e2bc933395383e2eb887e61f86a533fa43b'/>
<id>urn:sha1:51a39e2bc933395383e2eb887e61f86a533fa43b</id>
<content type='text'>
commit 4744d4e2afebf9644a439da9ca73d822fdd67bd9 upstream.

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
inserts a wait time before reading the conversion register if the
configuration is changed from a previous request.

Currently, the wait time is only the period required for a single
conversion that is calculated as the reciprocal of the sampling frequency.
However we also need to wait for the the previous conversion to complete.
Otherwise we probably get the conversion result for the previous
configuration when the sampling frequency is lower.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.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: ti-ads1015: don't return invalid value from buffer setup callbacks</title>
<updated>2017-09-09T15:39:21Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d9320af32f64ac3a28d7124d1dfd961e4bcc21d4'/>
<id>urn:sha1:d9320af32f64ac3a28d7124d1dfd961e4bcc21d4</id>
<content type='text'>
commit a6fe5e52d5ecfc98530034d6c9db73777cf41ede upstream.

pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
success, 1 if the device's runtime PM status was already requested status
or error code on failure.  So a positive return value doesn't indicate an
error condition.

However, any non-zero return values from buffer preenable and postdisable
callbacks are recognized as an error and this driver reuses the return
value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
these callbacks.  This change fixes the false error detections.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.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: ti-ads1015: avoid getting stale result after runtime resume</title>
<updated>2017-09-09T15:39:20Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1c68b99af8eb0c48d8b3f53a76e2fc112ef40a42'/>
<id>urn:sha1:1c68b99af8eb0c48d8b3f53a76e2fc112ef40a42</id>
<content type='text'>
commit 73e3e3fc50de50cfd68e945d85679c983ed31bd9 upstream.

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
doesn't insert a wait time before reading the conversion register if the
configuration is not changed from a previous request.

This assumption is broken if the device is runtime suspended and entered
a power-down state.  The forthcoming request causes reading a stale result
from the conversion register as the device is runtime resumed just before.

Fix it by adding a flag to detect that condition and insert a necessary
wait time.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.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>
</feed>
