On 26 October 2015 at 11:51, 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.

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

Alexander Holler has been looking at that for some time already.

Regards,

Tomeu

Regards,
Mike

quoted

If the dependency could only be discovered at the probe time, the
order of things might be changed in response to letting the driver
core know about it rather than "just in case", which should be more
efficient.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/