mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: John Stultz <john.stultz@linaro.org>,
	lkml <linux-kernel@vger.kernel.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Basil Eljuse <Basil.Eljuse@arm.com>,
	Ferry Toth <fntoth@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	Anders Roxell <anders.roxell@linaro.org>
Subject: Re: [PATCH] driver core: Use dev_warn() instead of dev_WARN() for deferred_probe_timeout warnings
Date: Thu, 2 Apr 2020 14:54:29 +0100	[thread overview]
Message-ID: <63eb5197-a683-2103-9b7b-246949601ffd@arm.com> (raw)
In-Reply-To: <20200330202715.86609-1-john.stultz@linaro.org>

On 2020-03-30 9:27 pm, John Stultz wrote:
> In commit c8c43cee29f6 ("driver core: Fix
> driver_deferred_probe_check_state() logic") and following
> changes the logic was changes slightly so that if there is no
> driver to match whats found in the dtb, we wait 30 seconds
> for modules to be loaded by userland, and then timeout, where
> as previously we'd print "ignoring dependency for device,
> assuming no driver" and immediately return -ENODEV after
> initcall_done.
> 
> However, in the timeout case (which previously existed but was
> practicaly un-used without a boot argument), the timeout message
> uses dev_WARN(). This means folks are now seeing a big backtrace
> in their boot logs if there a entry in their dts that doesn't
> have a driver.

I had always figured that timeout case somehow represented more of a 
definite failure than others, but if not then great! :)

> To fix this, lets use dev_warn(), instead of dev_WARN() to match
> the previous error path.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

However, I do now wonder if we really need these two separate cases with 
subtly different messages - after all, giving up at init vs. giving up 
30 seconds later still represents some kind of timeout out either way. 
Given that there are at least 5 underlying situations with varying 
levels of certainty and severity:

- No driver loaded for dependency (yet, if CONFIG_MODULES)
- Driver present and dependency will be probed at some point in future
- Driver present but dependency will not be probed (e.g. disabled in DT)
- Dependency itself is deferred but will be re-probed at some point
- Dependency probed, explicitly failed and will not be retried

then I'm not sure there's much value in having two slightly different 
ways of saying "any of those may have happened".

Robin.

> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Basil Eljuse <Basil.Eljuse@arm.com>
> Cc: Ferry Toth <fntoth@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Anders Roxell <anders.roxell@linaro.org>
> Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic")
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
>   drivers/base/dd.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 06ec0e851fa1..ca1652221c1a 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -267,7 +267,7 @@ int driver_deferred_probe_check_state(struct device *dev)
>   	}
>   
>   	if (!driver_deferred_probe_timeout) {
> -		dev_WARN(dev, "deferred probe timeout, ignoring dependency");
> +		dev_warn(dev, "deferred probe timeout, ignoring dependency");
>   		return -ETIMEDOUT;
>   	}
>   
> 

      parent reply	other threads:[~2020-04-02 13:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 20:27 John Stultz
2020-03-31  6:54 ` Naresh Kamboju
2020-04-02 13:54 ` Robin Murphy [this message]

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=63eb5197-a683-2103-9b7b-246949601ffd@arm.com \
    --to=robin.murphy@arm.com \
    --cc=Basil.Eljuse@arm.com \
    --cc=anders.roxell@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=fntoth@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®