linux-stable.git/tools/testing/selftests/alsa, branch linux-6.5.y

selftests: ALSA: Add test-pcmtest-driver to .gitignore

2023-07-19T13:25:03+00:00

It was forgotten to add the new binary to .gitignore.  Let's fix it.

Fixes: 10b98a4db11a ("selftests: ALSA: Add test for the 'pcmtest' driver")
Link: https://lore.kernel.org/r/20230719114336.18409-1-tiwai@suse.de
Signed-off-by: Takashi Iwai

selftests: ALSA: Fix fclose on an already fclosed file pointer

2023-07-13T06:08:08+00:00

In the case where a sysfs file cannot be opened the error return path
fcloses file pointer fpl, however, fpl has already been closed in the
previous stanza. Fix the double fclose by removing it.

Fixes: 10b98a4db11a ("selftests: ALSA: Add test for the 'pcmtest' driver")
Signed-off-by: Colin Ian King 
Reviewed-by: Mark Brown 
Link: https://lore.kernel.org/r/20230712140122.457206-1-colin.i.king@gmail.com
Signed-off-by: Takashi Iwai

Merge branch 'for-next' into for-linus

2023-06-26T13:23:23+00:00

Pull the 6.5-devel branch for upstreaming.

Signed-off-by: Takashi Iwai

selftests: ALSA: Add test for the 'pcmtest' driver

2023-06-07T11:09:03+00:00

This test covers the new Virtual PCM Test Driver, including the capturing,
playback and ioctl redefinition functionalities for both interleaved and
non-interleaved access modes. This test is also helpful as an usage example
of the 'pcmtest' driver.

We have a lot of different virtual media drivers, which can be used for
testing of the userspace applications and media subsystem middle layer.
However, all of them are aimed at testing the video functionality and
simulating the video devices. For audio devices we have only snd-dummy
module, which is good in simulating the correct behavior of an ALSA device.
I decided to write a tool, which would help to test the userspace ALSA
programs (and the PCM middle layer as well) under unusual circumstances
to figure out how they would behave. So I came up with this Virtual PCM
Test Driver.

This new Virtual PCM Test Driver has several features which can be useful
during the userspace ALSA applications testing/fuzzing, or testing/fuzzing
of the PCM middle layer. Not all of them can be implemented using the
existing virtual drivers (like dummy or loopback). Here is what can this
driver do:

- Simulate both capture and playback processes
- Generate random or pattern-based capture data
- Check the playback stream for containing the looped pattern
- Inject delays into the playback and capturing processes
- Inject errors during the PCM callbacks

Also, this driver can check the playback stream for containing the
predefined pattern, which is used in the corresponding selftest to check
the PCM middle layer data transferring functionality. Additionally, this
driver redefines the default RESET ioctl, and the selftest covers this PCM
API functionality as well.

The driver supports both interleaved and non-interleaved access modes, and
have separate pattern buffers for each channel. The driver supports up to
4 channels and up to 8 substreams.

Signed-off-by: Ivan Orlov 
Acked-by: Jaroslav Kysela 
Link: https://lore.kernel.org/r/20230606193254.20791-3-ivan.orlov0322@gmail.com
Signed-off-by: Takashi Iwai

selftests: alsa: pcm-test: Fix compiler warnings about the format

2023-06-05T07:15:42+00:00

GCC 11.3.0 issues warnings in this module about wrong sizes of format
specifiers:

pcm-test.c: In function ‘test_pcm_time’:
pcm-test.c:384:68: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 \
				has type ‘unsigned int’ [-Wformat=]
  384 |                 snprintf(msg, sizeof(msg), "rate mismatch %ld != %ld", rate, rrate);
pcm-test.c:455:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \
				type ‘long int’ [-Wformat=]
  455 |                                          "expected %d, wrote %li", rate, frames);
pcm-test.c:462:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \
				type ‘long int’ [-Wformat=]
  462 |                                          "expected %d, wrote %li", rate, frames);
pcm-test.c:467:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \
				type ‘long int’ [-Wformat=]
  467 |                                          "expected %d, wrote %li", rate, frames);

Simple fix according to compiler's suggestion removed the warnings.

Signed-off-by: Mirsad Goran Todorovac 
Reviewed-by: Mark Brown 
Link: https://lore.kernel.org/r/20230524191528.13203-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Takashi Iwai

kselftest/alsa - pcm-test: Don't include diagnostic message in test name

2023-03-24T06:49:57+00:00

When reporting errors or skips we currently include the diagnostic message
indicating why we're failing or skipping. This isn't ideal since KTAP
defines the entire print as the test name, so if there's an error then test
systems won't detect the test as being the same one as a passing test. Move
the diagnostic to a separate ksft_print_msg() to avoid this issue, the test
name part will always be the same for passes, fails and skips and the
diagnostic information is still displayed.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20230323-alsa-pcm-test-names-v1-1-8be67a8885ff@kernel.org
Signed-off-by: Takashi Iwai

kselftest/alsa - mixer-test: Log values associated with event issues

2023-03-24T06:49:47+00:00

While it is common for driver bugs with events to apply to all events there
are some issues which only trigger for specific values. Understanding these
is easier if we know what we were trying to do when configuring the control
so add logging for the specific values involved in the spurious event.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20230322-alsa-mixer-event-values-v1-1-78189fcf6655@kernel.org
Signed-off-by: Takashi Iwai

kselftest/alsa: Log card names during startup

2023-03-08T05:35:25+00:00

It can be helpful to know which card numbers apply to which cards in a
multi-card system so log the card names when we start the test programs.
People looking at the logs may not have direct access to the systems being
tested.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20230223-alsa-log-ctl-name-v1-2-ac0f10cc4db2@kernel.org
Signed-off-by: Takashi Iwai

kselftest/alsa - mixer: Always log control names

2023-03-08T05:35:18+00:00

Currently we only log the names of controls on error but it can be useful
to know what control we're testing (for example, when looking at why the
tests are taking a while to run). People looking at test logs may not have
direct access to the target system. This will increase the amount we write
to the console, hopefully that's buffered.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20230223-alsa-log-ctl-name-v1-1-ac0f10cc4db2@kernel.org
Signed-off-by: Takashi Iwai

kselftest/alsa - mixer-test: Don't fail tests if we can't restore default

2023-03-08T05:34:29+00:00

If a control has an invalid default value then we might fail to set it
when restoring the default value after our write tests, for example due to
correctly implemented range checks in put() operations. Currently this
causes us to report the tests we were running as failed even when the
operation we were trying to test is successful, making it look like there
are problems where none really exist. Stop doing this, only reporting any
issues during the actual test.

We already have validation for the initial readback being in spec and for
writing the default value back so failed tests will be reported for these
controls, and we log an error on the operation that failed when we write so
there will be a diagnostic warning the user that there is a problem.

Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20230224-alsa-mixer-test-restore-invalid-v1-1-454f0f1f2c4b@kernel.org
Signed-off-by: Takashi Iwai