public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <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: Mon, 5 Mar 2012 14:15:28 -0800	[thread overview]
Message-ID: <20120305221528.GA11935@kroah.com> (raw)
In-Reply-To: <CACxGe6samH6-o9Ye7h7Wpj8GztxvFpWDgcEvtx2ey+YRGYm_9g@mail.gmail.com>

On Mon, Mar 05, 2012 at 03:09:27PM -0700, Grant Likely wrote:
> On Mon, Mar 5, 2012 at 2:47 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Mar 05, 2012 at 08:47:41AM -0700, Grant Likely wrote:
> >> --- a/include/linux/device.h
> >> +++ b/include/linux/device.h
> >> @@ -587,6 +587,10 @@ struct device_dma_parameters {
> >>   * @mutex:   Mutex to synchronize calls to its driver.
> >>   * @bus:     Type of bus device is on.
> >>   * @driver:  Which driver has allocated this
> >> + * @deferred_probe: entry in deferred_probe_list which is used to retry the
> >> + *           binding of drivers which were unable to get all the resources
> >> + *           needed by the device; typically because it depends on another
> >> + *           driver getting probed first.
> >>   * @platform_data: Platform data specific to the device.
> >>   *           Example: For devices on custom boards, as typical of embedded
> >>   *           and SOC based hardware, Linux often uses platform_data to point
> >> @@ -646,6 +650,7 @@ struct device {
> >>       struct bus_type *bus;           /* type of bus device is on */
> >>       struct device_driver *driver;   /* which driver has allocated this
> >>                                          device */
> >> +     struct list_head        deferred_probe;
> >>       void            *platform_data; /* Platform specific data, device
> >>                                          core doesn't touch it */
> >>       struct dev_pm_info      power;
> >
> > This can go into the "struct device_private" structure instead, right?
> > That would be better to ensure that no non-driver-core code ever touches
> > this thing.
> 
> I don't see any reason why not.  I'll make the change and repost.

If you are going to repost, care to fix up your multi-line comment
blocks to follow the "standard" way of doing it?

That saves me doing the follow-on patch to do it myself :)

thanks,

greg k-h

  reply	other threads:[~2012-03-05 22:16 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 [this message]
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
  -- 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=20120305221528.GA11935@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox