From: Andrew Lunn <andrew@lunn.ch>
To: Mason <slash.tmp@free.fr>
Cc: netdev <netdev@vger.kernel.org>,
Florian Fainelli <f.fainelli@gmail.com>,
David Miller <davem@davemloft.net>
Subject: Re: Waiting for the PHY to complete auto-negotiation
Date: Wed, 6 Dec 2017 17:59:03 +0100 [thread overview]
Message-ID: <20171206165903.GM27063@lunn.ch> (raw)
In-Reply-To: <e54cda57-6a7d-611e-89b9-0b3c9ea55cc1@free.fr>
On Wed, Dec 06, 2017 at 05:39:00PM +0100, Mason wrote:
> Hello,
>
> I've been trying to wrap my head around Ethernet auto-negotiation,
> vs actual / real packets seen at the MAC layer. I found the relevant
> Wikipedia article to be fairly informative:
>
> https://en.wikipedia.org/wiki/Autonegotiation
>
> The reason I care is that my Ethernet HW does not allow changing the
> flow control setting once the MAC has started (more specifically, once
> RX DMA has been enabled).
>
> In nb8800_open(), the code currently works in this order:
>
> nb8800_start_rx(dev);
> phy_start(phydev);
>
> The first line enables the MAC (and DMA).
> The second enables the PHY and starts auto-negotiation.
>
> This is a problem: I would like for PHY auto-negotiation to be
> /complete/ before I enable the MAC.
>
> What is the recommended way to wait for the PHY?
> AFAICT, the PHY layer calls back into the eth driver through the
> adjust_link() callback registered through of_phy_connect().
> It seems like this might be a good place to enable the MAC?
That probably works, but you might have a few corner cases to handle.
I'm not sure changes at the PHY always transition through down. So you
could for example get a callback saying the link is up, 1Gbps, then a
second call saying it has dropped to 100Mbps, if your
cables/connectors are bad.
If your hardware has problems, it might be safest to stop everything
in the callback, make configuration changes, and they start everything
back up. A link negotiation change is not something you expect to
happen often. So making it slow but robust is O.K.
Andrew
next prev parent reply other threads:[~2017-12-06 16:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 16:39 Waiting for the PHY to complete auto-negotiation Mason
2017-12-06 16:59 ` Andrew Lunn [this message]
2017-12-06 18:03 ` Mason
2017-12-06 18:26 ` Andrew Lunn
2017-12-06 19:00 ` Mason
2017-12-06 19:07 ` Andrew Lunn
2017-12-06 19:25 ` Mason
2017-12-06 23:00 ` Florian Fainelli
2017-12-07 16:17 ` Mason
2017-12-09 18:49 ` Florian Fainelli
2017-12-11 14:29 ` Mason
2017-12-11 14:36 ` Måns Rullgård
2017-12-11 14:47 ` Mason
2017-12-11 16:32 ` Måns Rullgård
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=20171206165903.GM27063@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=slash.tmp@free.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.