From: Peter Tyser Date: Wed, 25 Feb 2009 14:30:23 -0600 Subject: [U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link In-Reply-To: <20090210173124.GA6698@ld0162-tx32.am.freescale.net> References: <1233782045-488-1-git-send-email-ptyser@xes-inc.com> <2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae@mail.gmail.com> <20090204212632.07F0D8322908@gemini.denx.de> <2acbd3e40902041507s2b02516cgb5e685e9843bb7eb@mail.gmail.com> <1233851271.6434.2066.camel@localhost.localdomain> <498C3BDE.3020102@ge.com> <2acbd3e40902061049ub9d2b6r72ac1010f918a60f@mail.gmail.com> <498C8FCE.8020807@ge.com> <2acbd3e40902091656n2b4c07b9mb3d11621f01a55d@mail.gmail.com> <4991882F.4070206@ge.com> <20090210173124.GA6698@ld0162-tx32.am.freescale.net> Message-ID: <1235593823.12407.50.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Sorry for the delayed response, On Tue, 2009-02-10 at 11:31 -0600, Scott Wood wrote: > On Tue, Feb 10, 2009 at 08:59:11AM -0500, Jerry Van Baren wrote: > > That is my reasoning behind my statement that we can generally ignore > > the autonegotiation <-> fixed configuration case because the odds of it > > working properly are poor anyway. > > I'm not fond of giving up any ability to support a configuration just > because some people get it wrong (including configurations where the > human *can't* screw it up because the fixed end is some old hub or NIC > that doesn't support anything other than 10Mbit, half-duplex), especially > when the benefit of not supporting it is so low. > > > Having said all that, I don't have any problem with using 3.5 seconds as > > the safe timeout value. it isn't worth timing out too soon just to > > shave 0.5 or even 1.0 seconds off the negotiation timeout time. > > OK, good. :-) I agree, I'd prefer to err on the conservative side too. The spec Jerry mentioned was for a 100M PHY. I'm guessing it could take longer for a 1000M PHY... I've looked around a fair bit and couldn't find anything concrete either. I see a few references to a 4.5 second autonegotiation timeout in the Linux kernel (e1000 and e1000e drivers), but of course no mention of where those numbers came from. I see timeout values of 4 and 5 seconds in U-Boot also. What if I keep this patch as is, then submit an additional patch which would replace all PHY_AUTONEGOTIATE_TIMEOUT references with CONFIG_SYS_PHY_AUTONEG_TIMEOUT. A conservative default value of 4.5 seconds would be assigned to CONFIG_SYS_AUTONEG_TIMEOUT in net.h, but this could be overridden by board config files if wanted/needed? Thanks, Peter