[PATCH 2/5] drivercore: Add driver probe deferral mechanism

[Josh Triplett]

On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > +config PROBE_DEFER
> > +	bool "Deferred Driver Probe"
> > +	default y
> > +	help
> > +	  This option provides deferring driver probe if it has dependency on
> > +	  other driver. Without this feature, initcall ordering should be done
> > +	  manually to resolve driver dependencies. This feature completely side
> > +	  steps the issues by allowing driver registration to occur in any
> > +	  order, and any driver can request to be retried after a few more other
> > +	  drivers get probed.
> 
> Why is this even an option?  Why would you ever want it disabled?  Why
> does it need to be selected?
> 
> If you are going to default something to 'y' then just make it so it
> can't be turned off any other way by just not making it an option at
> all.

Given that the drivers which use this mechanism will not necessarily get
built into the kernel, I'd suggest that it should remain optional and
default to n.  Those drivers can then add a dependency on PROBE_DEFER.
Let's try to avoid adding more infrastructure to the kernel that takes
up space even when unused; certainly embedded will appreciate not having
this feature unless a driver needs it.

(That said, it still feels to me like an explicit dependency mechanism
would make more sense than this "try again later" mechanism, but
nonetheless "try again later" seems like an improvement over what we
have now.)

> It also cleans up this diff a lot, as you really don't want #ifdef in .c
> files.

Ideally the entire .c file could become conditional on PROBE_DEFER via
kbuild, with the usual compatibility inlines in a .h file for the
!PROBE_DEFER case.

- Josh Triplett