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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
