linux-kernel - RE: [PATCH] ASoC: max98373: Added 10ms delay after amp software reset

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] [day] [month] [year] [list]

Date:   Fri, 24 Aug 2018 01:00:42 +0000
From:   Ryan Lee <RyanS.Lee@...imintegrated.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Mark Brown <broonie@...nel.org>
CC:     Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "ryan.lee.maxim@...il.com" <ryan.lee.maxim@...il.com>
Subject: RE: [PATCH] ASoC: max98373: Added 10ms delay after amp software reset

>-----Original Message-----
>From: Dmitry Torokhov <dmitry.torokhov@...il.com>
>Sent: Thursday, August 23, 2018 5:08 PM
>To: Mark Brown <broonie@...nel.org>
>Cc: Ryan Lee <RyanS.Lee@...imintegrated.com>; Liam Girdwood
><lgirdwood@...il.com>; Jaroslav Kysela <perex@...ex.cz>; Takashi Iwai
><tiwai@...e.com>; Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>;
>alsa-devel@...a-project.org; lkml <linux-kernel@...r.kernel.org>;
>ryan.lee.maxim@...il.com
>Subject: Re: [PATCH] ASoC: max98373: Added 10ms delay after amp software
>reset
>
>EXTERNAL EMAIL
>
>
>
>On Thu, Aug 23, 2018 at 10:51:07AM +0100, Mark Brown wrote:
>> On Wed, Aug 22, 2018 at 05:31:04PM -0700, Dmitry Torokhov wrote:
>> > On Wed, Aug 22, 2018 at 5:21 PM Ryan Lee
><ryans.lee@...imintegrated.com> wrote:
>> > > +       mdelay(10);
>>
>> > Is it really necessary for the CPU to spin for 10msec here?
>> > usleep_range() would be better solution.
>>
>> Or msleep() for that matter, it's not going ot be the end of the world
>> if we delay a bit too long.
>
>Frankly, I'd rather we did not introduce extra delays. I do not know if we use
>this part, but on ChromeOS we are interested in shaving as much from the boot
>time as possible and 10 msecs here and 10 msecs there do add up.

Thanks for all your feedback.
Let me apply usleep_range() or msleep() instead of using mdelay().

>
>Thanks.
>
>--
>Dmitry