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

From: Pavel Machek <pavel@ucw.cz>
To: Doug Anderson <dianders@chromium.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Jonathan Austin <jonathan.austin@arm.com>,
	Arnd Bergmann <arnd@arndb.de>, Mason <slash.tmp@free.fr>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Nicolas Pitre <nico@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible
Date: Thu, 7 Dec 2017 13:31:36 +0100	[thread overview]
Message-ID: <20171207123136.GB24547@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <CAD=FV=VKEz9jvJaD2KTitH=2G+wb42RXHyRVKi4-zrypAu9jSA@mail.gmail.com>

Hi!

> On Wed, Nov 1, 2017 at 2:26 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds
> >> <torvalds@linux-foundation.org> wrote:
> >> > So I'm very much open to udelay improvements, and if somebody sends
> >> > patches for particular platforms to do particularly well on that
> >> > platform, I think we should merge them. But ...
> >>
> >> If I'm reading this all correctly, this sounds like you'd be willing
> >> to merge <https://patchwork.kernel.org/patch/9429841/>.  This makes
> >> udelay() guaranteed not to underrun on arm32 platforms.
> >
> > That's a mis-representation again.  It stops a timer-based udelay()
> > possibly underrunning by one tick if we are close to the start of
> > a count increment.  However, it does nothing for the loops_per_jiffy
> > udelay(), which can still underrun.
> >
> > My argument against merging that patch is that with it merged, we get
> > (as you say) a udelay() that doesn't underrun _when using a timer_
> > but when we end up using the loops_per_jiffy udelay(), we're back to
> > the old problem.
> >
> > My opinion is that's bad, because it encourages people to write drivers
> > that rely on udelay() having "good" behaviour, which it is not guaranteed
> > to have.  So, they'll specify a delay period of exactly what they want,
> > and their drivers will then fail when running on systems that aren't
> > using a timer-based udelay().
> 
> IMHO the current udelay is broken in an off-by-one way and it's easy
> to fix.  Intentionally leaving a bug in the code seems silly.  This
> seems to by what Linus is saying with his statement that "(a) platform
> code could try to make their udelay/ndelay() be as good as it can be
> on a particular platform".
> 
> So no matter the rest of the discussions, we should land that.  If you
> disagree then I'm happy to re-post that patch straight to Linus later
> this week since it sounds as if he'd take it.

Did this get fixed in any way? Russell having crazy arguments for
keeping kernel buggy should not be good enough reason to keep the
bugs...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html