netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: netdev@vger.kernel.org, eric.dumazet@gmail.com,
	rayagond@vayavyalabs.com, davem@davemloft.net,
	yuvalmin@broadcom.com
Subject: Re: [net-next.git 1/4 (v5)] phy: add the EEE support and the way to access to the MMD registers.
Date: Fri, 15 Jun 2012 08:06:00 +0200	[thread overview]
Message-ID: <4FDAD0C8.6000307@st.com> (raw)
In-Reply-To: <1339630137.2612.83.camel@bwh-desktop.uk.solarflarecom.com>

Hello Ben

On 6/14/2012 1:28 AM, Ben Hutchings wrote:

[snip]

>> > + */
>> > +int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
>> > +{
>> > +	int ret = -EPROTONOSUPPORT;
>> > +
>> > +	/* According to 802.3az,the EEE is supported only in full duplex-mode.
>> > +	 * Also EEE feature is active when core is operating with MII, GMII
>> > +	 * or RGMII.
>> > +	 */
>> > +	if ((phydev->duplex == DUPLEX_FULL) &&
>> > +	    ((phydev->interface == PHY_INTERFACE_MODE_MII) ||
>> > +	    (phydev->interface == PHY_INTERFACE_MODE_GMII) ||
>> > +	    (phydev->interface == PHY_INTERFACE_MODE_RGMII))) {
>> > +		int eee_cap, eee_link;
>> > +
>> > +		/* EEE ability must be supported in both local and remote
>> > +		 * PHY devices.
>> > +		 */
>> > +		eee_cap = phy_read_mmd_indirect(phydev->bus, MDIO_AN_EEE_LPABLE,
>> > +						MDIO_MMD_AN, phydev->addr);
>> > +		if (eee_cap < 0)
>> > +			return eee_cap;
>> > +
>> > +		eee_link = phy_read_mmd_indirect(phydev->bus, MDIO_PCS_EEE_ABLE,
>> > +						 MDIO_MMD_PCS, phydev->addr);
>> > +		if (eee_link < 0)
>> > +			return eee_link;
>> > +
>> > +		if (eee_cap && eee_link) {
> I don't see any harm in setting the 'clock stop' bit if requested, even
> if EEE is not supported and therefore we will never receive LPI from the
> link partner.

ok

> But you also use this condition to decide whether to enable TX LPI, so
> it's important that it does match the specification (§78.3) for whether
> EEE is supported - but it doesn't.  You need to work out what mode was
> autonegotiated, then check that the relevant bit is set in both our EEE
> advertising (*not* supported) and the LP EEE advertising masks.

I've some doubts and, before resending the patch, I kindly ask you some
further details just on this point.

In the code, I check if the EEE is supported and on GMII, MII and RGMII
and duplex mode; in case of success the Ethernet driver can enable the
TX LPI.
Indeed, I am only using the 3.20 and 7.61 registers w/o looking at the
7.60. So this should be fixed, shouldn't it?
Am I missing anything else?
What do you mean when say that it doesn't match the specification
(§78.3)? I'm pointing to the '78.3 Capabilities Negotiation' chapter of
the IEEE802-3az, is it ok?\x02\x03\x03\x03\x04\x05\x06\a\x04\b

\x03\x03\x03\x04Thanks for your feedback in advance.

peppe

  parent reply	other threads:[~2012-06-15  6:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13  8:00 [net-next.git 0/4] EEE for PAL and stmmac (v3) Giuseppe CAVALLARO
2012-06-13  8:01 ` [net-next.git 1/4 (v5)] phy: add the EEE support and the way to access to the MMD registers Giuseppe CAVALLARO
2012-06-13 23:28   ` Ben Hutchings
2012-06-14 10:51     ` Giuseppe CAVALLARO
2012-06-15  6:06     ` Giuseppe CAVALLARO [this message]
2012-06-15 16:37       ` Ben Hutchings
2012-06-18  6:23         ` Giuseppe CAVALLARO
2012-06-13  8:01 ` [net-next.git 2/4 (v3)] stmmac: do not use strict_strtoul but kstrtoint Giuseppe CAVALLARO
2012-06-13  8:01 ` [net-next.git 3/4] stmmac: update the driver Documentation and add EEE Giuseppe CAVALLARO
2012-06-13  8:01 ` [net-next.git 4/4 (v5)] stmmac: add the Energy Efficient Ethernet support Giuseppe CAVALLARO
  -- strict thread matches above, loose matches on Subject: below --
2012-06-13  7:17 [net-next.git 0/4] EEE for PAL and stmmac (v2) Giuseppe CAVALLARO
2012-06-13  7:17 ` [net-next.git 1/4 (v5)] phy: add the EEE support and the way to access to the MMD registers Giuseppe CAVALLARO

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=4FDAD0C8.6000307@st.com \
    --to=peppe.cavallaro@st.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rayagond@vayavyalabs.com \
    --cc=yuvalmin@broadcom.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).