The TLV header numid is ignored in bytes control set from user space and random value seen in header in get

[singalsu]

When working with SOF issue thesofproject/sof#9092 with new version of sof-ctl in thesofproject/sof#9760 I noticed that in IPC4 systems the get response returns in TLV header a IPC4 component id that is from user space point-of-view a random number. It's assigned by kernel on the fly to a running number, so it varies even with same pipeline component instance in different use scenarios with other pipelines.

It would be more clear if the get response would be the same as in data for control set. We use in the blobs as legacy from IPC3 the value SOF_CTRL_CMD_BINARY.

If the response data from get is predictable and same as in set we can directly without need to ignore the header compare the data from get operation to blobs stored into the system to see what it is, e.g. /usr/share/alsa/ucm2/blobs/sof/ipc4/eq_iir/pass.blob.

There is similar issue in control set. The numid is checked in IPC3 kernel to be SOF_CTRL_CMD_BINARY to pass. In IPC4 systems the value is not checked.

[singalsu]

@ujfalusi @ranj063 I created this issue to help decide if we want to change the IPC4 bytes control. From my point of view, the current way is not a blocker, but somewhat confusing.

[ujfalusi]

@singalsu, thank you, I agree that the current way of passing comp_id as numid to user space and ignoring the numid from user space is not good. The comp_id is kernel internal running number used per swidgets, it can be different based on different factors.

I will update the kernel patch to use SOF_CTRL_CMD_BINARY for numid.