From: Mark Brown <broonie@kernel.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-kernel@lists.codethink.co.uk, alsa-devel@alsa-project.org,
Lars-Peter Clausen <lars@metafoo.de>,
kuninori.morimoto.gx@renesas.com, lgirdwood@gmail.com,
Ben Dooks <ben.dooks@codethink.co.uk>
Subject: Re: [PATCH] ak4642: show error if register write fails
Date: Tue, 11 Mar 2014 18:44:37 +0000 [thread overview]
Message-ID: <20140311184437.GV28112@sirena.org.uk> (raw)
In-Reply-To: <s5heh2822dm.wl%tiwai@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1262 bytes --]
On Tue, Mar 11, 2014 at 04:15:01PM +0100, Takashi Iwai wrote:
> This should be decided for each case, and I agree with the usefulness
> of error logging for this particular case. The I/O errors are
> basically exceptions, and shouldn't happen in normal operations.
Quite.
> That said, if the driver behavior depends on such lowlevel errors,
> its design is wrong, must be fixed in anyway.
Indeed, this shouldn't be something that happens in normal operation.
Usually you'd see this during board bringup if you'd got something like
I2C, regulators or reset GPIOs hooked up wrongly or missing, though you
can see things like incorrectly handled ramp or reset times triggering
it too. By the time the system is actually in use it shouldn't happen
which is why we've not been having problems with ignoring errors.
> Still an open question is whether it should be dev_err() or
> dev_dbg(). Ideally speaking, dev_dbg() should be used, while
> dev_err() would be more practical.
I think given that it's generally a sign of substantial hardware failure
dev_err() is justified, probably the user will be noticing other issues
and it'll help a lot with root causing. I'd guess Ben had something
like one of the situations above and needed this to figure it out.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2014-03-11 18:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 18:15 [PATCH] ak4642: show error if register write fails Ben Dooks
2014-03-10 23:40 ` Mark Brown
2014-03-11 11:18 ` Ben Dooks
2014-03-11 11:21 ` Mark Brown
2014-03-11 13:59 ` Lars-Peter Clausen
2014-03-11 14:17 ` Ben Dooks
2014-03-11 14:20 ` Lars-Peter Clausen
2014-03-11 14:21 ` Mark Brown
2014-03-11 15:15 ` Takashi Iwai
2014-03-11 18:44 ` Mark Brown [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=20140311184437.GV28112@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=ben.dooks@codethink.co.uk \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@lists.codethink.co.uk \
--cc=tiwai@suse.de \
/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