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
