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?
--
Martin Michlmayr
http://www.cyrius.com/
2008/8/25 John W. Linville <[email protected]>:
> 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
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
[email protected]
* John W. Linville <[email protected]> [2008-08-25 15:08]:
> 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.
mdelay(3) compiles on ARM, so replacing the udelay(2300) with
mdelay(3) might be an option. (I don't have the hardware to test
though.)
--
Martin Michlmayr
http://www.cyrius.com/
2008/9/10 Martin Michlmayr <[email protected]>:
> * Nick Kossifidis <[email protected]> [2008-08-25 22:36]:
>> > 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.
>
> Did you have a chance to do these tests yet?
Next week i hope, sorry for the delay ;-(
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
* Nick Kossifidis <[email protected]> [2008-08-25 22:36]:
> > 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.
Did you have a chance to do these tests yet?
--
Martin Michlmayr
http://www.cyrius.com/