From: Ryan Mallon <rmallon@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Axel Lin <axel.lin@gmail.com>,
linux-kernel@vger.kernel.org, Liam Girdwood <lrg@ti.com>,
alsa-devel@alsa-project.org,
Peter Hsiang <peter.hsiang@maxim-ic.com>,
Jesse Marroquin <jesse.marroquin@maxim-ic.com>
Subject: Re: [PATCH 1/2] ASoC: Add BUG() assertion if max98088_get_channel returns -EINVAL
Date: Thu, 29 Sep 2011 21:28:39 +1000 [thread overview]
Message-ID: <4E845667.3050404@gmail.com> (raw)
In-Reply-To: <20110929103413.GK3697@opensource.wolfsonmicro.com>
On 29/09/11 20:34, Mark Brown wrote:
> On Thu, Sep 29, 2011 at 09:15:03AM +1000, Ryan Mallon wrote:
>> On 29/09/11 00:01, Axel Lin wrote:
>>> The callers use the return value of max98088_get_channel as array index to
>>> access max98088->dai[] array.
>>> Add BUG() assertion for out of bound access of max98088->dai[] array.
>> BUG() is pretty heavy handed for a driver. Why not fix the problem
>> properly in the callers?
> There's nothing constructive that any of the callers can do with an
> error code - it's a clear bug in something (probably the driver) if we
> get called for a bad control. Simply returning an error code isn't
> terribly helpful, it's very obscure what's gone wrong and why. We at
> least need a log message.
Yeah, it can basically only happen if there is a mismatch between the
kcontrol definition and the get_channel function in the driver. Would
you be happy with adding a:
dev_err(codec->dev, "Bad kcontrol channel name\n");
and then returning the error? It doesn't seem worth panicking the whole
driver/system for a bug like this.
~Ryan
next prev parent reply other threads:[~2011-09-29 11:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 14:01 [PATCH 1/2] ASoC: Add BUG() assertion if max98088_get_channel returns -EINVAL Axel Lin
2011-09-28 14:02 ` [PATCH 2/2] ASoC: Add BUG() assertion if max98095_get_bq_channel " Axel Lin
2011-09-28 23:19 ` Ryan Mallon
2011-09-29 1:35 ` Dave Young
2011-09-29 1:52 ` Ryan Mallon
2011-09-29 1:59 ` Dave Young
2011-09-29 2:01 ` Ryan Mallon
2011-09-29 2:06 ` Dave Young
2011-09-29 1:33 ` Dave Young
2011-09-28 23:15 ` [PATCH 1/2] ASoC: Add BUG() assertion if max98088_get_channel " Ryan Mallon
2011-09-29 10:34 ` Mark Brown
2011-09-29 11:28 ` Ryan Mallon [this message]
2011-09-29 23:13 ` Ryan Mallon
2011-09-30 12:56 ` 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=4E845667.3050404@gmail.com \
--to=rmallon@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=axel.lin@gmail.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=jesse.marroquin@maxim-ic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=peter.hsiang@maxim-ic.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.