[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180319153717.GG26039@lunn.ch>
Date: Mon, 19 Mar 2018 16:37:17 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Claudiu Manoil <claudiu.manoil@....com>
Cc: Kevin Hao <haokexin@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH] net: phy: realtek: Add dummy stubs for MMD register
access for rtl8211b
> This gianfar patch should have been a temporary workaround.
> Obviously, the driver of an (old) eth controller that does not support EEE should
> not be modified to have the same eth controller work normally when some new EEE
> capable phy happens to be attached to that controller (i.e. on a new board).
> It should be up to the phy integration layer to identify that the controller and the phy
> are not EEE compatible, and restrict the phy from entering EEE mode. (without any
> change to the eth driver)
We end up in the same place, needing to patch the RealTek PHY driver.
A MAC driver indicates it can do EEE by calling phy_init_eee(). This
will then turn on EEE in the PHY.
A PHY is not supposed to negotiate EEE unless it is asked to. But some
PHYs do it by default, and the PHY driver is not turning it off. That
is what b6b5e8a69118 fixes for the gianfar.
We could unconditionally disable EEE on all PHYs at probe time, and
then let phy_init_eee() turn it back on again. But then we need the
fix posted here for the RealTek PHY.
There does not appear to be any bit in the PHY status registers to
indicate if MMD is supported or not. So i don't see how we can make
unconditional disable of EEE safe without introducing lots of
regressions.
Andrew
Powered by blists - more mailing lists