Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 1 Nov 2017 12:17:55 -0700 | Subject | Re: [RFC] Improving udelay/ndelay on platforms where that is possible |
| |
On Wed, Nov 1, 2017 at 12:09 PM, Linus Torvalds <torvalds@linux-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
| |