f20810d8d0
There is a possible race condition in the hardware when the abort command is issued to terminate the ongoing SCSI command as described below: - A bit in the door-bell register is set in the controller for a new SCSI command. - In some rare situations, before controller get a chance to issue the command to the device, the software issued an abort command. - If the device recieves abort command first then it returns success because the command itself is not present. - Now if the controller commits the command to device it will be processed. - Software thinks that command is aborted and proceed while still the device is processing it. - The software, controller and device may go out of sync because of this race condition. To avoid this, query task presence in the device before sending abort task command so that after the abort operation, the command is guaranteed to be non-existent in both controller and the device. Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Reviewed-by: Yaniv Gardi <ygardi@codeaurora.org> Tested-by: Dolev Raviv <draviv@codeaurora.org> Acked-by: Vinayak Holikatti <vinholikatti@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> |
||
|---|---|---|
| .. | ||
| Kconfig | ||
| Makefile | ||
| ufs.h | ||
| ufshcd-pci.c | ||
| ufshcd-pltfrm.c | ||
| ufshcd.c | ||
| ufshcd.h | ||
| ufshci.h | ||
| unipro.h | ||