[PATCH] scsi: match wait_for_completion_timeout return type

[Nicholas Mc Guire]

Return type of wait_for_completion_timeout is unsigned long not int.
An appropriately named unsigned long is added, and the assignments
as well as error checking fixed up.

API conformance testing for completions with coccinelle spatches are being
used to locate API usage inconsistencies:
./drivers/scsi/libfc/fc_fcp.c:1279
        int return assigned to unsigned long

Patch was compile tested with x86_64_defconfig + SCSI_LOWLEVEL=y,
CONFIG_SCSI_FC_ATTRS=m, CONFIG_LIBFC=m

Patch is against 4.1-rc3 (localversion-next is -next-20150514)

Signed-off-by: Nicholas Mc Guire <hofrat@xxxxxxxxx>
---
 drivers/scsi/libfc/fc_fcp.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index c679594..c438b81 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -1261,7 +1261,7 @@ static void fc_lun_reset_send(unsigned long data)
 static int fc_lun_reset(struct fc_lport *lport, struct fc_fcp_pkt *fsp,
 			unsigned int id, unsigned int lun)
 {
-	int rc;
+	unsigned long time_left;
 
 	fsp->cdb_cmd.fc_dl = htonl(fsp->data_len);
 	fsp->cdb_cmd.fc_tm_flags = FCP_TMF_LUN_RESET;
@@ -1276,7 +1276,7 @@ static int fc_lun_reset(struct fc_lport *lport, struct fc_fcp_pkt *fsp,
 	 * wait for completion of reset
 	 * after that make sure all commands are terminated
 	 */
-	rc = wait_for_completion_timeout(&fsp->tm_done, FC_SCSI_TM_TOV);
+	time_left = wait_for_completion_timeout(&fsp->tm_done, FC_SCSI_TM_TOV);
 
 	spin_lock_bh(&fsp->scsi_pkt_lock);
 	fsp->state |= FC_SRB_COMPL;
@@ -1292,7 +1292,7 @@ static int fc_lun_reset(struct fc_lport *lport, struct fc_fcp_pkt *fsp,
 	fsp->wait_for_comp = 0;
 	spin_unlock_bh(&fsp->scsi_pkt_lock);
 
-	if (!rc) {
+	if (!time_left) {
 		FC_SCSI_DBG(lport, "lun reset failed\n");
 		return FAILED;
 	}
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/