[SCSI] libfc: fix sending REC after FCP_RESP is received
[SCSI] libfc: fix sending REC after FCP_RESP is received

This is exposed in the case the FCP_DATA frames somehow got lost and fc_fcp got
the FCP_RSP, in fc_fcp_recv_resp(), since xfer_len is less than the expected_len
it resets the the timer to wait to 2 more jiffies in case the data frames are
already queued locally. However, for target does not support REC, it would just
send RJT w/ ELS_RJT_UNSUP. The rec response handler thus only clears the rport
flag for not doing REC later, but does not do fcp_io_complete() on the
associated fsp.

The fix is just check status of FCP_RSP being received already, i.e. using the
FC_SRB_RCV_STATUS flag, in fc_fcp_timeout before start sending REC. We should
have waited long enough if there is truely data frames queued locally.

Signed-off-by: Yi Zou <5b3a821cf7a153d601945bbe257e1150110342e4@intel.com>
Tested-by: Ross Brattain <ddebe0db9486ace8e4376a8be8a0aaa0090ac511@intel.com>
Signed-off-by: Robert Love <ae32029cc3b561e3768d1db8669e99f5bdf25e4b@intel.com>
Signed-off-by: James Bottomley <1acebbdca565c7b6b638bdc23b58b5610d1a56b8@Parallels.com>

KristFoundation/Programs,TeamVee-Kanas/android_kernel_samsung_kanas,TeamVee-Kanas/android_kernel_samsung_kanas,KristFoundation/Programs,KristFoundation/Programs,TeamVee-Kanas/android_kernel_samsung_kanas,KristFoundation/Programs,TeamVee-Kanas/android_kernel_samsung_kanas,TeamVee-Kanas/android_kernel_samsung_kanas,KristFoundation/Programs,KristFoundation/Programs