> In case of ignoring Codec check on DPCM, it allows unexpected direction, > I think. For example if it is not using dummy DAI, and in case of CPU can > playback/capture, Codec can playback, and user expect playback only, > in this case unexpected "capture" will be available. He need to add > playback_only flag, but it is not good for me. > > Can we avoid validation check if DAI has some kind of new flag, like > ignore_pair ? > > pseudo code is like this > > if (valid(cpu, PLAYBACK)) > has_cpu_playback = 1; > > if (valid(cpu, CAPTURE)) > has_cpu_capture = 1; > > if (valid(codec, PLAYBACK)) > has_codec_playback = 1; > > if (valid(codec, CAPTURE)) > has_codec_capture = 1; > > if (cpu->ignore_pair) { > has_codec_playback = 1; > has_codec_capture = 1; > } > > if (codec->ignore_pair) { > has_cpu_playback = 1; > has_cpu_capture = 1; > } > > Or more detail ignore_pair_playback, ignore_pair_capture There are two options a) we don't even try to test the codec-cpu match in terms of capabilities. That means the same behavior as today. b) we add a chicken bit for platforms to disable the codec-cpu match if it breaks specific platforms. The problem with b) is that we don't know what platforms will break. I reported one example that was caught by our CI, but there could be additional Chromebooks impacted, who knows. My vote is a).