diff options
| author | Charles Keepax <[email protected]> | 2018-09-05 15:20:58 +0100 |
|---|---|---|
| committer | Mark Brown <[email protected]> | 2018-09-05 17:11:17 +0100 |
| commit | 3bbf5d34fd4a0c41246290b70338095ae291851b (patch) | |
| tree | fa44737638789c47da02cb3f68029e9eb0af473b /tools/perf/scripts/python/bin | |
| parent | 0b7990e38971da403ce223d8bdc758a817eb72f8 (diff) | |
ASoC: dapm: Move error handling to snd_soc_dapm_new_control_unlocked
Currently DAPM has a lot of similar code to handle errors from
snd_soc_dapm_new_control_unlocked, and much of this code does
not really accurately reflect what the function returns.
Firstly, most places will check for a return value of
-EPROBE_DEFER and silence any error messages in that case. The
one notable exception here being dapm_kcontrol_data_alloc
which does currently print any error messages in the case
of snd_soc_dapm_new_control_unlocked returning NULL or an
error. Additionally the error prints being silenced in these
case are redundant as snd_soc_dapm_new_control_unlocked can
only return -EPROBE_DEFER or NULL when failing.
Secondly, most places will treat a return value of NULL as
an -ENOMEM. This is not correct either since any error except
EPROBE_DEFER will cause a return value of NULL from
snd_soc_dapm_new_control_unlocked.
Centralise this handling and the error messages within
snd_soc_dapm_new_control_unlocked and update the callers
to simply check IS_ERR and return. Note that this update is
slightly simpler in the case of dapm_kcontrol_data_alloc where
that is fairly close to the handling that was already in place.
Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions