All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH 1/1] ASoC: core: Do not print an actual error when deferring probe
Date: Thu, 19 May 2016 08:53:31 +0200	[thread overview]
Message-ID: <s5hinyazggk.wl-tiwai@suse.de> (raw)
In-Reply-To: <2608815.76PS7RUNga@ws-stein>

On Thu, 19 May 2016 08:28:02 +0200,
Alexander Stein wrote:
> 
> On Wednesday 18 May 2016 21:33:01, Takashi Iwai wrote:
> > On Wed, 18 May 2016 19:20:19 +0200,
> > 
> > Mark Brown wrote:
> > > On Wed, May 18, 2016 at 06:57:50PM +0200, Takashi Iwai wrote:
> > > > Mark Brown wrote:
> > > > > It's just shifting the problem around...  it sounds like for your use
> > > > > case suppressing the messages until we finish kernel boot would deal
> > > > > with most of the issue in a far more general fashion.
> > > > 
> > > > It comes to the question whether this message must be shown verbosely
> > > > as an error at all.  EPROBE_DEFER is usually a mechanism for the
> > > > delayed probe, and it doesn't indicate an error per se.  dev_err() is,
> > > > OTOH, for real errors that have to be notified to user inevitably.
> > > > That's why "quiet" boot option still shows it.
> > > 
> > > We can't tell the difference between something that's delayed and will
> > > come up later and something that's just never going to work - missing
> > > or misidentified components has always been a common source of errors
> > > in ASoC device bringup.
> > 
> > Yes, but it still means that most of cases are false-positive to show
> > as "error" message.
> 
> I think the same way. Of course it is an error if probing never finishes due 
> to some missing configuration/dt entry, but that needs to be checked in dmesg 
> anyway. dev_notice still allows that.
> 
> > > There's also just the fact that the noise from
> > > deferred probe is not an ASoC specific thing, we need to tackle this at
> > > a system level rather than hacking individual cases.
> > 
> > Such other noises are usually now shown as errors with dev_err() but
> > with dev_*() with a lower level.
> > 
> > I guess the patch subject and description are misleading.  This
> > doesn't suppress the messages to be printed.  In usual boots without
> > quiet boot option, there will be no visible change with this patch,
> > the messages are still shown.  It's not shown, however, when booted
> > with quiet boot option.  That's the whole point.
> > 
> > dev_notice() lowers the log level to somewhat between info and
> > warning, and it looks like a sensible choice to me.
> 
> You want me to change the subject to be more clear?

If the patch can go in, yes.  The changelog text should be also
clearer why it's needed and what it gives, too.


Takashi

  reply	other threads:[~2016-05-19  6:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18 13:41 [PATCH 1/1] ASoC: core: Do not print an actual error when deferring probe Alexander Stein
2016-05-18 14:25 ` Ricard Wanderlof
2016-05-18 15:08 ` Mark Brown
2016-05-18 15:18   ` Alexander Stein
2016-05-18 15:28     ` Mark Brown
2016-05-18 15:50       ` Alexander Stein
2016-05-18 16:21         ` Mark Brown
2016-05-18 16:57           ` Takashi Iwai
2016-05-18 17:20             ` Mark Brown
2016-05-18 19:33               ` Takashi Iwai
2016-05-19  6:28                 ` Alexander Stein
2016-05-19  6:53                   ` Takashi Iwai [this message]
2016-05-19 10:34                     ` Mark Brown

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=s5hinyazggk.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alexander.stein@systec-electronic.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.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 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.