> -----Original Message----- > From: Florian Fainelli [mailto:f.faine...@gmail.com] > Sent: Friday, December 09, 2016 7:22 AM > To: David Miller <da...@davemloft.net>; S.H. Xie <shaohui....@nxp.com> > Cc: netdev@vger.kernel.org > Subject: Re: [PATCH] net: gianfar: add ethtool eee support > > On 12/08/2016 03:19 PM, David Miller wrote: > > From: Shaohui Xie <shaohui....@nxp.com> > > Date: Thu, 8 Dec 2016 19:27:06 +0800 > > > >> Gianfar does not support EEE, but it can connect to a PHY which > >> supports EEE and the PHY advertises EEE by default, and its link > >> partner also advertises EEE, so the PHY enters low power mode when > >> traffic rate is low, which causes packet loss if an application's > >> traffic rate is low. This patch provides .get_eee and .set_eee so > >> that to disable the EEE advertisement via ethtool if needed, other EEE > >> features > are not supported. > >> > >> Signed-off-by: Shaohui Xie <shaohui....@nxp.com> > > > > This is not the way to fix this. > > > > If the Gianfar MAC does not support EEE properly, then the gianfar > > driver should not create a situation where the PHY advertises EEE in > > the first place. > > Agreed, you should have gianfar mask out the EEE advertisement from the PHY it > connects to, in order to make sure that EEE is properly disabled. > This should be no different from e.g: connecting a 10/100/1000 PHY to a > 10/100 only controller for instance. [S.H] The EEE advertisement does not belong to PHY device, gianfar cannot mask out the EEE Advertisement like advertising, should use phy_write_mmd_indirect() to disable it?
And by disabling EEE advertisement always, the PHY cannot enter low power mode even if there is no traffic. Using ethtool could provide user options to handle this. Thanks. Shaohui
