public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Love <robert.w.love@intel.com>
To: James.Bottomley@suse.de, linux-scsi@vger.kernel.org
Cc: Mike Christie <michaelc@cs.wisc.edu>
Subject: [PATCH 1/8] libfc: fix setting of rport dev loss
Date: Fri, 08 Oct 2010 17:12:10 -0700	[thread overview]
Message-ID: <20101009001210.7744.83712.stgit@localhost.localdomain> (raw)
In-Reply-To: <20101009001204.7744.21642.stgit@localhost.localdomain>

From: Mike Christie <michaelc@cs.wisc.edu>

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@cs.wisc.edu>
Signed-off-by: Robert Love <robert.w.love@intel.com>
---
 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);
 


  reply	other threads:[~2010-10-09  0:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-09  0:12 [PATCH 0/8] libfc, libfcoe and fcoe updates for scsi-misc Robert Love
2010-10-09  0:12 ` Robert Love [this message]
2010-10-09  0:12 ` [PATCH 2/8] libfc: use DID_TRANSPORT_DISRUPTED while lport not ready Robert Love
2010-10-09  0:12 ` [PATCH 3/8] libfc: adds flogi retry in case DID is zero in RJT Robert Love
2010-10-09  0:12 ` [PATCH 4/8] fcoe: set default FIP mode as FIP_MODE_FABRIC Robert Love
2010-10-09  0:12 ` [PATCH 5/8] libfc: possible race could panic system due to NULL fsp->cmd Robert Love
2010-10-09  0:12 ` [PATCH 6/8] libfc: Do not let disc work cancel itself Robert Love
2010-10-09  0:12 ` [PATCH 7/8] libfcoe: VN2VN connection setup causing stack memory corruption Robert Love
2010-10-09  0:12 ` [PATCH 8/8] fcoe: Fix broken NPIV with correction to MAC validation Robert Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101009001210.7744.83712.stgit@localhost.localdomain \
    --to=robert.w.love@intel.com \
    --cc=James.Bottomley@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox