[ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM

From
Joe Perches <joe@perches.com>
Date
2014-02-05 15:05:15
Also in
linux-wireless
Reply to
Russell King - ARM Linux, 2014-02-05
On Wed, 2014-02-05 at 14:21 +0000, Russell King - ARM Linux wrote:
On Wed, Feb 05, 2014 at 06:03:13AM -0800, Joe Perches wrote:
quoted
On Wed, 2014-02-05 at 13:39 +0000, Russell King - ARM Linux wrote:
quoted
On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote:
quoted
On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:
quoted
On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
quoted
Apparently, people just convert stupidly large udelay()s
to mdelay and not be bothered.
And that's the correct answer.  Having udelay(10000) rather than mdelay(10)
is a sign that they weren't paying that much attention when writing the
code.
Not really.
[]
quoted
quoted
It's not so much not paying attention as not
knowing ARM is broken for large udelay().
And now read my suggestion about how to avoid the "not knowing" problem. :)
I'd read it already.  I didn't and don't disagree.
Please explain /why/ you don't agree.
Please reread what I wrote.

We agree a lot more than you seem to think.
quoted
I still think adding a #warning on large static udelay()s
would be sensible.  Maybe adding another option like
#define UDELAY_TOO_BIG_I_KNOW_ALREADY_DONT_BOTHER_ME
guard to avoid seeing the #warning when there's no other
option.
How does that help?  It's /not/ a warning situation - if you ask for
udelay(10000) on ARM, you will /not/ get a 10ms delay.  You'll instead
get something much shorter because the arithmetic will overflow.
Now, you could argue that maybe ARM's udelay() implementation should
know about this and implement a loop around the underlying udelay()
implementation to achieve it,
I suggested something like that was possible.
and I might agree with you - but I
don't for one very simple reason: we /already/ have such an
implementation.  It's called mdelay():
I think mdelay should be for the case where the range
is too big for a udelay.  I think arm's 11 bit range
is unfortunately small.

I think we agree be nice to get a generic compiler
#warning when a __builtin_constant_p value is too large
and a ratelimited dmesg/warning for the runtime case.
Thread (11 messages) 11 messages, 3 authors, last reply 2014-02-05
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help