Date:	Mon, 4 Jul 2011 12:01:59 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Greg KH <gregkh@...e.de>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism

On Mon, Jul 04, 2011 at 10:41:26AM -0700, Greg KH wrote:
> On Mon, Jul 04, 2011 at 11:11:59AM -0600, Grant Likely wrote:
> > Allow drivers to report at probe time that they cannot get all the resources
> > required by the device, and should be retried at a later time.
> 
> When is "later"?

In this case, after at least one other device has successfully probed.
The 'later' is handled in a workqueue that walks the list
asynchronously from normal initialization.

> And why would a driver not be able to get all of the proper resources?

Discussed below...

> Why can't a bus, at a later time, just try to reprobe everything when it
> determines that it is a "later" time now, without having to do this
> added change to the core?

It can't be done by a specific bus type because it has zero
relationship with the bus type.  For example, it is typical for an
SDHCI driver to require a GPIO line for the card detect switch, and
the device cannot be initialized until it has it.  However, the
bus_type that the SDHCI driver is attached to could be anything;
platform_bus_type, pci, amba, etc.  It isn't a bus_type deficiency,
but rather that the driver core has no way to gracefully handle
devices that get probed in an undetermined order.

It has to be done at the core level because any device in the system,
regardless of bus_type, may require another device to be probed first.
Originally I tried modifying the drivers to successfully probe
anyway and then 'go to sleep' to try again later, but it turned out to
push a lot of complexity into the device drivers when it can be solved
far more simply if the driver core has the ability to retry drivers
that request it.

Another example is sound on embedded systems.  A "sound card"
typically consists of multiple devices; one or more codecs (often i2c
or spi attached), a sound bus (often i2s), a dma controller, and a
lump of machine/platform specific code that ties them all together.
Right now the ASoC code is going through all kinds of gymnastics make
each component register with the ASoC layer and the 'tie together'
driver has to wait for each of them to show up.  As Mark will attest,
it is a lot of domain specific code that cannot be easily generalized
to be used by other subsystems.

I also could have implemented this without the deferred_probe list,
but doing so would have required every unbound device in the system to
be retried against every matching driver each time an -EAGAIN event
occurred.  I figured that would be rather excessive when the kernel
already has specific knowledge of devices that need to be retried.

> > This should completely solve the problem of getting devices
> > initialized in the right order.  Right now this is mostly handled by
> > mucking about with initcall ordering which is a complete hack, and
> > doesn't even remotely handle the case where device drivers are in
> > modules.  This approach completely sidesteps the issues by allowing
> > driver registration to occur in any order, and any driver can request
> > to be retried after a few more other drivers get probed.
> 
> Why would drivers in modules be an issue?  If a driver depends on
> another driver, making it a module dependancy would solve the problem,
> right?

Not nearly that simple.  Consider the case where driver A depends on a
gpio resource provided by driver B.  Well, driver A could depend on
driver B, but driver A has zero knowledge of what B actually is
because B is different for each system.

So, since A cannot depend on B because B is dynamic, the problem
cannot be solved with enforcing a module load order.

g.

--
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/

Powered by blists - more mailing lists