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.