ASoC: SOF: Don't read reply if its not used #3925
Conversation
cujomalainey
requested review from
ajitkupandey,
bardliao,
dbaluta,
kuanhsuncheng,
kv2019i,
lgirdwood,
libinyang,
plbossart,
ranj063,
ujfalusi and
yaochunhung
as code owners
ujfalusi
left a comment
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.
That isn't quite correct, the majority are, but there are changes in the compress code as well as the flood test. |
|
Found a couple more replies that could be removed and added them to the chain. |
cujomalainey
force-pushed
the
reply
branch
2 times, most recently
from
64eca90 to
1cbdfac
Compare
|
Apologies for the rapid pushes, fixed a typo that then introduced a change-id |
|
quite a few build issues @cujomalainey |
Yea saw that, sorry for the delay, was out sick Monday/Tuesday, trying to catch up |
|
Ah forgot the |
cujomalainey
force-pushed
the
reply
branch
2 times, most recently
from
a5cd7d4 to
e1e9446
Compare
|
FYI I cannot open the checkpatch bot as I am getting SSL errors. |
|
@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. |
|
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. |
|
@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. |
|
@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
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".
|
@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>
|
|
||
| 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?
6 participants
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