All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Arnd Bergmann <arnd@arndb.de>, Dilan Lee <dilee@nvidia.com>,
	Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism
Date: Thu, 8 Mar 2012 12:22:18 -0800	[thread overview]
Message-ID: <20120308202218.GA31918@kroah.com> (raw)
In-Reply-To: <1330962461-9061-1-git-send-email-grant.likely@secretlab.ca>

On Mon, Mar 05, 2012 at 08:47:41AM -0700, Grant Likely wrote:
> Allow drivers to report at probe time that they cannot get all the resources
> required by the device, and should be retried at a later time.
> 
> This should completely solve the problem of getting devices
> initialized in the right order.  Right now this is mostly handled by
> mucking about with initcall ordering which is a complete hack, and
> doesn't even remotely handle the case where device drivers are in
> modules.  This approach completely sidesteps 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.
> 
> v4: - Integrate Manjunath's addition of a separate workqueue
>     - Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
>     - Update comment blocks to reflect how the code really works
> v3: - Hold off workqueue scheduling until late_initcall so that the bulk
>       of driver probes are complete before we start retrying deferred devices.
>     - Tested with simple use cases.  Still needs more testing though.
>       Using it to get rid of the gpio early_initcall madness, or to replace
>       the ASoC internal probe deferral code would be ideal.
> v2: - added locking so it should no longer be utterly broken in that regard
>     - remove device from deferred list at device_del time.
>     - Still completely untested with any real use case, but has been
>       boot tested.

Now applied, thanks for pushing this and seeing it through.

greg k-h

  parent reply	other threads:[~2012-03-08 20:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05 15:47 [PATCH] drivercore: Add driver probe deferral mechanism Grant Likely
2012-03-05 17:38 ` Alan Cox
2012-03-05 17:40 ` David Daney
2012-03-05 17:50 ` Mark Brown
2012-03-05 19:15 ` Arnd Bergmann
2012-03-05 21:10   ` Grant Likely
2012-03-05 21:24     ` Greg Kroah-Hartman
2012-03-05 21:28       ` Mark Brown
2012-03-06  9:10     ` Arnd Bergmann
2012-03-05 21:47 ` Greg Kroah-Hartman
2012-03-05 22:09   ` Grant Likely
2012-03-05 22:15     ` Greg Kroah-Hartman
2012-03-06  0:08       ` Grant Likely
2012-03-06  5:28         ` Greg Kroah-Hartman
2012-03-06  7:52           ` Grant Likely
2012-03-08 20:22 ` Greg KH [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-07-04 17:11 Grant Likely
2011-07-04 17:41 ` Greg KH
2011-07-04 17:56   ` Mark Brown
2011-07-04 18:01   ` Grant Likely
2011-07-05 14:21     ` Greg KH
2011-07-05 15:21       ` Arnd Bergmann
2011-07-05 15:50         ` Greg KH
2011-07-05 16:05           ` Arnd Bergmann
2011-07-05 16:27             ` Grant Likely
2011-07-05 16:11           ` Kay Sievers
2011-07-05 16:28             ` Grant Likely
2011-07-05 16:36               ` Greg KH
2011-07-05 17:17                 ` Grant Likely
2011-07-05 17:29                   ` Greg KH
2011-07-05 17:35                     ` Grant Likely
2011-07-10 14:24               ` Kay Sievers
2011-07-05 16:33             ` Grant Likely
2011-07-05 16:05       ` Grant Likely
2011-07-04 19:56 ` Randy Dunlap
2011-07-04 20:47 ` Mark Brown
2011-07-04 23:25   ` Grant Likely
2011-07-05  6:11     ` Mark Brown

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=20120308202218.GA31918@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dilee@nvidia.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manjunath.gkondaiah@linaro.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tony@atomide.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.