From: Andrew Lunn <andrew@lunn.ch>
To: Claudiu Manoil <claudiu.manoil@nxp.com>
Cc: Kevin Hao <haokexin@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH] net: phy: realtek: Add dummy stubs for MMD register access for rtl8211b
Date: Mon, 19 Mar 2018 16:37:17 +0100 [thread overview]
Message-ID: <20180319153717.GG26039@lunn.ch> (raw)
In-Reply-To: <AM0PR0402MB33963682784604EC4904928096D40@AM0PR0402MB3396.eurprd04.prod.outlook.com>
> 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
prev parent reply other threads:[~2018-03-19 15:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-19 12:05 [PATCH] net: phy: realtek: Add dummy stubs for MMD register access for rtl8211b Kevin Hao
2018-03-19 12:39 ` Andrew Lunn
2018-03-19 12:51 ` Kevin Hao
2018-03-19 14:31 ` Claudiu Manoil
2018-03-19 15:37 ` Andrew Lunn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180319153717.GG26039@lunn.ch \
--to=andrew@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=f.fainelli@gmail.com \
--cc=haokexin@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox