tx_lpi_timer is a MAC property, but phylib does track it across
--set-eee calls and will fill it in for get-eee. What however is
missing it setting its default value. There is currently no API the
MAC driver can call to let phylib know what default value it is using.
Either such an API could be added, e.g. as part of phy_support_eee(),
or we could hard code a value, probably again in phy_support_eee().
tx_lpi_enabled is filled in by phy_ethtool_get_eee(), and its default
value is set by phy_support_eee(). So i don't see what is wrong here.
Currently, we are facing 3 issues:
1. When we boot up our system and do not issue the 'ethtool --set-eee'
command, and then directly issue the 'ethtool --show-eee' command, it always
shows that EEE is disabled due to the eeecfg values not being set. However,
in the Maxliner GPY PHY, the driver EEE is enabled. If we try to disable
EEE, nothing happens because the eeecfg matches the setting required to
disable EEE in ethnl_set_eee(). The phy_support_eee() was introduced to set
the initial values to enable eee_enabled and tx_lpi_enabled. This would
allow 'ethtool --show-eee' to show that EEE is enabled during the initial
state. However, the Marvell PHY is designed to have hardware disabled EEE
during the initial state. Users are required to use Ethtool to enable the
EEE. phy_support_eee() does not show the correct for Marvell PHY.
We discussed what to set the initial state to when we reworked the EEE
support. It is a hard problem, because changing anything could cause
regressions. Some users don't want EEE enabled, because it can add
latency and jitter, e.g. to PTP packets. Some users want it enabled
for the power savings.
We decided to leave the PHY untouched, and will read out its
configuration. If this is going wrong, that is a bug which should be
found and fixed.
We want the core to be fixed, not workaround added to MACI will create different small patch fixes for each of the implementations. Thank you.
drivers. Please think about this when proposing future patches.
Andrew