[PATCH] net: emac: fix fixed-link setup for the RTL8363SB switch

[PATCH] net: emac: fix fixed-link setup for the RTL8363SB switch

[Christian Lamparter]

On the Netgear WNDAP620, the emac ethernet isn't receiving nor
xmitting any frames from/to the RTL8363SB (identifies itself
as a RTL8367RB).

This is caused by the emac hardware not knowing the forced link
parameters for speed, duplex, pause, etc.

This begs the question, how this was working on the original
driver code, when it was necessary to set the phy_address and
phy_map to 0xffffffff. But I guess without access to the old
PPC405/440/460 hardware, it's not possible to know.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
 drivers/net/ethernet/ibm/emac/core.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 354c0982847b..3b398ebdb5e6 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -2677,12 +2677,17 @@ static int emac_init_phy(struct emac_instance *dev)
 		if (of_phy_is_fixed_link(np)) {
 			int res = emac_dt_mdio_probe(dev);
 
-			if (!res) {
-				res = of_phy_register_fixed_link(np);
-				if (res)
-					mdiobus_unregister(dev->mii_bus);
+			if (res)
+				return res;
+
+			res = of_phy_register_fixed_link(np);
+			dev->phy_dev = of_phy_find_device(np);
+			if (res || !dev->phy_dev) {
+				mdiobus_unregister(dev->mii_bus);
+				return res ? res : -EINVAL;
 			}
-			return res;
+			emac_adjust_link(dev->ndev);
+			put_device(&dev->phy_dev->mdio.dev);
 		}
 		return 0;
 	}
-- 
2.19.0.rc2

Re: [PATCH] net: emac: fix fixed-link setup for the RTL8363SB switch

[David Miller]

From: Christian Lamparter <chunkeey@gmail.com>
Date: Mon, 17 Sep 2018 17:22:40 +0200

> On the Netgear WNDAP620, the emac ethernet isn't receiving nor
> xmitting any frames from/to the RTL8363SB (identifies itself
> as a RTL8367RB).
> 
> This is caused by the emac hardware not knowing the forced link
> parameters for speed, duplex, pause, etc.
> 
> This begs the question, how this was working on the original
> driver code, when it was necessary to set the phy_address and
> phy_map to 0xffffffff. But I guess without access to the old
> PPC405/440/460 hardware, it's not possible to know.
> 
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

Applied.