On Mon, Sep 11, 2023 at 12:39:36PM -0700, Stephen Boyd wrote: > It's possible for interrupts to get significantly delayed to the point > that callers of intel_scu_ipc_dev_command() and friends can call the > function once, hit a timeout, and call it again while the interrupt > still hasn't been processed. This driver will get seriously confused if > the interrupt is finally processed after the second IPC has been sent > with ipc_command(). It won't know which IPC has been completed. This > could be quite disastrous if calling code assumes something has happened > upon return from intel_scu_ipc_dev_simple_command() when it actually > hasn't. > > Let's avoid this scenario by simply returning -EBUSY in this case. > Hopefully higher layers will know to back off or fail gracefully when > this happens. It's all highly unlikely anyway, but it's better to be > correct here as we have no way to know which IPC the status register is > telling us about if we send a second IPC while the previous IPC is still > processing. > > Cc: Prashant Malani <pmalani@xxxxxxxxxxxx> > Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
