Tommy Christensen [EMAIL PROTECTED] wrote:
John W. Linville wrote:
Any chance you could re-diff this to apply on top of the patch posted
earlier today by Neil Horman?
Sure, but his patch didn't apply to -git8.
If Neil would please resend, then I can diff against that.
Is OK, I'll
On Sep 9, 2005, at 05:10, Bogdan Costescu wrote:
On Thu, 8 Sep 2005, Andy Fleming wrote:
Is the cost of an extra read every minute really too high?
You probably didn't look at the code. The MII registers are not
exposed in the PCI space, they need to be accessed through a serial
On Wed, 7 Sep 2005, Jeff Garzik wrote:
The phy status register must be read twice in order to get the actual link
state.
Can the original poster give an explanation ? I've enjoyed a rather
well functioning 3c59x driver for the past ~6 years without such
double reading. Plus:
- this
On Thu, 2005-09-08 at 15:35, Bogdan Costescu wrote:
On Thu, 8 Sep 2005, Tommy Christensen wrote:
The idea is to avoid an extra delay of 60 seconds before detecting
link-up.
But you are adding the read to a function that is called repeatedly to
fix an event that happens only once at
On Thu, 8 Sep 2005, Tommy Christensen wrote:
Besides, how long would you like to wait for network connectivity
after plugging in the cable? It is now lowered from [60-120] to
[0-60] seconds.
I now understood what the problem was, so I'll put it in words for
posterity: the Link Status bit
On Sep 8, 2005, at 10:42, Bogdan Costescu wrote:
On Thu, 8 Sep 2005, Tommy Christensen wrote:
Personally, I'd prefer the delay to be 10 seconds.
If you sample every 60 seconds ? Teach Shannon how to do it ;-)
If you mean to reduce the sampling period, there is a very good
reason not
Bogdan Costescu wrote:
I now understood what the problem was, so I'll put it in words for
posterity: the Link Status bit of the MII Status register needs to be
read twice to first clear the error state (link bit=0) after which the
bit reports the actual value of the link. From the manual:
Tommy Christensen [EMAIL PROTECTED] wrote:
In order to spare some I/O operations, be more intelligent about
when to read from the PHY.
Seems sane.
Should we also decrease the polling interval? Perhaps only when the cable
is unplugged?
-
To unsubscribe from this list: send the line
Andrew Morton wrote:
Should we also decrease the polling interval? Perhaps only when the cable
is unplugged?
Sounds like a plan. 60 seconds certainly strikes me as being very slow.
OTOH, I'm not aware of the reasoning behind this choice in the first place.
It might make sense for some odd
Tommy Christensen wrote:
Andrew Morton wrote:
Should we also decrease the polling interval? Perhaps only when the
cable
is unplugged?
Sounds like a plan. 60 seconds certainly strikes me as being very slow.
OTOH, I'm not aware of the reasoning behind this choice in the first place.
It
10 matches
Mail list logo
