Re: [PATCH 0/3] at803x: Add quirk to disable SmartEEE

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Mon, Jan 28, 2019 at 10:46:20AM +0000, Carlo Caione wrote:
> On 25/01/19 20:27, Heiner Kallweit wrote:
> > OK, then the description of the referenced patch isn't fully correct
> > and SmartEEE and EEE are partially compatible, and the problem is
> > just that we don't know exactly to which extent.
> 
> Reading from the datasheet at [0] it seems that SmartEEE is compatible with
> EEE but it's something different.

As I understand it, SmartEEE is just like normal EEE as far as the link
partner is concerned.  The difference is between the PHY and MAC.  What
follows is a simplified understanding of the differences.

In conventional EEE, the MAC takes part in EEE - the local MAC requests
that its attached PHY enters LPI mode, which signals to the link partner
PHY that the data stream on the link is going to pause.  When the local
MAC wants to transmit, it first has to signal to the attached PHY that
the link should be woken up, and the MAC has to wait for the link to
exit LPI before transmitting.

With SmartEEE, the decision to enter LPI mode is taken not by the local
MAC but by the PHY instead, since SmartEEE is designed to produce power
savings for MACs that do not support LPI.  Of course, they won't achieve
the same power saving as real EEE, but they do help to reduce the power
dissipation in the PHY.

PHYs that support this buffer some data from the MAC, and that buffering
has to be sufficient for the delay in the link coming out of LPI mode
without losing data.

As far as the link partner is concerned, EEE and SmartEEE appear the
same.

> With SmartEEE the PHY can actually enter LPI state even if this is not
> supported by the link partner since the LPI pattern is generated inside the
> PHY itself, so auto-implementing a sort of EEE.

It sounds to me like you have this the wrong way round.  SmartEEE isn't
about the link partner not supporting LPI, it's about the local MAC not
supporting EEE, but still getting some power savings.

EEE (of either kind) can only be entered on the link when both the
local PHY and remote PHY indicate support for EEE, and have negotiated
that they support EEE.

Most of the power dissipation is from driving the signals into the
network cable (which is a lossy environment) to ensure that the far
end has sufficient signal to keep the link established.  SmartEEE is
about giving a way to enter 802.3az EEE mode on the _cable_ with a
MAC that does not support EEE.

I've monitored the signals on a link with an Atheros AR8035 with
SmartEEE mode enabled, and a Marvell 88e1514 PHY in a Marvell switch
on the other end, and seen the signals on the cable quiesce as a
result of SmartEEE, but only when _both_ partners are set to allow
EEE in the negotiated link mode.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up