Michael Buesch wrote:
On Wednesday 28 June 2006 18:04, Larry Finger wrote:
Oh, well. Forget it all.
I remembered the code wrong.
At the moment I looked at the code and it has the opposite semantics.
It loops to wait for the READY bit to appear.
Well, I would say your old device simply takes this long
to disable and there is no bug.
Oh, well...
So the conclusion is that my card is really slow. As mine is likely to be the worst of the lot, I
propose the following structure for the loop in question:
for (i = 10000; i; i--) {
tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (tmp & BCM43xx_IRQ_READY) {
if (i < 9998)
printkl(KERN_INFO PFX "MAC suspend delay %d
usec, IRQ_REASON "
"0x%08x\n", 10000-i, tmp &
~BCM43xx_IRQ_READY);
goto out;
}
udelay(1);
}
printkl(KERN_ERR PFX "MAC suspend failed\n");
My maximum delay (so far) is 796 usec, thus this loop gives me a safety factor of more than 10, but
it should satisfy Jeff and let this patch in question be accepted. Of course, the 'if (i < 9998)'
statement with the printkl is optional. BTW, as you suspected, the IRQ_REASON value is still at
0x580 when the READY bit is set.
Thanks for the help,
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
