dump_config_tree() is declared to return an int, but the compiler cannot prove that it always returns any value at all. This leads to a clang warning, when building via:
make LLVM=1 -C tools/testing/selftests
Furthermore, Mark Brown noticed that dump_config_tree() isn't even used anymore, so just delete the entire function.
Cc: Mark Brown broonie@kernel.org Signed-off-by: John Hubbard jhubbard@nvidia.com --- tools/testing/selftests/alsa/conf.c | 13 ------------- 1 file changed, 13 deletions(-)
diff --git a/tools/testing/selftests/alsa/conf.c b/tools/testing/selftests/alsa/conf.c index 89e3656a042d..357561c1759b 100644 --- a/tools/testing/selftests/alsa/conf.c +++ b/tools/testing/selftests/alsa/conf.c @@ -105,19 +105,6 @@ static struct card_cfg_data *conf_data_by_card(int card, bool msg) return NULL; }
-static int dump_config_tree(snd_config_t *top) -{ - snd_output_t *out; - int err; - - err = snd_output_stdio_attach(&out, stdout, 0); - if (err < 0) - ksft_exit_fail_msg("stdout attach\n"); - if (snd_config_save(top, out)) - ksft_exit_fail_msg("config save\n"); - snd_output_close(out); -} - snd_config_t *conf_load_from_file(const char *filename) { snd_config_t *dst;
base-commit: f462ae0edd3703edd6f22fe41d336369c38b884b prerequisite-patch-id: b901ece2a5b78503e2fb5480f20e304d36a0ea27
On Sun, May 05, 2024 at 02:08:24PM -0700, John Hubbard wrote:
dump_config_tree() is declared to return an int, but the compiler cannot prove that it always returns any value at all. This leads to a clang warning, when building via:
Reviewed-by: Mark Brown broonie@kernel.org
On Sun, 05 May 2024 23:08:24 +0200, John Hubbard wrote:
dump_config_tree() is declared to return an int, but the compiler cannot prove that it always returns any value at all. This leads to a clang warning, when building via:
make LLVM=1 -C tools/testing/selftestsFurthermore, Mark Brown noticed that dump_config_tree() isn't even used anymore, so just delete the entire function.
Cc: Mark Brown broonie@kernel.org Signed-off-by: John Hubbard jhubbard@nvidia.com
Thanks, applied now.
Takashi
On 06. 05. 24 9:19, Takashi Iwai wrote:
On Sun, 05 May 2024 23:08:24 +0200, John Hubbard wrote:
dump_config_tree() is declared to return an int, but the compiler cannot prove that it always returns any value at all. This leads to a clang warning, when building via:
make LLVM=1 -C tools/testing/selftestsFurthermore, Mark Brown noticed that dump_config_tree() isn't even used anymore, so just delete the entire function.
Cc: Mark Brown broonie@kernel.org Signed-off-by: John Hubbard jhubbard@nvidia.com
Thanks, applied now.
This function is nice for debugging. I'd prefer to keep it with the fix.
Jaroslav
On Mon, 06 May 2024 09:27:38 +0200, Jaroslav Kysela wrote:
On 06. 05. 24 9:19, Takashi Iwai wrote:
On Sun, 05 May 2024 23:08:24 +0200, John Hubbard wrote:
dump_config_tree() is declared to return an int, but the compiler cannot prove that it always returns any value at all. This leads to a clang warning, when building via:
make LLVM=1 -C tools/testing/selftestsFurthermore, Mark Brown noticed that dump_config_tree() isn't even used anymore, so just delete the entire function.
Cc: Mark Brown broonie@kernel.org Signed-off-by: John Hubbard jhubbard@nvidia.com
Thanks, applied now.
This function is nice for debugging. I'd prefer to keep it with the fix.
I'm find in either way; just submit a fix patch, then.
thanks,
Takashi
On Mon, May 06, 2024 at 09:45:21AM +0200, Takashi Iwai wrote:
Jaroslav Kysela wrote:
This function is nice for debugging. I'd prefer to keep it with the fix.
I'm find in either way; just submit a fix patch, then.
The fix was already submitted as v1, I noticed that the function was unused in review.
On 5/6/24 7:44 AM, Mark Brown wrote:
On Mon, May 06, 2024 at 09:45:21AM +0200, Takashi Iwai wrote:
Jaroslav Kysela wrote:
This function is nice for debugging. I'd prefer to keep it with the fix.
I'm find in either way; just submit a fix patch, then.
The fix was already submitted as v1, I noticed that the function was unused in review.
It's generally considered a best practice to delete unused code. If there is something you especially like for upcoming code, you still have git history, and even a lore.kernel.org link, to bookmark it.
So I'd recommend going with v2, but of course it's your call! :)
thanks,
linux-kselftest-mirror@lists.linaro.org
-
Jaroslav Kysela -
John Hubbard -
Mark Brown -
Takashi Iwai