[PATCH v3 0/9] PM / Domains: Fix race conditions during boot
dmitry.torokhov at gmail.com
Tue Nov 4 10:29:20 PST 2014
On Tue, Nov 04, 2014 at 06:01:44PM +0100, Ulf Hansson wrote:
> >> Devices that are created while "discoverable buses" are being probed
> >> can't be attached to a PM domain before the probing is done, because
> >> those simply doesn't exist.
> > Honestly, I'm not sure what you're talking about.
> > Devices on a "discoverable* bus (say PCI) are added when the *controller* is
> > probed, not when *they* are probed.
> Okay, so maybe "discoverable buses" isn't the proper term.
> > You very much need to have a struct device registered to be able to call
> > really_probe() for it.
> Yes. But my point is that the struct device may be created dynamically
> at some point in time.
And that is fine.
> This is how mmc/sd/sdio cards are handled. We don't have the
> information about the card and thus not the struct device of it, until
> we have detected it. Maybe we could at that point try to add the
> device to its PM domain?
Well, I think we need to first define what PM domain they will fall
into. Do they have to be in one? The concept of power domain, as far as I
understand it, is needed when we need to form relations going outside
the standard parent/child relationship. Here we have a controller and
then one or more cards in it. To be able to use card you need to power
up parent and you can not power down parent until all children are
But in any case, device discovery and binding them to drivers are 2
separate steps. You have a PCI bus. You enumerate it - new PCI devices
are created. Some of them may be put in a certain power domain. You then
bind drivers to PCI devices (not strictly 'then' but we could implement
driver core to postpone binding until current round of enumeration is
complete) - and you discover USB controller and maybe i2c controller.
Then you bind drivers to them which causes enumeration of the new bus
and new devices are created. But in all these cases enumeration and
creation of new 'struct device's, and driver binding are logically
> >> Now, I haven't yet seen a demand for such a cases, but it seems wrong
> >> to not consider them. The current solution cover these.
> > Oh dear. Please rethink this.
> Currently, dev_pm_domain_attach() is being invoked at the point when a
> SDIO card has been found. From sdio_add_func(). How would that be
It is probably the one place where we currently doing it correctly (form
logical point of view, not implementation wise - implementation wise in
sdio we add device to power domain after calling device_add() which
means that probe() could have been called before we added the new device
to any power domain).
More information about the linux-arm-kernel