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.