[alsa-devel] [PATCH] ASoC: compress: Remove duplicated code
The value of the variable new_name is assigned repeatedly.
Signed-off-by: Peng Donglin pengdonglin137@163.com --- sound/soc/soc-compress.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index 206f36b..2c16f42 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -737,9 +737,6 @@ int snd_soc_new_compress(struct snd_soc_pcm_runtime *rtd, int num) }
/* check client and interface hw capabilities */ - snprintf(new_name, sizeof(new_name), "%s %s-%d", - rtd->dai_link->stream_name, codec_dai->name, num); - if (codec_dai->driver->playback.channels_min) playback = 1; if (codec_dai->driver->capture.channels_min) -- 1.9.1
On Mon, Aug 07, 2017 at 09:18:09PM +0800, Donglin Peng wrote:
The value of the variable new_name is assigned repeatedly.
@@ -737,9 +737,6 @@ int snd_soc_new_compress(struct snd_soc_pcm_runtime *rtd, int num) }
/* check client and interface hw capabilities */
snprintf(new_name, sizeof(new_name), "%s %s-%d",rtd->dai_link->stream_name, codec_dai->name, num);
Are you sure that this is the assignment that should be deleted, and if so why? Note that it's both conditionally and unconditionally assigned later on... Some words in the commit log about why this copy is removed would be helpful.
On 8/7/17 10:07 AM, Mark Brown wrote:
On Mon, Aug 07, 2017 at 09:18:09PM +0800, Donglin Peng wrote:
The value of the variable new_name is assigned repeatedly.
@@ -737,9 +737,6 @@ int snd_soc_new_compress(struct snd_soc_pcm_runtime *rtd, int num) }
/* check client and interface hw capabilities */
snprintf(new_name, sizeof(new_name), "%s %s-%d",rtd->dai_link->stream_name, codec_dai->name, num);Are you sure that this is the assignment that should be deleted, and if so why? Note that it's both conditionally and unconditionally assigned later on... Some words in the commit log about why this copy is removed would be helpful.
Thanks for the report. Yes, the logic escapes me as well, there were two separate changes from Liam and Richard Fitzgerald and I can't figure out why the reassignments of the variable new_name are required.
On Mon, Aug 07, 2017 at 10:28:30AM -0500, Pierre-Louis Bossart wrote:
On 8/7/17 10:07 AM, Mark Brown wrote:
Are you sure that this is the assignment that should be deleted, and if so why? Note that it's both conditionally and unconditionally assigned later on... Some words in the commit log about why this copy is removed would be helpful.
Thanks for the report. Yes, the logic escapes me as well, there were two separate changes from Liam and Richard Fitzgerald and I can't figure out why the reassignments of the variable new_name are required.
I've got a feeling it was people not working and testing against mainline independently trying to fix similar issues and ending up colliding when things went upstream.
On Mon, 2017-08-07 at 16:42 +0100, Mark Brown wrote:
On Mon, Aug 07, 2017 at 10:28:30AM -0500, Pierre-Louis Bossart wrote:
On 8/7/17 10:07 AM, Mark Brown wrote:
Are you sure that this is the assignment that should be deleted, and if so why? Note that it's both conditionally and unconditionally assigned later on... Some words in the commit log about why this copy is removed would be helpful.
Thanks for the report. Yes, the logic escapes me as well, there were two separate changes from Liam and Richard Fitzgerald and I can't figure out why the reassignments of the variable new_name are required.
I've got a feeling it was people not working and testing against mainline independently trying to fix similar issues and ending up colliding when things went upstream.
Yeah, probably Richard and I working on something similar in the past.
Liam
ok, I need to think twice.
On Monday, August 7, 2017, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Mon, 2017-08-07 at 16:42 +0100, Mark Brown wrote:
On Mon, Aug 07, 2017 at 10:28:30AM -0500, Pierre-Louis Bossart wrote:
On 8/7/17 10:07 AM, Mark Brown wrote:
Are you sure that this is the assignment that should be deleted, and
if
so why? Note that it's both conditionally and unconditionally
assigned
later on... Some words in the commit log about why this copy is
removed
would be helpful.
Thanks for the report. Yes, the logic escapes me as well, there were
two
separate changes from Liam and Richard Fitzgerald and I can't figure
out why
the reassignments of the variable new_name are required.
I've got a feeling it was people not working and testing against mainline independently trying to fix similar issues and ending up colliding when things went upstream.
Yeah, probably Richard and I working on something similar in the past.
Liam
participants (4)
-
Donglin Peng -
Liam Girdwood -
Mark Brown -
Pierre-Louis Bossart