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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
