On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > >> 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. 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-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
