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
proto
On Fri, Sep 09, 2005 at 12:44:06AM -0700, Andrew Morton wrote:
> 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
On Thu, 8 Sep 2005, Andy Fleming wrote:
The new PHY Layer (drivers/net/phy/*) can provide all these features
for you without much difficulty, I suspect.
As pointed to be Andrew a few days ago, this driver supports a lot of
chips - for most of them the test hardware would be hard to come by
a
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
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.
-Tommy
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, Sep 09, 2005 at 12:39:18AM +0200, Tommy Christensen wrote:
> --- linux-2.6.13-git8/drivers/net/3c59x.c-origFri Sep 9 00:05:49 2005
> +++ linux-2.6.13-git8/drivers/net/3c59x.c Fri Sep 9 00:13:55 2005
> @@ -1889,7 +1889,9 @@ vortex_timer(unsigned long data)
> {
>
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 might
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 setu
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 "unsu
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:
Yes
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 t
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 of
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 on
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 start-up !
If this read is really needed (I still doubt it..
On Thu, 2005-09-08 at 13:58, Bogdan Costescu wrote:
> 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 operation is I/O expensive
> - it is performed inside a region protected by
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 operatio
0700
[PATCH] 3c59x: read current link status from phy
The phy status register must be read twice in order to get the actual link
state.
Signed-off-by: Tommy S. Christensen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTEC
17 matches
Mail list logo
