linux-kernel - Re: [RFC] Improving udelay/ndelay on platforms where that is possible

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: <alpine.DEB.2.20.1711012032080.1942@nanos>
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