On Nov 29 2018, Andrew Lunn <and...@lunn.ch> wrote:
> So if we assume you can identify the PHY using its ID registers, you
> can put this reset code into the soft_reset call. That gets called
> first before anything else. There is no need to add a new function to
> phy_driver.
I've tried the following, but it made things only worse, with the
probing not working at all.
Andreas.
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 7cae175177..65baf31331 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -1822,6 +1822,23 @@ static int vsc85xx_probe(struct phy_device *phydev)
return vsc85xx_dt_led_modes_get(phydev, default_mode);
}
+static int vsc8541_soft_reset(struct phy_device *phydev)
+{
+ /* The VSC8541 has an unexpected feature where a single reset
+ * rising edge can only be used to enter managed mode. For
+ * unmanaged mode a pair of reset rising edges is necessary.
+ */
+ mdio_device_reset(&phydev->mdio, 0);
+ mdio_device_reset(&phydev->mdio, 1);
+
+ /* After this pair of reset rising edges we must wait at least
+ * 15ms before writing any phy registers.
+ */
+ msleep(15);
+
+ return genphy_soft_reset(phydev);
+}
+
/* Microsemi VSC85xx PHYs */
static struct phy_driver vsc85xx_driver[] = {
{
@@ -1908,7 +1925,7 @@ static struct phy_driver vsc85xx_driver[] = {
.phy_id_mask = 0xfffffff0,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .soft_reset = &genphy_soft_reset,
+ .soft_reset = &vsc8541_soft_reset,
.config_init = &vsc85xx_config_init,
.config_aneg = &vsc85xx_config_aneg,
.aneg_done = &genphy_aneg_done,
--
2.19.2
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
