PM / Domains: Fix race conditions during boot
Get series with b4
b4 am 20141104182920.GB440@dtor-wsVersions newest first · linked by author and title
- v3 Latest posting 2/20 of 9 patches 0 repliesNew
- v3 posting 1/21 of 9 patches 0 repliesSuperseded
Patches in v3 posting 2/2 No applies recorded yet
None of the 9 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [PATCH v3 0/9] PM / Domains: Fix race conditions during boot
Quoted 10 lines · Ulf Hansson
Quoted 9 lines
Quoted 4 lines
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.
Quoted 8 lines
Okay, so maybe "discoverable buses" isn't the proper term.
Quoted 3 lines
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.
Quoted 5 lines
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 powered down.
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 separate steps.
Quoted 11 lines
Quoted 6 lines
Quoted 4 lines
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. Fromsdio_add_func(). How would that be solved?
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).
Thanks.
Signature · 1 line
Dmitry