Hi Charles
Thank you for your feedback
Yes I had considered adding in breaks as an initial fix, however, two things drove me in this direction.
Firstly, it didn't feel like it made sense to be calling different compr_ops on different components. Not sure if anyone feels there might be use-cases for that?
And what should happen if two components had the same callback? Which do we call, should we call both as the current code does, but then what to do with the results? In short I felt there is significantly more work to be done to support systems where we have multiple components providing compressed functionality on a single runtime, so better to not look like we support it at the moment.
Secondly it feels like a lot of code duplication having those almost identical loops in every callback and this solution keeps things much neater.
I will have a look through the soc-pcm stuff as well and have a think if there are any issues there as well, although that does all seem to work on my system.
In existing drivers, the component which have compr_ops *was* originally "platform" component only. The main purpose why we want to replace platform (and codec) to component is that CPU/Codec/Platform categorize is no longer best match for modern device.
Thus, if we can replace all CPU/Codec/Platform into component, every device can have every feature, with no categorize ! In other words, we don't know how many device have it.
But anyway, we don't have such situation, and we don't know how to adjust to it at this point. Thus Yes !! I can 100% agree your opinion. Thank you for your help
One note is that "rtd->platform" itself will be removed if all platforms were replaced. Then, soc_compr_get_component() / soc_compr_get_ops() might be merged or adjusted.
Best regards --- Kuninori Morimoto