Audio: copier: Fix return value if pipeline_get_dai_comp_latency() fails
There is no use returning ret from a previous call assigning it if pipeline_get_dai_comp_latency() has failed. In fact this crashes the firmware.
Signed-off-by: Jyri Sarha [email protected]
@jsarha can you force push again to restart CI. Thanks.
@wszypelt @lrudyX Could someone check CI, this PR should not impact these tests. Thanks !!
@lgirdwood issue in IPC4 tests
@mwasko @jxstelter pls advise here, this PR fixes a crash and return error code, but fails IPC4 test. What is teh correct IPC4 flow here ?
Please fix IPC4 flow before merge
@mwasko can you advise on the correct IPC4 flow here and @jsarha can update (as this is a FW crash).
Please fix IPC4 flow before merge
@mwasko can you advise on the correct IPC4 flow here and @jsarha can update (as this is a FW crash).
@marcinszkudlinski can you help here?
So are you telling that this fix somehow breaks the IPC4 message flow?
About the crash, I am not so sure it can be repeated easily. I had some issue that caused the pipeline_get_dai_comp_latency() to fail and FW crashing right after. Fixing the return value stopped the crashing, but the pipeline_get_dai_comp_latency() failing was something that in the end was somehow caused by my build environment and I finally managed to fix it by creating it from the scratch (after trying pretty much everything else first).
About the crash, I am not so sure it can be repeated easily. I had some issue that caused the pipeline_get_dai_comp_latency() to fail and FW crashing right after. Fixing the return value stopped the crashing, but the pipeline_get_dai_comp_latency() failing was something that in the end was somehow caused by my build environment and I finally managed to fix it by creating it from the scratch (after trying pretty much everything else first).
If you can reproduce, can you walk back up the stack and find the deref/crash ? We could put a check in the code to avoid ? Otherwise we can revisit if we see this again, could have been a stale build.
SOFCI TEST
@jsarha any update @marcinszkudlinski can you provide guidance ?
@jsarha any update @marcinszkudlinski can you provide guidance ?
@lgirdwood I posted the same change yesterday and I think it is the right thing to do but this change but it will have to wait until after my kernel PR #3917 is merged
@jsarha any update @marcinszkudlinski can you provide guidance ?
@lgirdwood I posted the same change yesterday and I think it is the right thing to do but this change but it will have to wait until after my kernel PR #3917 is merged
ok, thanks @ranj063 please ping this PR after your kernel PR is merged and we can continue.
@jsarha any update @marcinszkudlinski can you provide guidance ?
@lgirdwood I have not seen the crash for a while, so I think the priority can be downgraded. There was probably something else wrong with my system at the time, and fixing this minor issue somehow saved it from crashing, because the whole operation failed with my change.
Can one of the admins verify this patch?
No activity in a long time, converting as draft.