From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org
Subject: Re: ethtool pause mode clarifications
Date: Fri, 13 Dec 2019 15:29:02 +0100 [thread overview]
Message-ID: <20191213142902.GB4286@lunn.ch> (raw)
In-Reply-To: <20191213114935.GR25745@shell.armlinux.org.uk>
On Fri, Dec 13, 2019 at 11:49:35AM +0000, Russell King - ARM Linux admin wrote:
> Hi,
>
> Please can someone explain the ethtool pause mode settings? The man
> page isn't particularly clear, it says:
>
> -A --pause
> Changes the pause parameters of the specified Ethernet device.
>
> autoneg on|off
> Specifies whether pause autonegotiation should be enabled.
>
> rx on|off
> Specifies whether RX pause should be enabled.
>
> tx on|off
> Specifies whether TX pause should be enabled.
>
>
> "autoneg" states whether pause autonegotiation should be enabled, but
> how is this possible, when pause autonegotiation happens as part of the
> rest of the autonegotiation as a matter of course, and the only control
> we have at the PHY is the value of the pause and asym pause bits?
Hi Russell
Yah, this is not clear. How i've interpreted it is:
autoneg on:
The driver should validate rx and tx with its capabilities, and then
tell the PHY what to advertise, kick off an auto-neg, and wait for the
result to program the MAC with the negotiated value.
If autoneg in general is off, return an error.
autoneg off:
Forget about the PHY, program the MAC directly, and potentially shoot
yourself in the foot. But it can be useful it auto-neg in general is
off, or there is no PHY.
> So, would it be possible to clarify what these settings mean in the
> ethtool man page please?
I suspect the first step would be to survey current implementations
and find out what is the most popular interpretation of this
text. Then expand the document, and maybe list some of the alternative
meanings which are currently in use?
Clearly, the more of this we can handle in phylink/phylib, the more
uniform it will be. But there is also a trend at the moment for
firmware to control the PHY, and it seems like a few MAC driver
writers have no idea what their firmware is actually doing with the
PHY for things like this.
Andrew
next prev parent reply other threads:[~2019-12-13 20:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 11:49 ethtool pause mode clarifications Russell King - ARM Linux admin
2019-12-13 14:29 ` Andrew Lunn [this message]
2019-12-13 15:12 ` Russell King - ARM Linux admin
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=20191213142902.GB4286@lunn.ch \
--to=andrew@lunn.ch \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
/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.