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);
next prev parent 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