On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > We have no explicit semantics to check if a driver / subsystem > > supports deferred probe. > > Why would we need such a thing?
It depends on the impact of a driver/subsystem not properly supporting deffered probe, if this is no-op then such a need is not critical but would be good to proactively inform developers / users so they avoid its use, if this will cause issues its perhaps best to make this a no-op through a check. AFAICT reviewing implications of not supporting deferred probe on drivers/subsytsems for this framework is not clearly spelled out, if we start considering re-using this framework for probe ordering I'd hate to see issues come up without this corner case being concretely considered. Furthermore -- how does this framework compare to Andrzej's resource tracking solution? I confess I have not had a chance yet to review yet but in light of this question it would be good to know if Andrzej's framework also requires deferred probe as similar concerns would exist there as well. Luis
