From: Heiko Stuebner <heiko@sntech.de>
To: linux-rockchip@lists.infradead.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
Douglas Anderson <dianders@chromium.org>,
huangtao@rock-chips.com, briannorris@chromium.org,
linux-kernel@vger.kernel.org, Andreas Mohr <andi@lisas.de>,
tony.xie@rock-chips.com, John Stultz <john.stultz@linaro.org>
Subject: Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process()
Date: Tue, 11 Oct 2016 22:34:55 +0200 [thread overview]
Message-ID: <147626835.p3yipu2Yfe@phil> (raw)
In-Reply-To: <alpine.DEB.2.20.1610110908240.7794@nanos>
Am Dienstag, 11. Oktober 2016, 09:14:38 CEST schrieb Thomas Gleixner:
> On Mon, 10 Oct 2016, Douglas Anderson wrote:
> > Users of usleep_range() expect that it will _never_ return in less time
> > than the minimum passed parameter. However, nothing in any of the code
>
> > ensures this. Specifically:
> There is no such guarantee for that interface and never has been, so how
> did you make sure that none of the existing users is relying on this?
>
> You can't just can't just declare that all all of the users expect that and
> be done with it.
It may be my personal ignorance for not finding this explained, but the
function documentation [0] states "min ... Minimum time in usecs to sleep"
which sounds pretty guaranteed to me.
One should of course make sure to not break anything intentionally, but having
things expect to work outside these parameters sounds somewhat broken
If the specified values are flexible beyond their stated range, I guess the
documentation should be updated to reflect that.
[0] https://www.kernel.org/doc/htmldocs/device-drivers/API-usleep-range.html
next prev parent reply other threads:[~2016-10-11 20:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 21:04 [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Douglas Anderson
2016-10-10 22:39 ` Doug Anderson
2016-10-11 7:14 ` Thomas Gleixner
2016-10-11 16:33 ` Doug Anderson
2016-10-12 8:56 ` Mark Brown
2016-10-11 18:25 ` Andreas Mohr
2016-10-12 13:11 ` Thomas Gleixner
2016-10-12 17:39 ` Doug Anderson
2016-10-11 20:34 ` Heiko Stuebner [this message]
2016-10-11 18:54 ` Brian Norris
2016-10-11 19:30 ` Andreas Mohr
2016-10-11 20:02 ` Doug Anderson
2016-10-11 20:40 ` Andreas Mohr
2016-10-12 16:03 ` [v2] " Guenter Roeck
2016-10-12 16:27 ` Doug Anderson
2016-10-12 16:53 ` Guenter Roeck
2016-10-18 13:44 ` [PATCH v2] " Daniel Kurtz
2016-10-18 20:29 ` Doug Anderson
2016-10-20 8:57 ` Daniel Kurtz
2016-10-20 9:51 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=147626835.p3yipu2Yfe@phil \
--to=heiko@sntech.de \
--cc=andi@lisas.de \
--cc=briannorris@chromium.org \
--cc=dianders@chromium.org \
--cc=huangtao@rock-chips.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=tglx@linutronix.de \
--cc=tony.xie@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox