forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The TLV header numid is ignored in bytes control set from user space and random value seen in header in get #5282
Comments
@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. |
ujfalusi
added a commit
to ujfalusi/sof-linux
that referenced
this issue
Jan 3, 2025
The header.numid is set to scontrol->comp_id in bytes_ext_get and it is ignored during bytes_ext_put. The use of comp_id is not quite great as it is kernel internal identification number. Set the header.numid to SOF_CTRL_CMD_BINARY during get and validate the numid during put to provide consistent and compatible identification number as IPC3. For IPC4 existing tooling also ignored the numid but with the use of SOF_CTRL_CMD_BINARY the different handling of the blobs can be dropped, providing better user experience. Reported-by: Seppo Ingalsuo <[email protected]> Closes: thesofproject#5282 Fixes: a062c88 ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]>
ujfalusi
added a commit
to ujfalusi/sof-linux
that referenced
this issue
Jan 8, 2025
The header.numid is set to scontrol->comp_id in bytes_ext_get and it is ignored during bytes_ext_put. The use of comp_id is not quite great as it is kernel internal identification number. Set the header.numid to SOF_CTRL_CMD_BINARY during get and validate the numid during put to provide consistent and compatible identification number as IPC3. For IPC4 existing tooling also ignored the numid but with the use of SOF_CTRL_CMD_BINARY the different handling of the blobs can be dropped, providing better user experience. Reported-by: Seppo Ingalsuo <[email protected]> Closes: thesofproject#5282 Fixes: a062c88 ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: