[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81DAD951-0909-4D3A-8451-AEE3F9B07054@boeing.com>
Date: Fri, 27 Aug 2010 15:51:58 -0500
From: "Moffett, Kyle D" <Kyle.D.Moffett@...ing.com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kyle Moffett <kyle@...fetthome.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] sky2: Add unidirectional fiber link support
On Aug 27, 2010, at 16:38, Stephen Hemminger wrote:
> On Fri, 27 Aug 2010 15:42:18 -0400 Kyle Moffett <Kyle.D.Moffett@...ing.com> wrote:
>> + /*
>> + * Once interrupts are reenabled, reset the PHY again to make sure
>> + * that we didn't miss a link-up interrupt. This is especially
>> + * likely to occur if we're in fiber-txonly mode, as a link-up
>> + * interrupt is generated almost immediately after we finish
>> + * programming the PHY.
>> + */
>> + sky2_phy_reinit(sky2);
>
> Won't this cause a renegotiation causing up to 2 second delay?
Well, I suppose that's possible, but we've only just reset and enabled the PHY moments before, so I don't see where you could get an *extra* 2-second delay. On the other hand, I suppose it would be much nicer if there was an easy way to fake an extra interrupt there instead of reinitializing the whole PHY. I'm not all that comfortable with my understanding of the interrupt logic in the sky2 driver, so I figured I would just reuse all the necessary locking from sky2_phy_reinit().
Do you have any comments or criticisms of the particular "duplex" method of configuring the unidirectional link support?
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists