2008/8/25 John W. Linville <linville@xxxxxxxxxxxxx>: > 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
