Noticed a couple of races in SCMI code around delayed responses that
time out. These are probably nearly impossible to hit in practice but
the fixes are pretty straightforward and it seems worth having the
code be sound.

Signed-off-by: Roland Dreier <rolanddreier@rivian.com>
---
Roland Dreier (2):
      firmware: arm_scmi: Protect xfer->async_done with xfer->lock
      firmware: arm_scmi: Don't reuse raw xfers with async_done still armed

 drivers/firmware/arm_scmi/common.h    | 23 ++++++++++++++++++++++
 drivers/firmware/arm_scmi/driver.c    | 36 ++++++++++++++++++++++++++++++-----
 drivers/firmware/arm_scmi/protocols.h |  9 ++++++---
 drivers/firmware/arm_scmi/raw_mode.c  | 29 ++++++++++++++++++++++------
 4 files changed, 83 insertions(+), 14 deletions(-)
---
base-commit: a5161661ae99f497affa83a5b8654e457cda6267
change-id: 20260814-scmi-async-done-race-29117fd1e9a5

Best regards,
--  
Roland Dreier <rolanddreier@rivian.com>

On Fri, Aug 14, 2026 at 08:15:32PM +0000, Roland Dreier via B4 Relay wrote:
> Noticed a couple of races in SCMI code around delayed responses that
> time out. These are probably nearly impossible to hit in practice but
> the fixes are pretty straightforward and it seems worth having the
> code be sound.

Hi, 

apologies for the delay in this reviews...

Nice hardening work, Sashiko complains about a few unrelated things (of
course :P), there is only probably a good point around the update of
DEBUG_COUNTERS that you added


https://sashiko.dev/#/patchset/20260814-scmi-async-done-race-v1-0-335b163d77ee%40rivian.com

"Will this new counter actually increment for timed-out responses, or will it 
be blocked by earlier validation logic?"

I mean please consider if you can improve the patch only regarding the
DEBUG_COUNTER update (probably moving the update where async_done is now
set to NULL is enough...)

Beside this, look good to me and in my testing everything was fine.

Thanks
Cristian

> Noticed a couple of races in SCMI code around delayed responses that
> time out. These are probably nearly impossible to hit in practice but
> the fixes are pretty straightforward and it seems worth having the
> code be sound.

Hi, just wondering if you had a chance to look at these patches, let me
know if there are any questions or fixes needed.

Thanks!
  Roland

                        |||
Ignore any footer below vvv

-- 
*CONFIDENTIALITY NOTE:* This electronic message (including any attachments) 
may contain information that is privileged, confidential, and proprietary. 
If you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, or use of the information contained 
herein (including any reliance thereon) is strictly prohibited. If you 
received this electronic message in error, please immediately reply to the 
sender that you have received this communication and destroy the material 
in its entirety, whether in electronic or hard copy format. Although Rivian 
has taken reasonable precautions to ensure no viruses are present in this 
email, Rivian accepts no responsibility for any loss or damage arising from 
the use of this email or attachments.