On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: >> I'm guessing the time is a matter of probing and undoing the probes >> rather than slow h/w. We could maybe improve things by making sure >> drivers move what they defer on to the beginning of probe, but that >> seems like a horrible, fragile hack. > > How can calling probe and failing cause 2 seconds? How many different > probe calls are failing here? Again, a boot log graph would be great to > see as it will show the root cause, not just guessing at this.
just fwiw, but when you have a driver that depends on several other drivers (which in turn depend on other drivers and so on), the amount of probe-defer we end up seeing is pretty comical. Yeah, there probably is some room to optimize by juggling around order drivers do things in probe. But that doesn't solve the fundamental problem with the current state, about probe order having no clue about dependencies.. BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
