summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/proc.py
diff options
context:
space:
mode:
authorKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2021-02-22 09:47:36 +0900
committerMark Brown <broonie@kernel.org>2021-03-10 13:06:48 +0000
commit4fe28461e289e7209dc969d5878997069f5be157 (patch)
treec11b13acb705fc59af762ea1d36231c4a4b69bda /scripts/gdb/linux/proc.py
parent1b8cb123f3dd6f205541299e2a573237452a6ffe (diff)
ASoC: soc-pcm: unpack dpcm_set_fe_runtime()
dpcm_fe_dai_startup() (= A) calls dpcm_set_fe_runtime() (= B) to setup DPCM runtime. From *naming point of view*, it sounds like setup function for FE. (A) static int dpcm_fe_dai_startup(...) { ... (B) dpcm_set_fe_runtime(...); ... } But in dpcm_set_fe_runtime() (= B), It setups FE by dpcm_runtime_setup_fe() (= X), and setups BE by dpcm_runtime_merge_xxx() (= Y). (B) static void dpcm_set_fe_runtime(...) { ... (X) dpcm_runtime_setup_fe(...); ^ dpcm_runtime_setup_be_format(...); (Y) dpcm_runtime_setup_be_chan(...); v dpcm_runtime_setup_be_rate(...); } These means that the function which is called as xxx_fe_xxx() is setups both FE and BE. This is confusable and can be hot bed for bug. Now dpcm_set_fe_runtime() (= B) is simple enough and confusable naming, let's unpack it at dpcm_fe_dai_startup(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87mtvxvsgn.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/proc.py')
0 files changed, 0 insertions, 0 deletions