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
| ||
|
Date: Wed, 1 Nov 2017 20:39:51 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: Marc Gonzalez <marc_gonzalez@...madesigns.com> cc: Alan Cox <gnomes@...rguk.ukuu.org.uk>, Linus Torvalds <torvalds@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>, John Stultz <john.stultz@...aro.org>, Douglas Anderson <dianders@...omium.org>, Nicolas Pitre <nico@...aro.org>, Mark Rutland <mark.rutland@....com>, Will Deacon <will.deacon@....com>, Jonathan Austin <jonathan.austin@....com>, Arnd Bergmann <arnd@...db.de>, Kevin Hilman <khilman@...nel.org>, Russell King <linux@....linux.org.uk>, Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...eaurora.org>, Mason <slash.tmp@...e.fr> Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible On Wed, 1 Nov 2017, Marc Gonzalez wrote: > On 01/11/2017 18:53, Alan Cox wrote: > > > On Tue, 31 Oct 2017 17:15:34 +0100 > > > >> Therefore, users are accustomed to having delays be longer (within a reasonable margin). > >> However, very few users would expect delays to be *shorter* than requested. > > > > If your udelay can be under by 10% then just bump the number by 10%. > > Except it's not *quite* that simple. > Error has both an absolute and a relative component. > So the actual value matters, and it's not always a constant. > > For example: > http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/nand_base.c#L814 That example is really pointless, because the only effect it does is to delay the read of the ready/busy pin long enough to bridge the silly gap between |----------------------- CS _____| and -------| R/B |_____________________ IIRC, the gap is in the low single digit nsec range, so it really does not matter how long you delay here. In fact on most older CPUs excuting the 3 instructions even if it returned immediately were sufficient. Any real NAND controller, not the stupid PIO based ones we had 15 years ago, should not even make it necessary to handle that on the software side. Simply because the controller should already take care of that and not blindly reflect the status of the R/B pin in the status register. If your hardware does that, then poke that HW dude on the desk next to yours with a big cluestick. Thanks, tglx
Powered by blists - more mailing lists