On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
[off-list ref] wrote:

Quoting Rafael J. Wysocki (2015-10-25 06:54:39)

quoted

On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown [off-list ref] wrote:

quoted

On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:

quoted

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues aren't if you're not directly having problems.

There's also the understanding people had that the order things get
bound changes the ordering for some of the other cases (perhaps it's a
good idea to do that, it seems likely to be sensible?).

But it really doesn't do that.  Also making it do so doesn't help much
in the cases where things can happen asynchronously (system
suspend/resume, runtime PM).

If, instead, there was a way to specify a functional dependency at the
device registration time, it might be used to change the order of
everything relevant, including probe.  That should help to reduce the
noise you're referring to.

Taking it a step further, if functional dependencies were understood at
link-time then we could optimize link order as well. There are probably
lots of optimizations if we only made the effort to understand these
dependencies earlier.

Do you mean the kernel link time or something else?

At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.

Constructing the device/resource dependency graph before the device ever
boots sounds interesting to me.

That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.

Thanks,
Rafael