public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Greg KH <greg@kroah.com>
Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>,
	linux-arm-kernel@lists.infradead.org,
	Grant Likely <grant.likely@secretlab.ca>,
	linux-omap@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Dilan Lee <dilee@nvidia.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Manjunath@jasper.es
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
Date: Fri, 7 Oct 2011 13:57:15 -0700	[thread overview]
Message-ID: <20111007205715.GC5275@leaf> (raw)
In-Reply-To: <20111007064928.GE27508@kroah.com>

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

  reply	other threads:[~2011-10-07 20:57 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-07  5:33 [PATCH 0/5] Driver Probe Deferral Mechanism G, Manjunath Kondaiah
2011-10-07  5:33 ` [PATCH 1/5] drivercore: add new error value for deferred probe G, Manjunath Kondaiah
2011-10-07  6:43   ` Greg KH
2011-10-07 10:00     ` Mark Brown
2011-10-07 22:12     ` Grant Likely
2011-10-07 23:28       ` Valdis.Kletnieks
2011-10-08  0:12         ` Greg KH
2011-10-09 22:59           ` Grant Likely
2011-10-10  1:06             ` Greg KH
2011-10-12  6:18               ` G, Manjunath Kondaiah
2011-10-13  4:10                 ` Grant Likely
2011-10-07  5:33 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism G, Manjunath Kondaiah
2011-10-07  6:49   ` Greg KH
2011-10-07 20:57     ` Josh Triplett [this message]
2011-10-07 21:23       ` Greg KH
2011-10-08  4:03         ` Josh Triplett
2011-10-08 15:55           ` Greg KH
2011-10-08 18:18             ` Josh Triplett
2011-10-10 17:37             ` Andrei Warkentin
2011-10-11 12:29               ` Ming Lei
2011-10-13  4:09                 ` Grant Likely
2011-10-13 14:18                   ` Ming Lei
2011-10-13 14:31                     ` Alan Stern
2011-10-13 15:21                       ` Ming Lei
2011-10-13 16:04                         ` Alan Stern
2011-10-14  0:13                           ` Ming Lei
2011-10-13 17:15                       ` Grant Likely
2011-10-13 18:16                         ` Alan Stern
2011-10-13 18:28                           ` Grant Likely
2011-10-14 15:39                             ` Alan Stern
2011-10-14 16:17                               ` Grant Likely
2011-10-14 16:33                                 ` Alan Stern
2011-10-14 17:20                                   ` Grant Likely
2011-10-14 17:33                                     ` Alan Stern
2011-10-14 18:25                                       ` Grant Likely
2011-10-14 18:39                                         ` Alan Stern
2011-10-14 19:07                                           ` Grant Likely
2011-10-14 18:56                                     ` David Daney
2011-10-14 19:03                                       ` Grant Likely
2011-10-14 19:09                                         ` David Daney
2011-10-14 15:37                         ` Alan Stern
2011-10-12  7:04               ` G, Manjunath Kondaiah
2011-10-07 21:28     ` Grant Likely
2011-10-07  5:33 ` [PATCH 3/5] regulator: Support driver probe deferral G, Manjunath Kondaiah
2011-10-07  5:33 ` [PATCH 4/5] gpiolib: handle deferral probe error G, Manjunath Kondaiah
2011-10-07 10:06   ` Alan Cox
2011-10-07 22:09     ` Grant Likely
2011-10-12  6:14       ` G, Manjunath Kondaiah
2011-10-13  4:12         ` Grant Likely
2011-10-07  5:33 ` [PATCH 5/5] omap: hsmmc: use platform_driver_register G, Manjunath Kondaiah
2011-10-07  6:50 ` [PATCH 0/5] Driver Probe Deferral Mechanism Greg KH
2011-10-07  7:37   ` G, Manjunath Kondaiah
  -- strict thread matches above, loose matches on Subject: below --
2011-10-07  5:05 G, Manjunath Kondaiah
2011-10-07  5:05 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism G, Manjunath Kondaiah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111007205715.GC5275@leaf \
    --to=josh@joshtriplett.org \
    --cc=Manjunath@jasper.es \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dilee@nvidia.com \
    --cc=grant.likely@secretlab.ca \
    --cc=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=manjugk@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox