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.
