[alsa-devel] [PATCH] [v2] ASoC: cs4270: use the built-in register cache support
timur at freescale.com
Mon Jan 10 18:35:50 CET 2011
Dimitris Papastamos wrote:
> There's not much that can be done for error recovery at that point.
> Usually a failing snd_soc_read()/snd_soc_write() will complain wildly
> with errors from the underlying bus. The only place that
> snd_soc_read()/snd_soc_write() are checked for errors is usually in
> _probe() functions.
I did a little digging, and I found something of concern, but I'm not sure if
there's a real problem.
On the surface, it appears that all current callers of snd_soc_update_bits() can
handle a negative return code. In fact, a lot of existing code already assumes
that it does return error codes.
My concern is that there may be some higher-level function that is *not*
expecting a return value of 1 from snd_soc_update_bits(). For example, take
wm8904_put_deemph(). This function calls wm8904_set_deemph(), which ends with this:
return snd_soc_update_bits(codec, WM8904_DAC_DIGITAL_1,
This doesn't seem right to me. Here, the .put function returns 0 or 1,
depending on whether or not the bits were actually updated. Is that what's
intended? I can't find any documentation that tells me what the return values
of snd_kcontrol_put_t are supposed to be.
Linux kernel developer at Freescale
More information about the Alsa-devel