From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link
Date: Wed, 25 Feb 2009 14:30:23 -0600 [thread overview]
Message-ID: <1235593823.12407.50.camel@localhost.localdomain> (raw)
In-Reply-To: <20090210173124.GA6698@ld0162-tx32.am.freescale.net>
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
next prev parent reply other threads:[~2009-02-25 20:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 21:14 [U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link Peter Tyser
2009-02-04 21:20 ` Andy Fleming
2009-02-04 21:26 ` Wolfgang Denk
2009-02-04 21:45 ` Peter Tyser
2009-02-04 23:07 ` Andy Fleming
2009-02-05 16:27 ` Peter Tyser
2009-02-06 13:32 ` Jerry Van Baren
2009-02-06 18:49 ` Andy Fleming
2009-02-06 19:30 ` Jerry Van Baren
2009-02-10 0:56 ` Andy Fleming
2009-02-10 13:59 ` Jerry Van Baren
2009-02-10 17:31 ` Scott Wood
2009-02-25 20:30 ` Peter Tyser [this message]
2009-02-04 21:49 ` Scott Wood
2009-02-04 21:58 ` Wolfgang Denk
2009-02-04 22:00 ` Scott Wood
2009-02-04 22:19 ` Wolfgang Denk
2009-02-06 13:16 ` Jerry Van Baren
2009-02-06 17:16 ` Ben Warren
2009-07-19 20:14 ` Peter Tyser
2009-08-04 22:50 ` Peter Tyser
2009-08-21 17:04 ` Peter Tyser
2009-08-21 17:35 ` Ben Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1235593823.12407.50.camel@localhost.localdomain \
--to=ptyser@xes-inc.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox