Messages in this thread | | | From | Grant Likely <> | Date | Tue, 6 Mar 2012 00:52:12 -0700 | Subject | Re: [PATCH] drivercore: Add driver probe deferral mechanism |
| |
On Mon, Mar 5, 2012 at 10:28 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > 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@linuxfoundation.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@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 :) >> >> 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.
Alright; that works for me. :-)
g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |