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
next prev 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 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.