2011/11/20 Felix Fietkau <nbd@xxxxxxxxxxx>: > On 2011-11-20 8:56 AM, Nick Kossifidis wrote: >> Use usleep_range where possible to reduce busy waits >> >> Signed-off-by: Nick Kossifidis <mickflemm@xxxxxxxxx> >> --- >> drivers/net/wireless/ath/ath5k/attach.c | 2 +- >> drivers/net/wireless/ath/ath5k/pci.c | 2 +- >> drivers/net/wireless/ath/ath5k/phy.c | 22 +++++++++++----------- >> drivers/net/wireless/ath/ath5k/reset.c | 14 +++++++------- >> 4 files changed, 20 insertions(+), 20 deletions(-) >> >> @@ -1454,7 +1454,7 @@ static int ath5k_hw_rf5110_calibrate(struct ath5k_hw *ah, >> beacon = ath5k_hw_reg_read(ah, AR5K_BEACON_5210); >> ath5k_hw_reg_write(ah, beacon & ~AR5K_BEACON_ENABLE, AR5K_BEACON_5210); >> >> - mdelay(2); >> + usleep_range(2000, 2500); >> >> /* >> * Set the channel (with AGC turned off) >> @@ -1467,7 +1467,7 @@ static int ath5k_hw_rf5110_calibrate(struct ath5k_hw *ah, >> * Activate PHY and wait >> */ >> ath5k_hw_reg_write(ah, AR5K_PHY_ACT_ENABLE, AR5K_PHY_ACT); >> - mdelay(1); >> + usleep_range(1000, 1500); >> >> AR5K_REG_DISABLE_BITS(ah, AR5K_PHY_AGC, AR5K_PHY_AGC_DISABLE); >> > Are you sure this is safe? This looks like it's being called from > tasklet context, and I think usleep_range is not allowed there. > > - Felix > Reset runs in process context. Calls to reset are done directly from non-interrupt context (e.g. during init) or through a work queue, not a tasklet. They are also locked using a mutex lock, not a spinlock so we should be fine. I did a few tests to be on the safe side and run this on a multi-core system with an AR2425 with no problems/deadlocks or anything. -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick -- 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
