On Tue, Jun 02, 2015 at 09:54:13AM +0200, Ulf Hansson wrote: > On the other hand, the "long term plan" is to have PM domain pointers > assigned at device registration point instead of at probe. Since > driver core then invokes the ->activate|sync|dismiss() callbacks, it > will make the dev_pm_domain_attach|detach() APIs redundant. How does that work if the PM domain doesn't exist yet, because the driver supplying it hasn't had its own device probed ? You can't return -EPROBE_DEFER to anything that isn't being called via a driver's probe function. So, when the OF code is scanning the device tree, creating the various struct device's, returning -EPROBE_DEFER will cause it to fail to register that struct device and there is no mechanism to retry. Also, your idea above goes against the grain that other resources are heading - that is, towards probe time resolution of resources. IRQ resources have the same problem, and this has caused real problems on platforms to have the IRQ resources resolved to a number at registration time. To me, your idea sounds like the wrong approach and unworkable. What would resolve that would be to have the device registration succeed, but also to scan all devices in the system when a PM domain is attached and attach the PM domain to matching devices. The problem you then have is the same race between attaching the PM domain to all devices in the domain, and devices being probed. Remember, this may not be happening at boot time, but during module load, which on some systems is multithreaded. So, the problem of not having all devices in the PM domain hasn't changed and nothing is solved by this approach - the only thing is the code has become more complex. I don't think that's an improvement. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
