[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y++IAH16RqbZrSpg@lunn.ch>
Date: Fri, 17 Feb 2023 14:58:24 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: netdev <netdev@...r.kernel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <vladimir.oltean@....com>,
Sean Wang <sean.wang@...iatek.com>,
Landen Chao <Landen.Chao@...iatek.com>,
DENG Qingfang <dqfext@...il.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Doug Berger <opendmb@...il.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Wei Fang <wei.fang@....com>,
Shenwei Wang <shenwei.wang@....com>,
Clark Wang <xiaoning.wang@....com>,
NXP Linux Team <linux-imx@....com>,
UNGLinuxDriver@...rochip.com, Byungho An <bh74.an@...sung.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <rmk+kernel@...linux.org.uk>,
Woojung Huh <woojung.huh@...rochip.com>,
Oleksij Rempel <linux@...pel-privat.de>
Subject: Re: [PATCH RFC 08/18] net: FEC: Fixup EEE
> > @@ -1997,6 +1988,7 @@ static void fec_enet_adjust_link(struct net_device *ndev)
> > netif_tx_unlock_bh(ndev);
> > napi_enable(&fep->napi);
> > }
> > + fec_enet_eee_mode_set(ndev, phy_dev->eee_active);
>
> Most of iMX variants do not support EEE. It should be something like this:
> if (fep->quirks & FEC_QUIRK_HAS_EEE)
> fec_enet_eee_mode_set(ndev, phy_dev->eee_active);
Yes, i missed that. Thanks.
> > @@ -3131,15 +3120,7 @@ fec_enet_set_eee(struct net_device *ndev, struct ethtool_eee *edata)
> > return -ENETDOWN;
> >
> > p->tx_lpi_timer = edata->tx_lpi_timer;
> > -
> > - if (!edata->eee_enabled || !edata->tx_lpi_enabled ||
> > - !edata->tx_lpi_timer)
> > - ret = fec_enet_eee_mode_set(ndev, false);
> > - else
> > - ret = fec_enet_eee_mode_set(ndev, true);
> > -
> > - if (ret)
> > - return ret;
> > + p->tx_lpi_enabled = edata->tx_lpi_enabled;
>
> Hm.. this change have effect only after link restart. Should we do
> something like this?
>
> if (phydev->link)
> fec_enet_eee_mode_set(ndev, phydev->eee_active);
>
> or, execute phy_ethtool_set_eee() first and some how detect if link
> changed? Or restart link by phylib on every change?
The whole startup sequence needs looking at, and ties in with the
phy_supports_eee() call we need to add. Given that EEE is broken with
most MAC drivers, i thought we could do that in a follow up patch
series.
As Russell says, we want to avoid multiple auto-neg cycles. Ideally we
want phy_supports_eee() to be called before phy_start() so that EEE
advertisement is set correctly for the first auto-neg. What is missing
from many MAC drivers is a default value from the LPI timer. It seems
like the need eee_set() has to be called with a value, or they are
relying on hardware reset values. Maybe we need to define a default?
We also need to discuss policy of if EEE should be enabled by default
for those systems which support it. As you have pointed out, it can
effect PTP quality.
Andrew
Powered by blists - more mailing lists