bcm57xx: bound how long an MI transaction is waited for

phy_read waits for MICOMM_BUSY to clear by reading MI_COMM back to back,
up to 5000 times. A bound in reads is not a bound in time - tg3 allows
5000 tries for the same wait, with a 10 us delay between them, so fifty
milliseconds - but neither is a problem while the interface answers. What
matters is the ceiling when it does not.

That ceiling is now 1000 reads. A frame is 64 bit times, about 26 us at
the standard 2.5 MHz MI clock, and the reads go out back to back, so a
thousand of them is a few hundred microseconds even on a PCI Express
card, an order of magnitude above the transaction they are waiting for.
What the bound buys is the worst case: check_link reads the PHY two or
three times, and from a link attention those reads happen in the
interrupt handler with interrupts off, so an interface that has stopped
answering used to cost ten to fifteen milliseconds there. It now costs
about one.

The MI interface stopping to answer has not been observed; this is the
ceiling being set deliberately rather than inherited.

Assisted-by: ZCode:deepseek-flash

drivers/ethernet/bcm57xx.asm

@@ -2649,7 +2649,13 @@ phy_read:
         or      eax, MICOMM_CMD_READ or MICOMM_BUSY or (PHY_ADDR shl MICOMM_PHY_SHIFT)
         mov     [esi + MI_COMM], eax
 
-        mov     ecx, 5000
+; A frame is 64 bit times, about 26 us at the standard 2.5 MHz MI clock,
+; and the loop below reads back to back, so a thousand tries is a few
+; hundred microseconds even on PCI Express - out of all proportion to the
+; transaction. It is also the ceiling on how long a dead MI interface can
+; hold a caller, and from a link attention that caller is the interrupt
+; handler with interrupts off, so the count stays this low.
+        mov     ecx, 1000
   .wait:
         mov     eax, [esi + MI_COMM]
         test    eax, MICOMM_BUSY