Larry Finger wrote:
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?
That's acceptable, yes, but it sounds like the problem has since been cured?
Jeff
-
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
