In OCR path, before calling chip reset calls function
megasas_wait_for_outstanding_fusion to check reason for OCR. In case of
firmware FAULT initiated OCR and DCMD timeout initiated timeout, driver
will clear any outstanding reply (yet to be processed by driver) in
reply queues before going for chip reset. This code is added to handle a
scenario when IO timeout initiated adapter reset and management
application initiated adapter reset (by sending command to FAULT
firmware) happens simultaneously since adapter reset function is
safe-guarded by reset_mutex so only thread will be doing controller
reset. Consider IO timeout thread gets mutex and proceeds with adapter
reset process after disabling interrupts and by the time management
application has fired command to firmware to do adapter reset and the
same command is completed by firmware but since interrupts are disabled,
driver will not get completion and the same command will be in
outstanding/pending commands list of driver and refires same command
from IO timeout thread after chip reset which will again FAULT firmware
and eventually causes kill adapter.
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinicke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>