Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

Alan Stern
2011-10-13T14:31:46Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1328 bytes --]

On Thu, 13 Oct 2011, Ming Lei wrote:

> >> Inside device_add(), device_pm_add is called before bus_probe_device,
> >> so the patch can't change the device order in pm list, and just change
> >> the driver probe order.
> >
> > That's the way it works now, but can it be reworked?  It would be
>
> IMO, it depends on what shape you plan to rework. Currently, the
> deferred probe may found a resource dependency, but I am not sure
> that pm dependency is same with the resource dependency found
> during probe.
>
> > possible to adjust the list order after successful probe.  However,
> > I'm not clear on the ordering rules for the dpm_list.  Right now it is
> > explicitly ordered to have parents before children, but as already
> > expressed, that doesn't accurately represent ordering constraints for
> > multiple device dependancies.
>
> Maybe we should understand the correct model of the ordering constraints
> for the multiple device dependancies first, could you give a description or
> some examples about it?

The requirement is that devices must be capable of resuming in the
order given by dpm_list, and they must be capable of suspending in
the reverse order.

Therefore if device A can't work unless device B is functional, then B
must come before A in dpm_list.

Alan Stern