Re: testing/selftests/alsa/mixer-test: 10 failures on Dell XPS 13 9360

[Jaroslav Kysela <perex@xxxxxxxx>]

On 14. 06. 24 13:33, Takashi Iwai wrote:
> On Mon, 03 Jun 2024 13:38:18 +0200,
> Mark Brown wrote:
> > On Fri, May 31, 2024 at 08:06:14PM +0200, Takashi Iwai wrote:
> > > 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,
> >
> > > > 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.
> >
> > Yeah, I mean I tend to think the whole accepting invalid values thing is
> > questionable to start off with so I do think that's a good idea.  That
> > said we probably should still be fixing the drivers as well.
>
> OK, I'm going to submit a patch set for addressing those.

I think that this check should be optional (as discussed some years ago), 
because the driver code can implement the validation / bitmask handling in a 
more efficient way that we can do in the ALSA core code. Those double checks 
are not so nice. But they may be enabled by default as suggested to log 
problems for users building custom kernels, IMHO.

					Jaroslav

--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.