A race condition exists between the config read submission thread and the
interrupt handler responsible for request completion. The issue occurs
when:
- A config read thread sets is_waiting = 1, submits the command, and waits for completion.
- Firmware responds, and the interrupt handler processes the command and calls complete().
- The waiting thread wakes up before the interrupt handler resets is_waiting = 0, and reuses the command slot for a new config read.
- The interrupt handler (still completing the previous command) clears the newly set is_waiting flag, mistaking it for the earlier command.
- When the firmware response for the new command arrives, the driver sees is_waiting = 0 and does not wake up the second thread.
This results in false timeouts, delayed config reads, and late drive
exposure during back-to-back config read operations.
Fix this by setting is_waiting = 0 before invoking complete(), ensuring
that no valid waiting thread is skipped.