Hi Florian
sorry for my delay.
On 11/24/2016 7:23 PM, Florian Fainelli wrote:
+Peppe,
Le 24/11/2016 à 07:38, Andrew Lunn a écrit :
As for enabling advertising and correct working of cpsw do you mean it
would be better to disable EEE in any PHY on cpsw initialization as
long as cpsw doesn't provide support for EEE?
We observe some strange behavior with our gigabit PHYs and a link
partner in a EEE-capable unmanaged NetGear switch. Disabling
advertising seems to help. Though we're still investigating the issue.
Hi Florian
Am i right in saying, a PHY should not advertise EEE until the MAC
driver calls phy_init_eee(), indicating the MAC supports EEE?
You would think so, but I don't see how this could possibly work if that
was not the case already, see below.
If so, it looks like we need to change a few of the PHY drivers, in
particular, the bcm-*.c.
The first part that bcm-phy-lib.c does is make sure that EEE is enabled
such that this gets reflected in MDIO_PCS_EEE_ABLE, without this, we
won't be able to pass the first test in phy_init_eee(). The second part
is to advertise EEE such that this gets reflected in MDIO_AN_EEE_ADV,
also to make sure that we can pass the second check in phy_init_eee().
Now, looking at phy_init_eee(), and what stmmac does (and bcmgenet,
copied after stmmac), we need to somehow, have EEE advertised for
phy_init_eee() to succeed, prepare the MAC to support EEE, and finally
conclude with a call to phy_ethtool_set_eee(), which writes to the
MDIO_AN_EEE_ADV register, and concludes the EEE auto-negotiated process.
Since we already have EEE advertised, we are essentially just checking
that the EEE advertised settings and the LP advertised settings actually
do match, so it sounds like the final call to phy_ethtool_set_eee() is
potentially useless if the resolved advertised and link partner
advertised settings already match...
So it sounds like at least, the first time you try to initialize EEE, we
should start with EEE not advertised, and then, if we have EEE enabled
at some point, and we re-negotiate the link parameters, somehow
phy_init_eee() does a right job for that.
Peppe, any thoughts on this?
I share what you say.
In sum, the EEE management inside the stmmac is:
- the driver looks at own HW cap register if EEE is supported
(indeed the user could keep disable EEE if bugged on some HW
+ Alex, Fabrice: we had some patches for this to propose where we
called the phy_ethtool_set_eee to disable feature at phy
level
- then the stmmac asks PHY layer to understand if transceiver and
partners are EEE capable.
- If all matches the EEE is actually initialized.
the logic above should be respected when use ethtool, hmm, I will
check the stmmac_ethtool_op_set_eee asap.
Hoping this is useful
Regards
Peppe
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
