Re: MDIO over I2C driver driver probe dependency issue

On Thu, Jan 07, 2021 at 07:05:21PM -0800, Florian Fainelli wrote:

On 1/7/2021 6:22 PM, Brian Silverman wrote:

quoted

I've written a very small generic MDIO driver that uses the existing
mdio-i2c.c library in drivers/net/phy.  The driver allows
communication to the PHY's MDIO interface as using I2C, as supported by
PHYs like the BCM54616S.  This is working on my hardware.  

The one issue I have is that I2C is not up and available (i.e. probed)
at the time that the MDIO interface comes up.  To fix this, I've changed
the device order in drivers/Makefile to put "obj-y += i2c/"
before "obj-y += net/".

While that works, I prefer not to have to keep that difference from
mainline Linux.  Also, I don't understand why i2c drivers occur
arbitrarily late in the Makefile - surely there are other devices
drivers that need i2c to be enabled when they are probed?

Is there a way to do this that doesn't change probe order?  Or is there
a way to change probe order without patching mainline Linux?

Linux supports probe deferral so when a consumer of a resource finds
that said resource's provider is not available, it should return
-EPROBE_DEFER which puts the driver's probe routine onto a list of
driver's probe function to retry at a later time.

In your case the GEM Ethernet driver should get an -EPROBE_DEFER while
the Ethernet PHY device tree node is looked up via
phylink_of_phy_connect() because the mdio-i2c-gen i2c client has not had
a chance to register the MDIO bus yet. Have you figured out the call
path that does not work for you?

Just adding to this. The way the current mdio-i2c code is used, we
have already talked to the SFP to get its EEPROM contents. So we know
I2C works at the time the mdio-i2c bus is instantiated.

You are using the code slightly differently which might be why the
code is not correctly handling EPROBE_DEFER where it should. Patches
to add this are likely to be accepted.

   Andrew