linux-kernel - Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to complete during init

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]

Date:	Thu, 09 May 2013 09:52:35 -0700
From:	Saravana Kannan <skannan@...eaurora.org>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	Ming Lei <tom.leiming@...il.com>,
	Mike Turquette <mturquette@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Liam Girdwood <lrg@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to
 complete during init

On 05/09/2013 04:50 AM, Grant Likely wrote:
> On Thu, May 9, 2013 at 11:07 AM, Ming Lei <tom.leiming@...il.com> wrote:
>> On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan <skannan@...eaurora.org> wrote:
>>>
>>> The most obvious fallback of using late_initcall_sync() also doesn't work
>>> since the deferred probing work initated during late_initcall() is done in
>>> a workqueue. So, frameworks that want to wait for all devices to finish
>>> probing during init will now have to wait for the deferred workqueue to
>>> finish it's work. This patch adds a wait_for_init_deferred_probe_done() API
>>
>> flush_workqueue() has been added in deferred_probe_initcall(), so looks it
>> should be OK for your problem, doesn't it?
>
> It looks like Saravana is using a kernel that already does that based
> on object bb5645e from the diff. So if he is still having problem,
> then there is probably another deferred probe that is triggered after
> the deferred probe lateinitcall is executed. It would be good to know
> what driver is getting deferred past clearing the queue. Or has this
> been rebased from an earlier kernel? It may no longer be necessary.

Sorry, it was mindless rebase late at night. I missed the addition of 
the flush_workqueue(). That takes care of my immediate needs. Sorry for 
wasting your time.

But the other patches to move clock and regulator calls to 
late_init_sync should still be necessary. Right? Or are we going to 
depend on the Makefile ordering to determine the order of the lateinit 
calls? (I would rather not).

But the rest of the discussion is still interesting and relevant and 
something I would like to see resolved too. I'll reply to that part of 
the discussion in one of the later emails.

Thanks,
Saravana

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/