a) remove the error handling after soc_dapm_add_routes() to be backwards compatible with Intel problematic machine drivers. Not really nice for everyone else.
b) remove this error conditionally so that legacy Intel solutions still work but new ones deal with errors upfront.
I am not sure if there's a 'clean' way to implement b), maybe with a Kconfig selected by some machine drivers? Morimito-san, any suggestions now that we've root caused the problem (copied again below for reference)?
Is it possible to *real* fixup in the future, some day ?
Quite unlikely I am afraid. This is a mismatch between topology and machine driver, and there are no planned updates of those topologies (which were never released for upstream use).
In this case I guess the topology file was taken from a ChromeOS distribution (based on v4.4 IIRC), so there's really no guarantee that a fix would ever reach the user without a convoluted set of manual updates.
We need correct code, but backward compatibility is also needed. Not only Intel but some machine might have similar issue, so, how about to indicate WARNING, and comment ?
Like this
ret = snd_soc_dapm_add_routes(dapm, component->driver->dapm_routes, component->driver->num_dapm_routes); if (ret < 0)
goto err_probe;
/** This is error, but legacy Intel want* compatibility until xxxx.* call "goto err_probe" after that*/dev_warn(dev, "DAPM route add failed.")
we already had a warning before:
[ 22.364318] skl_n88l25_s4567 skl_n88l25_s4567: ASoC: Failed to add route iDisp3_out -> direct -> iDisp3 Tx
and it was ignored since there was no functional impact....
Maybe we could have some sort of boolean flag in the component->driver definition and explicitly request a backwards-compatible behavior (e.g. for all SKL/KBL machine drivers) when that driver is known to be flaky. There's already things like 'fully_routed', maybe we can add something such as 'disable_route_check'?