From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: Oder Chiou <oder_chiou@realtek.com>,
alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH] ASoC: rl6347a: Use dev_err_once for I2C communication error prints
Date: Fri, 7 Oct 2016 10:47:12 +0300 [thread overview]
Message-ID: <48e5d022-c7c1-93b9-8b52-7890efe944a5@linux.intel.com> (raw)
In-Reply-To: <20161006162624.bvnn2s7u7s2uex6j@sirena.org.uk>
On 10/06/2016 07:26 PM, Mark Brown wrote:
> On Wed, Oct 05, 2016 at 05:05:36PM +0300, Jarkko Nikula wrote:
>
>> It's difficult to guess from bunch of "ret=-121" errors what driver and
>> device actually caused them. Since struct i2c_client has the dev pointer
>> use that for dev_err_once() in order to see the device and not spam the
>> log needlessly.
>
> dev_err() is obviously an improvement (as would a better message be) but
> dev_err_once() seems like a big jump that we don't normally do for our
> I/O errors - transient errors do happen from time to time (especially
> when people get their power up sequences wrong) and it can be useful to
> know if something is just dead, failed gradually over time or just had a
> single transient error. It's also helpful since a lot of the errors
> that do occur result in long timeouts so it's not always clear that
> we're grinding through lots of I/Os if we don't say anything. Am I
> missing something about this case?
>
You are right. This looks like it is either due HW issue or pincontrol
misconfiguration after resume and device starts making interrupt storm
and acknowledging them fails before I2C is resumed. I switch it to
dev_err().
--
Jarkko
prev parent reply other threads:[~2016-10-07 7:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20161005140536.12166-1-jarkko.nikula@linux.intel.com>
2016-10-06 16:26 ` [PATCH] ASoC: rl6347a: Use dev_err_once for I2C communication error prints Mark Brown
2016-10-07 7:47 ` Jarkko Nikula [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=48e5d022-c7c1-93b9-8b52-7890efe944a5@linux.intel.com \
--to=jarkko.nikula@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=oder_chiou@realtek.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;
as well as URLs for NNTP newsgroup(s).