ath5k: bad udelay call, build failure on ARM

ath5k: bad udelay call, build failure on ARM

[Martin Michlmayr]

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/

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

[John W. Linville]

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

Re: [ath5k-devel] ath5k: bad udelay call, build failure on ARM

[Nick Kossifidis]

2008/8/25 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

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

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

[Martin Michlmayr]

* John W. Linville <linville@tuxdriver.com> [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/

Re: [ath5k-devel] ath5k: bad udelay call, build failure on ARM

[Martin Michlmayr]

* Nick Kossifidis <mickflemm@gmail.com> [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/

Re: [ath5k-devel] ath5k: bad udelay call, build failure on ARM

[Nick Kossifidis]

2008/9/10 Martin Michlmayr <tbm@cyrius.com>:
> * Nick Kossifidis <mickflemm@gmail.com> [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