On Sat, 12 Sep 2026 04:54:30 +0200, HyeongJun An wrote: > > Nothing checks that the put() callback of an IEC958 control reports a > change, because write_valid skips these controls. > > Where the device publishes a mask, toggle every bit in it and check each > write. A bit the mask advertises that does not stick fails the test, the > way a rejected value fails for the other control types. > > Where none is found, keep the old single guess at the non audio bit, > which the device is free to ignore, so only the notification can be > counted against it. That path writes without checking so drop_events() > clears what those writes leave behind. > > On an HDA card with four HDMI PCMs the Con Mask is 0f ff, so each control > walks eleven bits instead of one and all eleven stick: > > -# Totals: pass:212 fail:5 xfail:0 xpass:0 skip:56 error:0 > +# Totals: pass:216 fail:5 xfail:0 xpass:0 skip:52 error:0 > > A driver whose put() never reports a change still shows up as > event_missing. hdmi-codec and img-spdif-out store every byte and return > 0, so boards using them report one event_missing per walked bit, and > hdmi-codec advertises the whole block so that is 191 of them. A driver > whose mask claims more than its put() keeps now fails write_valid > outright: au88x0 and ice1712 on Delta 1010 and Mediastation advertise > bytes they never store, cs46xx, oxygen and ice1724 advertise bits their > put() drops, and the RME cards regenerate the whole emphasis field from > one bit so the rest of it never reads back. None of that hardware was > to hand, the paths were read rather than run. > > write_invalid stays a skip. Every bit pattern is a valid channel status. > > Signed-off-by: HyeongJun An <[email protected]> > Assisted-by: Claude:claude-opus-5
Applied to for-next branch now. Thanks. Takashi
