On 08/20/2018 09:06 PM, Andrew Lunn wrote:
> I would actually say, this is your real issue here. The warnings are
> annoying, but i don't think they are fatal. This -EBUSY is what is
> stopping the driver from loading, causing the real regression.
My real issue is that a specific commit broke the driver and I would like
to partially revert that offending commit.
> I'm guessing, but i think you will find the driver is loading once,
> but hits a EPROBE_DEFFER condition, after getting the gpio. It does
> not release the gpio correctly. Sometime later, it gets loaded again,
> but the gpio is now in use, so you get the -EBUSY.
>
> So check the error paths, and make sure cleanup is being done correct.
> It could also be a phylib core bug...
I've traced it some more: While mdiobus_register fails to find a PHY,
creation of the "MDIO" bus is still successful and it returns successfully,
having claimed the reset GPIO (These functions should really be called
miibus_register...).
of_phy_fixed_link_register tries to claim the same GPIO and fails.
A fix for that would be something along the lines of da47b45
("phy: add support for a reset-gpio specification"), which caused a regression
and was unfortunately later reverted.
But regardless, there shouldn't have been an of_mdiobus_register and a MDIO bus
probe
before registering the fixed-link in the first place and my patch remedies that.
Reintroducing da47b45 would be out-of-scope for this patch series.
Cheers
Ahmad
