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

On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:

On Wed, 2014-02-05 at 11:50 +0000, Russell King - ARM Linux wrote:

quoted

On Tue, Feb 04, 2014 at 08:36:36AM -0800, Joe Perches wrote:

quoted

On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:

quoted

Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
cannot handle large values because of lost-of-precision.

IMHO udelay on ARM is broken, because it also cannot work with fast
ARM processors (where bogomips >= 3355, which is in sight now). It's
just not broken enought that someone did something against it ...   so
the current kludge is good enought.

Maybe something like this would be better?

No, the point of __bad_udelay() is that people doing stupidly large
udelay()s result in build errors,

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.

Perhaps there should be some runtime udelay > maximum supported check.

Having both a runtime check _and_ a compile time check would actually
be a good thing, but any runtime check needs to be suitably rate-
limited.

The compile time check is very important because it catches a lot of
cases which wouldn't otherwise be found (eg, in drivers which hardly
anyone uses on ARM.)

Maybe the compile time check should be something which is implemented
in a cross-architecture way in linux/delay.h with the maximum set to
the lowest that any architecture can do?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".