netdev - Re: MDIO over I2C driver driver probe dependency issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <X/hhT4Sz9FU4kiDe@lunn.ch>
Date:   Fri, 8 Jan 2021 14:42:39 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Brian Silverman <silvermanbri@...il.com>, netdev@...r.kernel.org
Subject: 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:
> > 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