From: Lars-Peter Clausen <lars@metafoo.de>
To: Ben Dooks <ben.dooks@codethink.co.uk>
Cc: linux-kernel@lists.codethink.co.uk, alsa-devel@alsa-project.org,
Mark Brown <broonie@kernel.org>,
lgirdwood@gmail.com, kuninori.morimoto.gx@renesas.com
Subject: Re: [PATCH] ak4642: show error if register write fails
Date: Tue, 11 Mar 2014 15:20:11 +0100 [thread overview]
Message-ID: <531F1B9B.5050400@metafoo.de> (raw)
In-Reply-To: <531F1ADE.3000409@codethink.co.uk>
On 03/11/2014 03:17 PM, Ben Dooks wrote:
> On 11/03/14 13:59, Lars-Peter Clausen wrote:
>> On 03/11/2014 12:21 PM, Mark Brown wrote:
>>> On Tue, Mar 11, 2014 at 11:18:30AM +0000, Ben Dooks wrote:
>>>> On 10/03/14 23:40, Mark Brown wrote:
>>>
>>>>> Two things here. One is that this should be a dev_err() and the other
>>>>> is that if this is worth doing shouldn't it just be in the core - I see
>>>>> nothing driver specific here?
>>>
>>>> Sorry, didn't see a device in "struct snd_soc_codec *codec" so I went
>>>> for a printk (although it was pr_info instead of pr_err).
>>>
>>> codec->dev.
>>>
>>>> If you think that changing the two snd_soc calls to print errors
>>>> when anything bad happens then that would also be a good idea then
>>>> I can send a patch for that.
>>>
>>> That would be better, yes.
>>
>> In my opinion it's better to pass the error on to the upper levels. E.g.
>> if userspace opens the PCM device and there is an IO error in the
>> startup callback then that error should be passed on to the userspace
>> application rather than doing a out of band error reporting and adding a
>> entry to the kernel log.
>
> From a grep, there doesn't seem to be much in the way of error
> checking in a number of the codec drivers.
>
>
That doesn't mean it's the right thing to do no error checking ;)
next prev parent reply other threads:[~2014-03-11 14:25 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 [this message]
2014-03-11 14:21 ` Mark Brown
2014-03-11 15:15 ` Takashi Iwai
2014-03-11 18:44 ` 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=531F1B9B.5050400@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=ben.dooks@codethink.co.uk \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@lists.codethink.co.uk \
/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.