[alsa-devel] [PATCH] [v2] ASoC: cs4270: use the built-in register cache support

[Timur Tabi]

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,
				   WM8904_DEEMPH_MASK, val);


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.

-- 
Timur Tabi
Linux kernel developer at Freescale