Re: phy_attach_direct()'s use of device_bind_driver()

On Wed, Feb 10, 2021 at 11:31 PM Heiner Kallweit [off-list ref] wrote:

On 11.02.2021 00:29, Saravana Kannan wrote:

quoted

On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn [off-list ref] wrote:

quoted

On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:

quoted

Hi,

This email was triggered by this other email[1].

Why is phy_attach_direct() directly calling device_bind_driver()
instead of using bus_probe_device()?

Hi Saravana

So this is to do with the generic PHY, which is a special case.

First the normal case. The MDIO bus driver registers an MDIO bus using
mdiobus_register(). This will enumerate the bus, finding PHYs on
it. Each PHY device is registered with the device core, using the
usual device_add(). The core will go through the registered PHY
drivers and see if one can drive this hardware, based on the ID
registers the PHY has at address 2 and 3. If a match is found, the
driver probes the device, all in the usual way.

Sometime later, the MAC driver wants to make use of the PHY
device. This is often in the open() call of the MAC driver, when the
interface is configured up. The MAC driver asks phylib to associate a
PHY devices to the MAC device. In the normal case, the PHY has been
probed, and everything is good to go.

However, sometimes, there is no driver for the PHY. There is no driver
for that hardware. Or the driver has not been built, or it is not on
the disk, etc. So the device core has not been able to probe
it. However, IEEE 802.3 clause 22 defines a minimum set of registers a
PHY should support. And most PHY devices have this minimum. So there
is a fall back driver, the generic PHY driver. It assumes the minimum
registers are available, and does its best to drive the hardware. It
often works, but not always. So if the MAC asks phylib to connect to a
PHY which does not have a driver, we forcefully bind the generic
driver to the device, and hope for the best.

Thanks for the detailed answer Andrew! I think it gives me enough
info/context to come up with a proper fix.

quoted

We don't actually recommend using the generic driver. Use the specific
driver for the hardware. But the generic driver can at least get you
going, allow you to scp the correct driver onto the system, etc.

I'm not sure if I can control what driver they use. If I can fix this
warning, I'll probably try to do that.

The genphy driver is a last resort, at least they lose functionality like
downshift detection and control. Therefore they should go with the
dedicated Marvell PHY driver.

But right, this avoids the warning, but the underlying issue (probably
in device_bind_driver()) still exists. Would be good if you can fix it.

Yeah, I plan to fix this. So I have a few more questions. In the
example I gave, what should happen if the gpios listed in the phy's DT
node aren't ready yet? The generic phy driver itself probably isn't
using any GPIO? But will the phy work without the GPIO hardware being
initialized? The reason I'm asking this question is, if the phy is
linked to a supplier and the supplier is not ready, should the
device_bind_driver() succeed or not?

-Saravana