How to handle device drivers depending on another device.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux