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

[Takashi Iwai <tiwai@xxxxxxx>]

On Fri, 14 Jun 2024 13:42:05 +0200,
Jaroslav Kysela wrote:
> 
> 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.

Yes, what I've worked on are the coverage in HD-audio and vmaster code
as well as the enablement of validation for user control elements.
It's not about unconditional enablement of input validation.


thanks,

Takashi