A user reports (slightly shortened from the original message):
libphy: lantiq,xrx200-mdio: probed
mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing.
gswip 1e108000.switch lan: no phy at 2
gswip 1e108000.switch lan: failed to connect to port 2: -19
lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy
This is a single-port board using the internal Fast Ethernet PHY. The
user reports that switching to PHY scanning instead of configuring the
PHY within device-tree works around this issue.
The documentation for the standalone variant of the PHY11G (which is
probably very similar to what is used inside the xRX200 SoCs but having
the firmware burnt onto that standalone chip in the factory) states that
the PHY needs 300ms to be ready for MDIO communication after releasing
the reset.
Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
firmware had enough time to initialize and to appear on the MDIO bus.
Unfortunately there is no (known) documentation on what the minimum time
to wait after releasing the reset on an internal PHY so play safe and
take the one for the external variant. Only wait after the last GPHY
firmware is loaded to not slow down the initialization too much (
xRX200 has two GPHYs but newer SoCs have at least three GPHYs).
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Martin Blumenstingl <[email protected]>
---
drivers/net/dsa/lantiq_gswip.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 74db81dafee3..0a25283bdd13 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -26,6 +26,7 @@
*/
#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/etherdevice.h>
#include <linux/firmware.h>
#include <linux/if_bridge.h>
@@ -1894,6 +1895,16 @@ static int gswip_probe(struct platform_device *pdev)
dev_err(dev, "gphy fw probe failed\n");
return err;
}
+
+ /* The standalone PHY11G requires 300ms to be fully
+ * initialized and ready for any MDIO communication after being
+ * taken out of reset. For the SoC-internal GPHY variant there
+ * is no (known) documentation for the minimum time after a
+ * reset. Use the same value as for the standalone variant as
+ * some users have reported internal PHYs not being detected
+ * without any delay.
+ */
+ msleep(300);
}
/* bring up the mdio bus */
--
2.29.2
> Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
> firmware had enough time to initialize and to appear on the MDIO bus.
> Unfortunately there is no (known) documentation on what the minimum time
> to wait after releasing the reset on an internal PHY so play safe and
> take the one for the external variant. Only wait after the last GPHY
> firmware is loaded to not slow down the initialization too much (
> xRX200 has two GPHYs but newer SoCs have at least three GPHYs).
Hi Martin
Could this be moved into gswip_gphy_fw_list() where the actual
firmware download happens?
To me that seems like the more logical place.
Otherwise
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
Hi Andrew,
On Sun, Nov 15, 2020 at 4:57 PM Andrew Lunn <[email protected]> wrote:
>
> > Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
> > firmware had enough time to initialize and to appear on the MDIO bus.
> > Unfortunately there is no (known) documentation on what the minimum time
> > to wait after releasing the reset on an internal PHY so play safe and
> > take the one for the external variant. Only wait after the last GPHY
> > firmware is loaded to not slow down the initialization too much (
> > xRX200 has two GPHYs but newer SoCs have at least three GPHYs).
>
> Hi Martin
>
> Could this be moved into gswip_gphy_fw_list() where the actual
> firmware download happens?
>
> To me that seems like the more logical place.
good point, that's closer to the loop over all GPHY instances.
I've taken care of it in v2 - many thanks!
Best regards,
Martin