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 <linus.walleij@xxxxxxxxxx> wrote:
>
> > 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
