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.0 > > > Through 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.
