On Fri, 31 May 2024 18:03:52 +0200, Mark Brown wrote:
On Fri, May 31, 2024 at 05:17:43PM +0200, Takashi Iwai wrote:
On Fri, 31 May 2024 07:50:33 +0200,
not ok 5 write_invalid.0.40 not ok 201 write_invalid.0.12 not ok 208 write_invalid.0.11 not ok 264 write_invalid.0.3 not ok 271 write_invalid.0.2 not ok 278 write_invalid.0.1 not ok 285 write_invalid.0.0Through a quick look, those are no real "failures". It'd be more preferable if the driver returns an error for invalid values, but currently it's up to drivers how to deal with them, and some accept as is but with correction of the values internally. They are shown as "skips" in the summary above you showed, after all.
I would say these are all bugs, they show the driver not correcting the value and allowing users to read back out of range values that were written. Even if the driver is accepting out of range values I'd expect it to transform them somehow when storing, the program will accept a mismatched read when testing this case but it will complain if the read value is not valid according to the control's info.
Ideally, yeah. But it's a whack-a-mole game, and my gut feeling is that it'd be better to enable the input validation globally, something like below.
Takashi
--- a/sound/core/Kconfig +++ b/sound/core/Kconfig @@ -219,7 +219,8 @@ config SND_PCM_XRUN_DEBUG the process or driver which causes the scheduling gaps.
config SND_CTL_INPUT_VALIDATION - bool "Validate input data to control API" + bool "Validate input data to control API" if EXPERT + default y help Say Y to enable the additional validation for the input data to each control element, including the value range checks.