linux-kernel - Re: [PATCH] drivercore: Add driver probe deferral mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACxGe6uQCUGyj4ib7da0iTSWRcGGRftO1WzpUOKkbgfL84Ojjw@mail.gmail.com>
Date:	Tue, 6 Mar 2012 00:52:12 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 5, 2012 at 10:28 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.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@...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.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/