Auke Kok wrote:
Francois Romieu wrote:
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of
iterations
- put the break on a line of its own
- add a Signed-off-by: Foo Bar <[EMAIL PROTECTED]> line
- Cc: [EMAIL PROTECTED] and Auke Kok <[EMAIL PROTECTED]>
I'm already checking out specs, which, for 8255x devices, are available
on http://e1000.sf.net/ .
okay, I don't think this is needed at all:
Allthough the spec itself didn't talk about phy reset times, I've ran this patch with
some debugging output on a few boxes and did some speed/duplex settings, and the PHY
reset returned succesfull after the very first mdio_read, which is before any msleep(10)
is executed. That is also expected behaviour.
I think you might be confusing this with a MAC reset, which has a documented 10usec
timeout (see 8255x developers manual). The driver already adheres to this by doing a
20usec delay after software/selective resets.
which gets us back to the original problem: how did your driver end up in loopback mode?
(and, how did you figure out that it did??).
Cheers,
Auke
-
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
