From: Guenter Roeck <linux@roeck-us.net>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>,
linux-kernel@vger.kernel.org
Subject: Re: [RFT PATCH 1/2] net: dsa: mv88e6xxx: Add EEE support
Date: Mon, 23 Feb 2015 10:52:45 -0800 [thread overview]
Message-ID: <20150223185245.GB23456@roeck-us.net> (raw)
In-Reply-To: <54EB671D.3000707@gmail.com>
On Mon, Feb 23, 2015 at 09:45:01AM -0800, Florian Fainelli wrote:
> On 23/02/15 08:26, Guenter Roeck wrote:
> > EEE configuration is similar for the various MV88E6xxx chips.
> > Add generic support for it.
> >
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
> > ---
> > Applies to net-next.
> >
> > The code seems to be working, at least according to ethtool, but some
> > more testing with other chip types would be useful. Also, I am not sure
> > what to do with phy_init_eee.
>
> phy_init_eee() is to be used in case you have a PHY which is not managed
> by the switch indirect or direct accesses, it looks like you are just
> fine with the current code.
>
> One possible improvement could be ironing out the EEE
> enabling/resolution by ensuring that the link partner also supports EEE?
> Not sure if there is an existing register returning that from the
> switch, or if you need to do a direct read to the PHY?
>
EEE configuration on Marvell switches is independent from link partner
capabilities. In the hardware available to me, EEE is enabled by
default with a strapping pin on the chip. Making it dependent on link
partner capabilities would be odd because it would mean that, if the
link is down or if the link partner doesn't support it, it could be
disabled, but it could no longer be re-enabled. This is what
phy_init_eee enforces today. I dropped calling it because I thought
that this behavior would be odd and inconsistent.
Question for me is if it makes sense to have phy_init_eee depend on
the link status or on link partner capabilities in the first place.
Personally I think it should only depend on local PHY capabilities,
and that it should be possible to configure EEE even if the link
is down or if the (current) link partner doesn't support it.
Consider the following: Assume both ends are configured to have EEE
disabled, even if the PHYs support it. Both ends run linux and call
phy_init_eee() to check for EEE capabilities. I have not tested it,
but I suspect that it is not currently possible to enable EEE on either
end because both ends believe that the link partner doesn't support it.
I'll test that theory once I get a system where I can control both ends.
Thanks,
Guenter
next prev parent reply other threads:[~2015-02-23 18:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 16:26 [RFT PATCH 1/2] net: dsa: mv88e6xxx: Add EEE support Guenter Roeck
2015-02-23 16:26 ` [RFT PATCH 2/2] net: dsa: mv88e6352: Add support for EEE Guenter Roeck
2015-02-23 17:45 ` [RFT PATCH 1/2] net: dsa: mv88e6xxx: Add EEE support Florian Fainelli
2015-02-23 18:52 ` Guenter Roeck [this message]
2015-02-23 21:25 ` Florian Fainelli
2015-02-23 22:19 ` David Miller
2015-02-24 2:29 ` Guenter Roeck
2015-02-24 2:34 ` Florian Fainelli
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=20150223185245.GB23456@roeck-us.net \
--to=linux@roeck-us.net \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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 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).