linux-kernel - RE: [PATCH 14/14] staging: comedi: daqboard2000: prefer 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]

Message-ID: <CO2PR01MB208896729967320E963F0350D0480@CO2PR01MB2088.prod.exchangelabs.com>
Date:	Tue, 17 May 2016 17:42:38 +0000
From:	Hartley Sweeten <HartleyS@...ionengravers.com>
To:	Ian Abbott <abbotti@....co.uk>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 14/14] staging: comedi: daqboard2000: prefer
 usleep_range()

On Tuesday, May 17, 2016 2:53 AM, Ian Abbott wrote:
> The checkpatch.pl warns about two `udelay(x)` calls, one of 100
> microseconds, and one of 10 microseconds.  The 100 microseconds one is
> used when waiting for FPGA to become ready to accept firmware, and is
> not that critical, so replace it with a call to `usleep_range(100,
> 1000)`.  The 10 microseconds one is called as each 16-bit word of
> firmware data is written.  A longer sleep would slow down firmware
> loading, so leave it alone.

The firmware blob in comedi-nonfree-firmware/daqboard2000 is
41236 bytes or 20618 words. With the 10 microsecond delay for
each word to total delay time is only 0.0206 seconds. I don't think a
small usleep_range() would slow down the firmware loading by much.
How about usleep_range(10, 20)?

Regards,
Hartley