2008/8/25 John W. Linville [off-list ref]:

On Mon, Aug 25, 2008 at 02:57:15PM +0300, Martin Michlmayr wrote:

quoted

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

Sorry for that i just haven't tested 5210 code much (these are older
chips that need more delay). I'll do some tests asap and tweak this
value to be in range.



-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick