linux-kernel - Re: [PATCH v2 03/10] rtc: max77686: Use usleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jan 2016 16:47:37 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Javier Martinez Canillas <javier@....samsung.com>,
	<linux-kernel@...r.kernel.org>
CC:	Kukjin Kim <kgene@...nel.org>, <rtc-linux@...glegroups.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	<linux-samsung-soc@...r.kernel.org>
Subject: Re: [PATCH v2 03/10] rtc: max77686: Use usleep_range() instead of
 msleep()


On Friday 22 January 2016 05:35 PM, Javier Martinez Canillas wrote:
> Hello Laxman,
>
> On 01/22/2016 06:41 AM, Laxman Dewangan wrote:
>>
>> On Friday 22 January 2016 01:53 AM, Javier Martinez Canillas wrote:
>>>       RTC_SEC = 0,
>>> @@ -130,7 +130,8 @@ static int max77686_rtc_update(struct 
>>> max77686_rtc_info *info,
>>>                   __func__, ret, data);
>>>       else {
>>>           /* Minimum 16ms delay required before RTC update. */
>>> -        msleep(MAX77686_RTC_UPDATE_DELAY);
>>> +        usleep_range(MAX77686_RTC_UPDATE_DELAY,
>>> +                 MAX77686_RTC_UPDATE_DELAY * 2);
>>>       }
>>>
>>
>> Instead of making usleep_range(16000, 32000), can we make small range as
>> usleep_range(16000, 17000)?
>>
>
> Yes, I also didn't know how to make the delay smaller. If I do for 
> example
>
> usleep_range(delay, delay + 10000), then the 10000 delta would be too big
> for max77802 (50 times the minimum required 200 delay).
>
> So I used delay * 2 for two reasons:
>
> 1) That way is generic enough and can work for any delay
>
> 2) My understanding is that most of times the delay should be precise and
>    is not that bad if sometimes the delay is the worst case (2 * X) since
>    after all the delay is the minimum required.
>
> I also see that usleep_range(X, X * 2) is a used pattern across the 
> kernel.

OK, fine to me here.

Acked-by: Laxman Dewangan <ldewangan@...dia.com>