From: "Allan W. Nielsen" <allan.nielsen@microsemi.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: <netdev@vger.kernel.org>, <f.fainelli@gmail.com>,
<raju.lakkaraju@microsemi.com>
Subject: Re: [PATCH net-next 1/3] ethtool: (uapi) Add ETHTOOL_PHY_LOOPBACK to PHY tunables
Date: Mon, 28 Nov 2016 20:23:06 +0100 [thread overview]
Message-ID: <20161128192306.GA11474@microsemi.com> (raw)
In-Reply-To: <20161128141410.GF4379@lunn.ch>
Hi Andrew and Florian,
On 28/11/16 15:14, Andrew Lunn wrote:
> On Mon, Nov 28, 2016 at 02:24:30PM +0100, Allan W. Nielsen wrote:
> > From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> >
> > 3 types of PHY loopback are supported.
> > i.e. Near-End Loopback, Far-End Loopback and External Loopback.
> Is this integrated with ethtool --test? You only want the PHY to go
> into loopback mode when running ethtool --test external_lb or maybe
> ethtool --test offline.
There are other use-cases for enabling PHY loopback:
1) If the PHY is connected to a switch then a loop-port is sometime
used to "force/enable" one or more extra pass through the switch
core. This "hack" can sometime be used to achieve new functionality
with existing silicon.
2) Existing user-space application may expect to be able to do the
testing on its own (generate/validate the test traffic).
> What i think should happen is that this tunable sets the mode the
> PHY will go into when loopback is enabled. It does not however
> enable loopback.
That does not make a lot of sense with the "FAR" loopback (it is
looping received traffic back into the wire).
> It is running ethtool --test which actually enables
> the loopback, probably by setting BMCR_LOOPBACK. Once the test is
> finished, the bit is cleared and the PHY goes back into normal
> operation.
We are always happy to integrate with any existing functionality, but
as I understand "ethtool --test" then intention is to perform a test
and then bring back the PHY in to a "normal" state (I may be
wrong...).
The idea with this patch is to allow configuring loopback more
"permanently" (userspace can decide when to activate and when to
de-activate). I should properly have made that clear in the cover
letter.
Please let me know what you think.
/Allan
next prev parent reply other threads:[~2016-11-28 19:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-28 13:24 [PATCH net-next 0/3] Adding PHY Loopback tunable Allan W. Nielsen
2016-11-28 13:24 ` [PATCH net-next 1/3] ethtool: (uapi) Add ETHTOOL_PHY_LOOPBACK to PHY tunables Allan W. Nielsen
2016-11-28 14:14 ` Andrew Lunn
2016-11-28 17:59 ` Florian Fainelli
2016-11-28 19:23 ` Allan W. Nielsen [this message]
2016-11-28 20:21 ` Andrew Lunn
2016-11-28 21:01 ` Florian Fainelli
2016-11-29 0:46 ` Andrew Lunn
2016-11-29 15:32 ` Allan W. Nielsen
2016-11-28 13:24 ` [PATCH net-next 2/3] ethtool: Core impl for ETHTOOL_PHY_LOOPBACK tunable Allan W. Nielsen
2016-11-28 13:24 ` [PATCH net-next 3/3] net: phy: Add Loopback support in Microsemi PHYs driver Allan W. Nielsen
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=20161128192306.GA11474@microsemi.com \
--to=allan.nielsen@microsemi.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=raju.lakkaraju@microsemi.com \
/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;
as well as URLs for NNTP newsgroup(s).