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

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

Jeff Garzik wrote:
> John W. Linville wrote:
>> +    assert(bcm->mac_suspended >= 0);
>> +    if (bcm->mac_suspended == 0) {
>> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
>> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
>> +                        bcm43xx_read32(bcm, 
>> BCM43xx_MMIO_STATUS_BITFIELD)
>> +                & ~BCM43xx_SBF_MAC_ENABLED);
>> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
>> read */
>> +        for (i = 100000; i; i--) {
>> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
>> +            if (tmp & BCM43xx_IRQ_READY)
>> +                goto out;
>> +            udelay(10);
>> +        }
>> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
>>      }
> 
> 
> NAK this super-long delay...  should be done in a workqueue, looks like?
> 
> ACK everything else.
> 

That delay was set to try to accommodate my interface when it refused to suspend the MAC, which 
resulted in transmit errors. That problem has since been cured by reworking the periodic work 
handlers - thus such a long delay should not be needed. The original spec from the clean-room group 
was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for 
(i=1000; i; i--) be acceptable?

Larry