Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger <Larry.Finger@lwfinger.net>]

Jeff Garzik wrote:
> Michael Buesch wrote:
>>
>> 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