How to handle device drivers depending on another device.

How to handle device drivers depending on another device.

[Grant Likely]

Scenario: I have an Ethernet device whose driver is probed via the
of_platform bus.  The PHY device is attached to an MDIO bus, but the
MDIO controller hardware is not integrated into the Ethernet device
(separate hardware).  The MDIO bus driver uses phylib.  At probe time,
the Ethernet driver must get a reference to the phy_device structure
in order to set it up and control it.  (Actually, I've got this exact
scenario with 3 different devices on various embedded boards except
using I2C or SPI bus connections.  For simplicity sake I'll stick to
the ETH->MDIO case)

Problem: There are no guarantees that the MDIO bus controller will be
probed before the Ethernet device.
  - If the MDIO bus is probed first, the there is no problem.  The
Ethernet driver can use something like bus_find_device() to locate the
PHY.
  - If the MDIO bus is not probed first, then the PHY is not ready,
and the Ethernet probe function must in some way defer locating the
phy_device until after the MDIO bus is probed.

I'm looking at making the Eth driver register a bus notifier callback
so that it can check each new phy device as it gets registered, but
this is only half a solution because it doesn't get notifications for
PHY devices that are already registered.  To solve this, the driver
could use a use both a notifier and a call to bus_find_device().
However, I'm concerned about a race condition between the two
activities.  If bus_find_device() is called before registering the
notifier, then it theoretically possible for the PHY to be registered
between the two calls and the Eth driver not getting notified.  If the
notifier is registered before the bus_find_device() call, then it is
possible that the Eth driver will get told about a PHY device more
than once if the phy is registered after the notifier, but before
bus_find_device().  I can certainly handle this condition in my
driver, but it seems ugly to me.  Especially so if this is a common
case which would be useful to other drivers (see below).

Here are my questions:
First, is this race condition something I should even be concerned
about (ie. is it more theoretical than practical).  Am I being overly
paranoid in being concerned about it?

Second, does this sound like a common case that would be useful for
more than just a handful of driver that I'm working on?  Specifically,
would it be useful to have an alternate bus_register_notifier()
function which also generated ADD_DEVICE and BOUND_DRIVER
notifications for devices already present?  If others see value in it
then I'll code something up.

Third, let me know if it seems like I'm looking at this problem in the
wrong way.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: How to handle device drivers depending on another device.

[Grant Likely]

On Tue, Dec 9, 2008 at 11:09 PM, Dave Hylands <dhylands@gmail.com> wrote:
> Hi Grant,
>
>> Problem: There are no guarantees that the MDIO bus controller will be
>> probed before the Ethernet device.
>
> I believe that what you're supposed to do is to have "bus" controllers
> initilize themselves using subsys_initcall rather than module_init. If
> you look in include/linux/init.h you can see the various initcall
> definitions. module_init is at the same level as device_initcall. All
> of the initcalls at one "level" are completed before moving onto the
> next level.

Even so the problem still exists.  There is 1 bus and 3 devices
involved.  The 'bus' infrastructure is the MDIO bus (drivers/net/phy),
and it does indeed use subsys_initcall().  But then there is the
Ethernet device, the MDIO controller device, and the PHY device.  Both
the Ethernet device and the MDIO controller device are probed via the
of_platform bus.  The PHY device is attached to the MDIO controller.

So, while the MDIO bus infrastructure is guaranteed to be initialized
first; there is no guarantee that the MDIO bus controller will be
probed before the Ethernet device.  Secondly, even if the MDIO
controller is probed before the Ethernet device, there is no guarantee
that the PHY device will get registered onto the MDIO bus before the
Ethernet device is probed.  There remains the uncertainty of which of
the two devices will get registered first and the Ethernet driver
needs a mechanism to defer initialization until the PHY device is
ready.

> Of course, if you're using loadable modules, then the dependencies
> should take care of things for you.

For the bus infrastructure, yes, but not for the bus instances.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.