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@xxxxxxxxxxxxx -- 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
