On 3/27/06, J.A. Magallon <[email protected]> wrote:
> Corrected:
>
> --- linux/drivers/net/e100.c.orig 2006-01-24 09:20:44.000000000 +0100
> +++ linux/drivers/net/e100.c 2006-01-24 09:21:55.000000000 +0100
> @@ -884,10 +884,10 @@
> * procedure it should be done under lock.
> */
> spin_lock_irqsave(&nic->mdio_lock, flags);
> - for (i = 100; i; --i) {
> + for (i = 1000; i; --i) {
> if (readl(&nic->csr->mdi_ctrl) & mdi_ready)
> break;
> - udelay(20);
> + udelay(2);
what is the purpose of this patch? what bug is it solving? Are we
trying to achieve some goal? A comment at the very least is
necessary. I don't like changing timing stuff unless we have some
clear reason. In fact I sent a patch a while back to a guy who was
complaining about latency in a -RT kernel with e100 and he said this
kind of change made things worse: see the end of:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113808831932769&w=2
The problem in this case is the mii library calling back into our
mdio_read. eepro100's mdio read hard spins with no delay besides the
ioread32 delay created by reading from an i/o port. This could
explain the glitching in an RT kernel.
Is this the kind of problem this patch tries to solve?
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
