Re: [PATCH v3 0/9] PM / Domains: Fix race conditions during boot

[Ulf Hansson <ulf.hansson@linaro.org>]

On 4 November 2014 22:38, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> 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.

It's done in patch 7 in this patchset.

[PATCH v3 7/9] mmc: core: Attach PM domain prior probing of SDIO func driver

Kind regards
Uffe