Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 6 Jul 2020 20:13:31 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Frank Rowand <frowand.list@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        Antoine =?utf-8?Q?T=C3=A9nart?= <antoine.tenart@bootlin.com>
Subject: PHY reset handling during DT parsing
Message-ID: <20200706181331.x2tn5cl5jn5kqmhx@gilmour.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="2ftaacwvvl7mumne"
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--2ftaacwvvl7mumne
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--2ftaacwvvl7mumne
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXwNpywAKCRDj7w1vZxhR
xU1lAQCR+4X7EF6qEnFyxVCuaNV/g3Bjlk5krQv8tSUb3DmQ+AEA2WAuzE9iBzzg
Awm1dmo/sBptpDkj+d3oPz4YqsFQvQw=
=Gsc3
-----END PGP SIGNATURE-----

--2ftaacwvvl7mumne--