Re: ath5k: bad udelay call, build failure on ARM

["John W. Linville" <linville@tuxdriver.com>]

On Mon, Aug 25, 2008 at 02:57:15PM +0300, Martin Michlmayr wrote:
> ath5k fails to build on ARM with:
> 
> __bad_udelay is specifically designed on ARM to fail when udelay is
> called in a bad way.  arch/arm/include/asm/delay.h has this to say
> about __bad_udelay:
> 
> /*
>  * This function intentionally does not exist; if you see references to
>  * it, it means that you're calling udelay() with an out of range value.
>  *
>  * With currently imposed limits, this means that we support a max delay
>  * of 2000us. Further limits: HZ<=1000 and bogomips<=3355
>  */
> extern void __bad_udelay(void);
> 
> Can you check why your driver is calling udelay() with a value > 2000?

There are "udelay(2300)" calls in phy.c and hw.c.  How important is
that exact number?  Could those be replaced by mdelay(3) instead?

Of course, looking in include/linux/delay.h, mdelay(3) may still
translate to __bad_udelay on arm.  It would be nice if the ARM guys
and delay.h could at least agree on the maximum value allowed to be
passed to udelay...

John
-- 
John W. Linville
linville@tuxdriver.com