From: Mike Christie <michaelc@xxxxxxxxxxx>
There does not seem to be a reason why libfc adds a 5
second delay to the user requested value for the dev loss
tmo. There also does not seem to be a reason to allow
setting it to 0 (or really close).
This patch removes the extra 5 sec delay, and for 0 it
sets it to 1 like other fc drivers. We should actually
be able to set it to 0 since the queue_delayed_work API
will just call queue_work, but other drivers set it to 1 in
that case.
Signed-off-by: Mike Christie <michaelc@xxxxxxxxxxx>
Signed-off-by: Robert Love <robert.w.love@xxxxxxxxx>
---
drivers/scsi/libfc/fc_rport.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c
index b9f2286..a84ef13 100644
--- a/drivers/scsi/libfc/fc_rport.c
+++ b/drivers/scsi/libfc/fc_rport.c
@@ -196,9 +196,9 @@ static const char *fc_rport_state(struct fc_rport_priv *rdata)
void fc_set_rport_loss_tmo(struct fc_rport *rport, u32 timeout)
{
if (timeout)
- rport->dev_loss_tmo = timeout + 5;
+ rport->dev_loss_tmo = timeout;
else
- rport->dev_loss_tmo = 30;
+ rport->dev_loss_tmo = 1;
}
EXPORT_SYMBOL(fc_set_rport_loss_tmo);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
