ipc3: override type field once comp_driver found

[cujomalainey]

A bad IPC can mismatch UUID and type, causing downstream processes to operate differently than the final component target. This is because get_drv will not reject the mismatch and given we don't know the state of topology we can't start now. Instead we can override the ipc with the proper type.

[cujomalainey]

@lyakh this is the correct fix for #9473

The issue was it was using the UUID of the selector but passing in the DAI type

[lyakh]

wouldn't it be better to check and to error out in case of mismatch?

[lgirdwood]

if not possible to error out then due to usersapce, then it could be logged.

[cujomalainey]

We can error out as well in get_drv. I figured this was the most likely way to preserve existing functionality rather than breaking it

[cujomalainey]

Looks like regardless of what way I do it, unit tests fail. I am curious what on device testing looks like @wszypelt

[cujomalainey]

LNL test appear to pass but unit tests do not.

Here are my thoughts on the two solutions on their ups/downs

	override	expect match
upside	should always work regardless of state of host / topology	requires correctness
downside	- we are overriding host information	1.will break any topology that is not set correctly 2.may break with module adapter changes as enum changes with that.

[cujomalainey]

@lgirdwood @lyakh would be great to get clarification on this, this is blocking the fuzzer currently

[lyakh]

@lgirdwood @lyakh would be great to get clarification on this, this is blocking the fuzzer currently

@cujomalainey you mean a clarification of unit test failures? Sorry, I don't have an answer off the top of my head, I guess it just needs to be debugged and fixed. Supposedly unit tests use those fields in some different incompatible with our assumptions here way. @singalsu would you have an idea maybe?

[cujomalainey]

No, which one is better given both have risks of topology mismatch, if we should do override or check enum + uuid. The double checks i listed above, just curious if there is any thoughts on the risks.

[lyakh]

@cujomalainey I'm for correctness FWIW

[marc-hb]

For the record, this was merged broken:

#6879 (comment)

https://github.com/thesofproject/sof/actions/runs/10964848537/job/30449371562

94% tests passed, 3 tests failed out of 47

Total Test time (real) =   0.14 sec

The following tests FAILED:
	 10 - mux_get_processing_function (Failed)
	 11 - mux_copy (Failed)
	 12 - demux_copy (Failed)
Errors while running CTest
Output from these tests are in: /home/runner/work/sof/sof/build_ut_defs/acp_6_3_defconfig/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.

https://github.com/thesofproject/sof/actions/runs/10964848523/job/30449371607

726859083.164893:(ipc-common.c:273) ipc_init()
1726859083.177222:(ll_schedule.c:114) ll_scheduler_init()
1726859083.178586:(edf_schedule.c:112) edf_scheduler_init()
1726859083.208130:(helper.c:144) get_drv(): the provided UUID (bfc7488c4ce875aadad8be9dc298a608) doesn't match to any driver!
1726859083.208856:(helper.c:684) ipc_comp_new(): component cd = NULL
error: file read
error: load AIF IN failed
error: parsing topology
error: pipeline load 0 failed -22

(On the same day when unrelated #9475 (comment) was also merged broken)