On 06/04/16 15:58, Laxman Dewangan wrote:Sure. I will CC.
Hi Daniel,It's actually worse than that having taken a quick look at the generic-adc thermal patch
On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote:
On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan <ldewangan@xxxxxxxxxx> wrote:Most of client for this APIs are in other subsystem.
Some of kernel driver uses the IIO framework to get the sensorPlease provide at least one example of code that uses this API.
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get() and release it by calling iio_channel_release().
Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get() then it need not to release it explicitly,
it can be done by managed device framework when driver get un-binded.
This reduces the code in error path and also need of .remove callback in
some cases.
When I was working on the patch
[PATCH 2/2] thermal: generic-adc: Add ADC based thermal sensor driver
if I have devm_iio_channel_get() then I can get .remove callback at all.
I did not use this new APIs in my patch because they are in different subsystem.
you reference above.
(perhaps worth cc'ing linux-iio for next version of that).
Yaah, possibly race for very small time possible.
Without this devm function set you have a race in remove in which I think you can
get attempts to access the channels after they have been released...