Hello.
On 02-04-2014 3:55, Alexander Holler wrote:
Commit 7cd1463664c2a15721ff4ccfb61d4d970815cb3d (introduced with 3.14)
changed the initialization of the mv643xx_eth driver to use phy_init_hw()
to reset the PHY. Unfortunately the initialization for the 88E1116R PHY
was broken such, that it used mdelay() instead of really waiting for a
reset to finish.
The effect was that the ethernet on my Kirkwood 88F6281 based device didn't
come up anymore (no carrier).
Fix this by waiting for a reset to finish before proceeding further.
Signed-off-by: Alexander Holler <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: <[email protected]>
---
drivers/net/phy/marvell.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bd37e45..5b84808 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -396,7 +396,9 @@ static int m88e1116r_config_init(struct phy_device *phydev)
if (err < 0)
return err;
- mdelay(500);
+ do
+ temp = phy_read(phydev, MII_BMCR);
+ while (temp & BMCR_RESET);
I don't understand what's the point of this BMCR reset if phy_init_hw()
will have already done it before calling phy_init_hw().
@@ -429,7 +431,9 @@ static int m88e1116r_config_init(struct phy_device *phydev)
if (err < 0)
return err;
- mdelay(500);
+ do
+ temp = phy_read(phydev, MII_BMCR);
+ while (temp & BMCR_RESET);
Not clear why it's necessary to reset one more time... Also, tight loop
without a timeout (0.5 sec, specified by IEEE 802.3) doesn't look good. The
comment above phy_poll_reset() suggests that it could be used in the PHY
drivers as well. Florian?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
