[PATCH][next] ASoC: codecs: rt298: remove redundant assignment to d_len_code
Variable d_len_code is being initialized to zero and then re-assigned a different value in all the valid cases in the following switch statement. The only place it is not being assigned a value is on the return for a default case and in this case it does not need to be assigned. The initialization is redundant and can be removed.
Signed-off-by: Colin Ian King colin.i.king@gmail.com --- sound/soc/codecs/rt298.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/rt298.c b/sound/soc/codecs/rt298.c index 8fbd25ad9b47..ad3783ade1b5 100644 --- a/sound/soc/codecs/rt298.c +++ b/sound/soc/codecs/rt298.c @@ -789,7 +789,6 @@ static int rt298_hw_params(struct snd_pcm_substream *substream, return -EINVAL; }
- d_len_code = 0; switch (params_width(params)) { /* bit 6:4 Bits per Sample */ case 16:
On Mon, 23 Oct 2023 16:49:17 +0100, Colin Ian King wrote:
Variable d_len_code is being initialized to zero and then re-assigned a different value in all the valid cases in the following switch statement. The only place it is not being assigned a value is on the return for a default case and in this case it does not need to be assigned. The initialization is redundant and can be removed.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: codecs: rt298: remove redundant assignment to d_len_code commit: 91e174fc04b1975b0e4d431a7020779635ff7c05
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (2)
-
Colin Ian King -
Mark Brown