On Thu, Jan 07, 2021 at 09:16:31AM -0300, Fabio Estevam wrote:

Hi Linus,

On Tue, Jan 5, 2021 at 12:35 PM Linus Walleij [off-list ref] wrote:

quoted

So should the ethernet PHY not just have some reset-gpios
that it obtain and de-assert as part of probing?

For example drivers/net/phy/mdio_bus.c has this:

        /* de-assert bus level PHY GPIO reset */
        gpiod = devm_gpiod_get_optional(&bus->dev, "reset", GPIOD_OUT_LOW);

Other drivers can do the same.

Deferred probe should ascertain that this GPIO driver gets
loaded before the ethernet phy driver.

Thanks for your review. I investigated this further and it seems to me
that the issue is in drivers/net/phy/mdio_bus.c, so I am adding some
netdev folks.

The driver drivers/net/phy/mdio_bus.c and the yaml description says
that it only supports one bus level PHY GPIO reset via reset-gpios
property.

On the imx6ul-evk, there are two KSZ8081 PHYs in the same mdio bus, so
this is how I described it in dts:

There are two different GPIO supported. There is the bus GPIO you have
found, which is intended to reset all devices on the MDIO bus.

And there is a per device GPIO reset and reset controller. However, in
order to use these, you need to be able to 'discover' the PHY,
potentially when the device is held in reset. Some devices will
respond to MDIO while held in reset, some don't. If you PHYs don't you
need to add a compatible of the form
ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$ with the PHY ID. The PHY
will then be probed, independent of if it can be found on the bus or
not, and that probing will enable the GPIO.

     Andrew