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 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).