[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120306052849.GC19454@kroah.com>
Date: Mon, 5 Mar 2012 21:28:49 -0800
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: linux-kernel@...r.kernel.org, Tony Lindgren <tony@...mide.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Arnd Bergmann <arnd@...db.de>, Dilan Lee <dilee@...dia.com>,
Manjunath GKondaiah <manjunath.gkondaiah@...aro.org>,
Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism
On Mon, Mar 05, 2012 at 05:08:30PM -0700, Grant Likely wrote:
> On Mon, Mar 5, 2012 at 3:15 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > 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@...uxfoundation.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 :)
>
> Yeah, I can do that.
>
> Actually, if you're okay with this version other than the private data
> change, could you pick up this version (it's actually received
> testing) and I'll provide follow up patches to fix up the issues
> pointed out by you and Arnd.
Yes, I can, and I might as well fix up the private thing myself and the
comments when I do that, I'll cc: you on that. I have a flight tomorrow
so I might get the chance to do it then.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists