linux-kernel - How to handle device drivers depending on another device.

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 9 Dec 2008 22:45:36 -0700
From:	"Grant Likely" <grant.likely@...retlab.ca>
To:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-embedded@...r.kernel.org
Subject: How to handle device drivers depending on another device.

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/