On 4/27/06, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > + if (startup) {
> > + int timeout = 10; /* max 1 ms */
> > for (i = 0; i < reset_length; i++)
> >
> > iowrite32(get_u16(&reset_sequence[i]) << 16, ioaddr + CSR15);
> > +
> > + /* flush posted writes */
> > + ioread32(ioaddr + CSR15);
> > +
> > + /* Sect 3.10.3 in DP83840A.pdf (p39)
> > */
> > + udelay(500);
> > +
> > + /* Section 4.2 in DP83840A.pdf (p43)
> > */
> > + /* and IEEE 802.3 "22.2.4.1.1 Reset"
> > */
> > + while (timeout-- &&
> > + (tulip_mdio_read (dev,
> > phy_num, MII_BMCR) & BMCR_RESET))
> > + udelay(100);
>
>
> What can we do about this?
>
> Its a huge delay to be taken inside a spinlock.
This is device setup code. ISTR Grant showing other similar examples
of delays in such code in the kernel. Unless you keep
configuring/deconfiguring the device, and assuming you hit worst case
scenario everytime, it won't be a problem. But if you're doing that,
you already have a problem elsewhere. Or am I missing something?
> Anybody interested to converting the driver to use schedule_work() or
> similar?
That question has been raised months ago without any significant
outcome. Maybe it's time to move on? This code does respect hardware
specs, at least, which isn't the case of existing code, and fixes a
bug...
HTH
T-Bone
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
-
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
