On Sat, 2012-09-08 at 19:57 -0700, Greg Kroah-Hartman wrote: > As you state, this doesn't really solve the problem, and will cause a > lot more (think about all the busses that aren't expecting to have > their > probe functions called at the same time as other probe functions are > being called.) > > So while I applaud the effort, I can't accept this due to the past > history of when it was tried before.
Maybe a compromise would be to have ->probe() be called synchronously as done currently, but to add support for a specific -EAGAIN return from it, requiring a later asynchronous re-probe ? (Possibly requiring an explicit trigger) That would allow drivers who fail some kind of "oddball" dependency (the firmware load is such as case, there are a few others) to basically install some kind of notifier and try again later when the dependency has been fulfilled. That way existing drivers still behave synchronously, there is no breakage unless drivers are explicitly modified for async probing. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/