From: rishabhb@codeaurora.org
To: rafael@kernel.org
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
psodagud@codeaurora.org, ckadabi@codeaurora.org,
tsoni@codeaurora.org, linux-pm@vger.kernel.org,
Vikram Mulukutla <markivx@codeaurora.org>
Subject: Re: [PATCH v1] dd: Invoke one probe retry cycle after some initcall levels
Date: Fri, 07 Sep 2018 13:34:30 -0700 [thread overview]
Message-ID: <1dfc67f3d7ea8aa3cb556c853d29f822@codeaurora.org> (raw)
In-Reply-To: <1534181989-22536-1-git-send-email-rishabhb@quicinc.com>
On 2018-08-13 10:39, Rishabh Bhatnagar wrote:
> From: Rishabh Bhatnagar <rishabhb@codeaurora.org>
>
> Drivers that are registered at an initcall level may have to
> wait until late_init before the probe deferral mechanism can
> retry their probe functions. It is possible that their
> dependencies were resolved much earlier, in some cases even
> before the next initcall level. Invoke one probe retry cycle
> at every _sync initcall level after subsys initcall, allowing
> these drivers to be probed earlier.
> To give an example many Qualcomm drivers are dependent on the
> regulator and bus driver. Both the regulator and bus driver
> are probed in the subsys_initcall level. Now the probe of bus
> driver requires regulator to be working. If the probe of bus
> driver happens before regulator, then bus driver's probe will
> be deferred and all other device's probes which depend on bus
> driver will also be deferred.
> The impact of this problem is reduced if we have this patch.
>
> Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
> ---
>
> Changes since v0:
> * Remove arch_initcall_sync(deferred_probe_initcall) from patch. This
> is not
> really needed as none of the devices are re-probed in
> arch_initcall_sync
> level.
>
> drivers/base/dd.c | 32 ++++++++++++++++++++++++++------
> 1 file changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 1435d72..9aa41aa 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -224,23 +224,43 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +static void enable_trigger_defer_cycle(void)
> +{
> + driver_deferred_probe_enable = true;
> + driver_deferred_probe_trigger();
> + /*
> + * Sort as many dependencies as possible before the next initcall
> + * level
> + */
> + flush_work(&deferred_probe_work);
> +}
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> * We don't want to get in the way when the bulk of drivers are
> getting probed.
> * Instead, this initcall makes sure that deferred probing is delayed
> until
> - * late_initcall time.
> + * all the registered initcall functions at a particular level are
> completed.
> + * This function is invoked at every *_initcall_sync level.
> */
> static int deferred_probe_initcall(void)
> {
> - driver_deferred_probe_enable = true;
> - driver_deferred_probe_trigger();
> - /* Sort as many dependencies as possible before exiting initcalls */
> - flush_work(&deferred_probe_work);
> + enable_trigger_defer_cycle();
> + driver_deferred_probe_enable = false;
> + return 0;
> +}
> +subsys_initcall_sync(deferred_probe_initcall);
> +fs_initcall_sync(deferred_probe_initcall);
> +device_initcall_sync(deferred_probe_initcall);
> +
> +static int deferred_probe_enable_fn(void)
> +{
> + /* Enable deferred probing for all time */
> + enable_trigger_defer_cycle();
> initcalls_done = true;
> return 0;
> }
> -late_initcall(deferred_probe_initcall);
> +late_initcall(deferred_probe_enable_fn);
>
> /**
> * device_is_bound() - Check if device is bound to a driver
Hi Rafael
Just a reminder about this patch. Let me know if you want me to add/edit
anything else.
-Rishabh
next prev parent reply other threads:[~2018-09-07 20:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-13 17:39 [PATCH v1] dd: Invoke one probe retry cycle after some initcall levels Rishabh Bhatnagar
2018-09-07 20:34 ` rishabhb [this message]
2018-09-09 20:22 ` Rafael J. Wysocki
-- strict thread matches above, loose matches on Subject: below --
2018-08-10 21:52 Rishabh Bhatnagar
2018-08-12 8:26 ` Rafael J. Wysocki
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=1dfc67f3d7ea8aa3cb556c853d29f822@codeaurora.org \
--to=rishabhb@codeaurora.org \
--cc=ckadabi@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=markivx@codeaurora.org \
--cc=psodagud@codeaurora.org \
--cc=rafael@kernel.org \
--cc=tsoni@codeaurora.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.