Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 07/07/2017 09:03 AM, Andy Duan wrote:
From: Richard Leitner <richard.leitner@xxxxxxxxxxx> Sent: Friday, July 07, 2017 1:51 PM
Since it is common issue so long as using the PHY, can you move it into smsc
phy driver like in .smsc_phy_reset() function ?
And get the reset pin from phy dts node.

Some more points that come into my mind:
 - The smsc_phy_reset function is registered as "soft_reset". Would it be OK to
use nRST in it?

It is not reasonable.

 - Would it be OK to call the phy_init_hw function from within the
smsc_phy_reset?

No, phy_init_hw() already call .drv->soft_reset().

 - IMHO I'd have to move the reset gpio binding inside the phy node then. Isn't
that a pretty big change doing that for all PHYs/FECs? Would it be "worth" it?

To make the change to be common, there have big change for phy driver.
Maybe somebody can give one good suggestion/solution for it.

Sorry, I don't think I understood everything correctly:

1. The "phy-reset-gpios" binding should go inside the phy node. This will cause to *change ALL FEC and PHY drivers*. Correct?

2. Add an additonal "hard reset" function to the PHY driver which handles the "phy-reset-gpios". Correct?

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?


Andy


kind regards,
Richard.L
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux