On Tue, Sep 08, 2026 at 05:23:19PM +0100, Mark Brown wrote: Thanks for the detailed review.
> You're using "grading" a bunch, I think you mean "check"? It makes > things hard to follow. Yes, that's what I meant. Will change it. > It seems like we should have a test that we can actually find this > control, right now it looks like we silently ignore it being missing. > Are all IEC958 controls supposed to have one of these? I couldn't find anything saying they must. 32 of the 36 writable Playback Defaults in the tree have a Con Mask, Pro Mask or Mask sibling, 4 don't (fsl_spdif, fsl_xcvr, uniperif_player, stm32_sai_sub). The driver docs only ask that mask and default share an iface, and sound/core doesn't check. So unless there's a rule I'm missing I'll keep the non audio guess for those and print that no mask was found, rather than fail them. > This will fail without reporting a diagnostic which isn't helpful. Right, thanks. Will add one. I'll print the raw return value rather than snd_strerror() since three of the wait_for_event() paths hand back a bare -1. > Aren't there two cases here? There's the case where the device > advertised a mask where we presumably know that the control ought to be > writable, and there's the case where we just guessed a bit to write > where it's more legitimate that the write got ignored. Yes, good point. I'll split on whether a mask was found. With one, walk every advertised bit except the layout bit through write_and_verify() and fail if a bit doesn't stick, same as the integer loop does. Without one, keep the v2 guess and only check the event. That also means drop_events() only runs on the guess path. > In theory we could also probe every single bit advertised rather than > just the first one, that's more what the tests for other control types > do. That falls out of the split. 11 writes per control on the HDA card here. One thing I'd like to check with you first. Failing on an advertised bit that's dropped turns three drivers that pass today into failures: au88x0 (mask says 0xff, put() reads only the FS bits), ice1712 on Delta 1010 and Mediastation (mask 0xff, no put callback), and rme32 in professional layout (mask advertises the whole emphasis field, the converter reads one value). I think those are the mask not matching the driver, which is the kind of thing the test is for, but I don't have any of that hardware. I'll go with strict for v3 unless you'd rather those were reported without failing. Happy to do either. Thanks, HyeongJun
