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: <CA+55aFx86WR3wFibq6MUtSCvVG9Ty-m=tAFh0XHSfu192fFeiA@mail.gmail.com>
Date:   Wed, 1 Nov 2017 12:17:55 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Marc Gonzalez <marc_gonzalez@...madesigns.com>
Cc:     Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        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, Nov 1, 2017 at 12:09 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Yes, there is a *fallback* for when somebody doesn't do ndelay() at
> all, but that doesn't make it the default.
>
> It's just a "the architecture didn't implement ndelay at all, we'll
> work around it".

Side  note: I will continue to claim that anybody who thinks they need
ndelay() needs to rethink their position anyway, due to all the issues
I did already bring up.

So I'd say that pretty much 100% of all ndelay() users are just wrong.
If you are doing a driver that needs that kind of delay granularity,
you had better already know exactly how long it takes to read the
status register, and just do that instead.

And if you don't know how long it takes to read a status register, you
have no business thinking that you need ndelay(). You probably ended
up reading one piece of hardware doc ("the sample-and-hold register
takes 200ns to settle") without then reading the other low-level
hardware documentation that talks about the timings of the chip
accesses from the host side.

                 Linus