Re: [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Russell King - ARM Linux <hidden>
Date: 2014-02-05 13:39:56
Also in:
linux-arm-kernel
On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote:
quoted hunk ↗ jump to hunk
On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:quoted
On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:quoted
Apparently, people just convert stupidly large udelay()s to mdelay and not be bothered.And that's the correct answer. Having udelay(10000) rather than mdelay(10) is a sign that they weren't paying that much attention when writing the code.Not really. Look at the code that brought this up in the first place. On Tue, 2014-02-04 at 08:37 +0530, Sujith Manoharan wrote:quoted
From: Sujith Manoharan <redacted> Use mdelay instead of udelay to fix this error: ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined![]diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c[]quoted
@@ -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);quoted
if (AR_SREV_9300_20_OR_LATER(ah)) udelay(50); else if (AR_SREV_9100(ah)) - udelay(10000); + mdelay(10); else udelay(100);One chip needs a larger delay than the others. It's not so much not paying attention as not knowing ARM is broken for large udelay().
And now read my suggestion about how to avoid the "not knowing" problem. :) -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".