Uh oh!
There was an error while loading. Please reload this page.
ASoC: SOF: Don't read reply if its not used - #3925
Conversation
Uh oh!
There was an error while loading. Please reload this page.
ujfalusi
left a comment
There was a problem hiding this comment.
I would be tempted to change the subject to "ASoC: SOF: ipc3: ..." as this change only affects IPC3 code path.
cujomalainey
commented
Oct 14, 2022
That isn't quite correct, the majority are, but there are changes in the compress code as well as the flood test. |
cujomalainey
commented
Oct 14, 2022
Found a couple more replies that could be removed and added them to the chain. |
64eca90 to
1cbdfacComparecujomalainey
commented
Oct 14, 2022
Apologies for the rapid pushes, fixed a typo that then introduced a change-id |
plbossart
commented
Oct 26, 2022
quite a few build issues @cujomalainey |
cujomalainey
commented
Oct 28, 2022
Yea saw that, sorry for the delay, was out sick Monday/Tuesday, trying to catch up |
cujomalainey
commented
Nov 2, 2022
Ah forgot the |
a5cd7d4 to
e1e9446Comparecujomalainey
commented
Nov 2, 2022
FYI I cannot open the checkpatch bot as I am getting SSL errors. |
cujomalainey
commented
Nov 3, 2022
@plbossart can we do a review? The longer the delay the likelyhood of more uses slipping in that the patches won't catch, my fix and rebase already caught 2 more. |
plbossart
commented
Nov 3, 2022
I'll be honest @cujomalainey, we have too many PRs in flight: Your PR makes complete sense but we have to be realistic on the urgency/priority. |
cujomalainey
commented
Nov 3, 2022
@plbossart understood, thanks for the update. Let me know when things calm down, I'll rebase to make sure I get any new cases then re-review. |
cujomalainey
commented
Nov 22, 2022
@plbossart just wanted to let you know I rebased these so if things have calmed down on your end they should be able to go in |
iuliana-prodan
left a comment
There was a problem hiding this comment.
LGT, but can't we use only patches 2 and 3 - patch 1 is modified by 3?
Add no reply calls and use them where reply is "thrown away".
cujomalainey
commented
Nov 28, 2022
@iuliana-prodan It was more to keep the conceptually isolated since the first was produced on its own and is clean up, the other two are the prevention |
95% of the calls inside SOF to TX an IPC don't care about a reply. Yet the previous commit cleaned up a bunch of replies that were being populated and then thrown away. This adds some functions so users who do not need replies don't feel obligated to provide the space to the API. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Convert all existing calls that pass "NULL, 0" for reply data to the new no_reply calls. Also convert any calls that pass in data but don't actually parse the result. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
plbossart
commented
Dec 2, 2022
| int sof_client_ipc_tx_message(struct sof_client_dev *cdev, void *ipc_msg, | ||
| void *reply_data, size_t reply_bytes); | ||
| static inline int sof_client_ipc_tx_message_no_reply(struct sof_client_dev *cdev, void *ipc_msg) |
There was a problem hiding this comment.
@cujomalainey the change itself is OK but i think the name with the no_reply suffix is a bit misleading which seems to indicate that there's no reply for this IPC TX. It's not that there's no reply but that there's no data expected with the reply right?
There was a problem hiding this comment.
No the concept is that we don't care about the reply, only the return code. I.e don't fetch the reply data. Name was recommended by @plbossart
There was a problem hiding this comment.
@cujomalainey the return code that you mention here is part of the reply isnt it?
Most uses of the IPC TX reply only care about the return code which can be returned without passing a stack allocated struct. Let's save those copy cycles.
Signed-off-by: Curtis Malainey cujomalainey@chromium.org