Re: RFC: phylink: disable PHY autonomous EEE when MAC manages LPI

[Andrew Lunn <andrew@lunn.ch>]

> Thanks Russell and Andrew. You're both heading in the same direction,
> so to make sure I understand correctly:
> 
> 1. Add a new phylib interface (separate from phy_ethtool_set_eee) to
>    control PHY-autonomous EEE, e.g. phy_set_autonomous_eee(phydev,
>    enable) and phy_get_autonomous_eee(phydev) to query the current
>    state.

In the end, we want the MAC driver using phylib to just call the
phylib methods for configuring EEE, and the MAC driver should not care
if EEE is actually implemented in the PHY or the MAC. The adjust_link
callback would simply not enable LPI if the PHY is doing EEE.

The phylink API should do the same, the MAC driver should not care, it
calls into phylink, but phylink never tells it to enable LPI.

So any API you add here should only be for phylink to phylib.

> 2. PHY drivers implement it where applicable. BCM54xx AutogrEEEn as
>    the first user, Realtek RTL8211F as a second - it already
>    unconditionally disables PHY-mode EEE in config_init with the same
>    intent.

We might want to think about this lower API, the driver
API. Historically EEE has been a mess because MAC drivers have been
left to implement the whole API, they each did it differently, and
many were wrong. There has been a push over the last few years to put
the core of EEE support onto phylib/phylink, so leaving the MAC
drivers to do a small amount.

We should learn from this, and try to think about what can the phylib
core should do for PHY level EEE, and what does the PHY driver need to
do?  Maybe passing the whole struct ethtool_keee to the PHY driver is
just asking for problems. We want a much simpler API to start with.
Just add an autonomous_eee_disable() call for the moment, leaving it
open to later add a autonomous_eee_enable() call with just the needed
parameters.

Sorry this is different to what i said yesterday. A night of thinking
about it made me refine my thoughts.

      Andrew