Jeff Garzik wrote:

Michael Buesch wrote:

quoted

Short: Don't touch it. Fullstop.

Long: The delay will _never_ be exhausted. Actually the for-counter
is only there to not lock up the machine, if there is a Bug in the
driver. (__much__ easier debugging).
The loop will only iterate a few times, typically.
Actually, _if_ we want to change something, we should do this:

for (i = 1000000; i; i--) {
    ...
    udelay(1);
}

(max loop multiplied by 10, delay value divided by 10).
This will shorten the whole delay by a few usecs (up to 10).
I will send a patch for this, if it is desired.

But lowering the loop counter value is NACKed by me,
because it simply does not make sense.

My overriding concern was that this type of loop spins the CPU at 100% 
until the hardware condition is satisfied, which starves all other 
kernel work on that CPU, and is very unfriendly to power consumption 
(though I believe monitor/mwait/cpu_relax helps on x86).

Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
grepping for udelay in bcm43xx_radio.c shows some of the worst 
offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
both look like candidates for using msleep() rather than udelay().

It is not my place to get into the middle of this discussion; however, my interface has been pinging 
my AP for over 12 hours with the loop counter starting at 1000. I get the usual log entries for the 
hourly TKIP changes, but no MAC suspend failures.

Larry