On Tuesday, November 04, 2014 10:29:20 AM Dmitry Torokhov wrote: > 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 > 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. > > > > > > > > >> 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 > > 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). I agree. Ideally, devices should be added to power (or generally PM) domains before registration. That is, before calling device_add() for them. That's the first thing to fix here. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html