Hi Andy,
thanks for the clarifications!
On 07/07/2017 01:08 PM, Andy Duan wrote:
3. Who should then trigger the "hard reset" of the PHY? phy_init_hw? The FEC?
The point is that the LAN8710 is currently not always working correctly,
therefore this small change was proposed. Should we really change all
PHY/FECs only because of this?
Furthermore one problem still remains: The enet_refclk is controlled by the
FEC. How does the PHY recognize when it was disabled/enabled?
Your patch is workaround for the issue. As you pointed out these is a common issue.
So we hope to get a better solution to handle these in common code.
Ok. I'm fine with moving the phy-reset-gpios binding into the PHY. But
one question still remains: Who should then trigger the "hard reset" of
the PHY?
The PHY itself doesn't "know" when the refclk is turned off/on. So the
FEC still must call some function of the PHY after the clock was enabled
again. So the phy-reset-after-clk-enable property will remain in the fec
node? Or am I missing something?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
