ath9k ARM build error with v3.13-8330-g4ba9920

3 messages, 2 authors, 2014-01-27 · open the first message on its own page

ath9k ARM build error with v3.13-8330-g4ba9920

From: Josh Boyer <hidden>
Date: 2014-01-26 15:59:50

Hi All,

This commit:

commit 4dc78c437a0a2ac152a2b2c5e91a814a6ef3599e
Author: Sujith Manoharan [off-list ref]
Date:   Wed Dec 18 09:53:26 2013 +0530

    ath9k: Fix RTC reset delay

    The delay that is required after issuing a RTC reset
    varies for each chip. Handle this properly.

    Signed-off-by: Sujith Manoharan [off-list ref]
    Signed-off-by: John W. Linville [off-list ref]

adds a udelay(10000) call to the ath9k driver.  This will cause a
build error on various ARM configs because the value passed to udelay
is too large:

ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Is the 10000 microsecond udelay really required?  I believe the limit
on ARM is 2000.  Perhaps something else could be done in this case?

josh

Re: ath9k ARM build error with v3.13-8330-g4ba9920

From: Sujith Manoharan <hidden>
Date: 2014-01-27 01:55:48

Josh Boyer wrote:
adds a udelay(10000) call to the ath9k driver.  This will cause a
build error on various ARM configs because the value passed to udelay
is too large:

ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Is the 10000 microsecond udelay really required?  I believe the limit
on ARM is 2000.  Perhaps something else could be done in this case?
The delay is a workaround for a HW issue. Does this patch fix the problem ?
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index fbf43c0..11eab9f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type)
 	if (AR_SREV_9300_20_OR_LATER(ah))
 		udelay(50);
 	else if (AR_SREV_9100(ah))
-		udelay(10000);
+		mdelay(10);
 	else
 		udelay(100);
 
@@ -2051,9 +2051,8 @@ static bool ath9k_hw_set_power_awake(struct ath_hw *ah)
 
 	REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
 		    AR_RTC_FORCE_WAKE_EN);
-
 	if (AR_SREV_9100(ah))
-		udelay(10000);
+		mdelay(10);
 	else
 		udelay(50);
 
Sujith

Re: ath9k ARM build error with v3.13-8330-g4ba9920

From: Josh Boyer <hidden>
Date: 2014-01-27 15:10:28

On Sun, Jan 26, 2014 at 8:50 PM, Sujith Manoharan [off-list ref] wrote:
Josh Boyer wrote:
quoted
adds a udelay(10000) call to the ath9k driver.  This will cause a
build error on various ARM configs because the value passed to udelay
is too large:

ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Is the 10000 microsecond udelay really required?  I believe the limit
on ARM is 2000.  Perhaps something else could be done in this case?
The delay is a workaround for a HW issue. Does this patch fix the problem ?
It fixes the build error, yes.  I don't have actual HW to test, but
the driver compiles on ARM now with the same config as before.
Thanks!

josh
quoted hunk
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index fbf43c0..11eab9f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type)
        if (AR_SREV_9300_20_OR_LATER(ah))
                udelay(50);
        else if (AR_SREV_9100(ah))
-               udelay(10000);
+               mdelay(10);
        else
                udelay(100);
@@ -2051,9 +2051,8 @@ static bool ath9k_hw_set_power_awake(struct ath_hw *ah)

        REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
                    AR_RTC_FORCE_WAKE_EN);
-
        if (AR_SREV_9100(ah))
-               udelay(10000);
+               mdelay(10);
        else
                udelay(50);

Sujith
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help