[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a3b53c07-39b9-31db-0a40-4018f74dc9c6@ti.com>
Date: Wed, 17 Aug 2016 16:43:43 +0530
From: Vignesh R <vigneshr@...com>
To: Jonathan Cameron <jic23@...nel.org>
CC: Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
Lee Jones <lee.jones@...aro.org>, "Davis, Andrew" <afd@...com>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [PATCH 1/2] iio: adc: ti_am335x_adc: Protect FIFO1 from
concurrent access
On Monday 15 August 2016 09:15 PM, Jonathan Cameron wrote:
> On 08/08/16 12:05, Vignesh R wrote:
>> It is possible that two or more ADC channels can be simultaneously
>> requested for raw samples, in which case there can be race in access to
>> FIFO data resulting in loss of samples.
>> If am335x_tsc_se_set_once() is called again from tiadc_read_raw(), when
>> ADC is still acquired to sample one of the channels, the second process
>> might be put into uninterruptible sleep state. Fix these issues, by
>> protecting FIFO access and channel configurations with a mutex. Since
>> tiadc_read_raw() might take anywhere between few microseconds to few
>> milliseconds to finish execution (depending on averaging and delay
>> values supplied via DT), its better to use mutex instead of spinlock.
>>
>> Signed-off-by: Vignesh R <vigneshr@...com>
> Hi,
>
> Thanks for the patch.
>
> As this is clearly a fix for a long standing issue, I'd like to send
> it for stable inclusion. Would you mind doing a bit of detective work
> to added a Fixes tag to say which original patch introduced the issue?
>
Looks to be due to the commit 7ca6740cd1cd4 ("mfd: input: iio:
ti_amm335x: Rework TSC/ADC synchronization")
Will send v2 with fixes tag. Thanks!
--
Regards
Vignesh
Powered by blists - more mailing lists