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

[Linus Torvalds]

On Wed, Nov 1, 2017 at 12:09 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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