Larry Finger wrote:

Jeff Garzik wrote:

quoted

John W. Linville wrote:

quoted

+    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?

That's acceptable, yes, but it sounds like the problem has since been cured?

	Jeff