[alsa-devel] [PATCH v2 09/25] ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()

[Pierre-Louis Bossart]

>>>>> Question is simple: are we staying with all-for-one/ one-for-all 
>>>>> approach or we reverting to permissive behavior?
>>>>
>>>> Can you elaborate in which test case this patch creates a problem? 
>>>> Just curious why the route addition fails in the first place.
>>>
>>> If snd_soc_instantiate_card fails so does any test, really. Red wall 
>>> was easy to spot even for a hungry developer : )
>>>
>>> Our cnl_rt274 board declares several routes, yet our topology does 
>>> not provide necessary info for all of them. And thus, addition of 
>>> some routes fails. This was fine till now. That's also why I'd 
>>> mentioned in the very first sentence: it might be simply a board 
>>> issue. Maybe we should have never abused permissive behavior in the 
>>> first place.
>>
>> Yep, and that driver is not upstream as well so Intel can't complain 
>> here...
> 
> ??
> 
> It's not about complaining, rather starting a discussion. If I were 
> using boards with topology not fully matching its board equivalent 
> (because if has never been required of me) then there may be others who 
> did the exact same trick. Your card won't be enumerated now == change of 
> behavior.
> 
> Board bxt_rt298 is upstreamed and the exact same failures could be 
> reproduced since topology has something to say here too..

That's different. For bxt_rt298 there is a topology that was released, 
and if it's incorrect it should be fixed.
I *hope* we are not going to see such regressions with SKL/KBL 
Chromebooks, that would be more of a problem since there are more users.