Hi, I came across an issue today on an Allwinner board, but I believe it's a core issue. That board is using the stmac driver together with a phy that happens to have a reset GPIO, except that that GPIO will never be claimed, and the PHY will thus never work. You can find an example of such a board here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun6i-a31-hummingbird.dts#n195 It looks like when of_mdiobus_register() will parse the DT, it will then call of_mdiobus_register_phy() for each PHY it encounters [1]. of_mdiobus_register_phy() will then if the phy doesn't have an ethernet-phy-id* compatible call get_phy_device() [2], and will later on call phy_register_device [3]. get_phy_device() will then call get_phy_id() [4], that will try to access the PHY through the MDIO bus [5]. The code that deals with the PHY reset line / GPIO is however only done in mdiobus_device_register, called through phy_device_register. Since this is happening way after the call to get_phy_device, our PHY might still very well be in reset if the bootloader hasn't put it out of reset and left it there. I'm not entirely sure how to fix that though. I tried to fix it by splitting away the gpio / reset code away from mdiobus_device_register into a new function, and calling it before the first call to get_phy_id so that we can put our phy out of reset, but it looks like the device registration makes it more complicated than that. Any ideas? Thanks! Maxime 1: https://elixir.bootlin.com/linux/latest/source/drivers/of/of_mdio.c#L274 2: https://elixir.bootlin.com/linux/latest/source/drivers/of/of_mdio.c#L82 3: https://elixir.bootlin.com/linux/latest/source/drivers/of/of_mdio.c#L119 4: https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy_device.c#L830 5: https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy_device.c#L791
Attachment:
signature.asc
Description: PGP signature
