As we are all trying to avoid a value of zero, we should just make the
transport set function validate the range so that
1 <= dev_loss_tmo <= whatever_the_max_define_is
-- james s
Michael Reed wrote:
lpfc and qla2x00 have something similar. I chose the driver default instead of
1. Is setting it to one correct for the api?
static void
lpfc_set_rport_loss_tmo(struct fc_rport *rport, uint32_t timeout)
{
/*
* The driver doesn't have a per-target timeout setting. Set
* this value globally. lpfc_nodev_tmo should be greater then 0.
*/
if (timeout)
lpfc_nodev_tmo = timeout;
else
lpfc_nodev_tmo = 1;
rport->dev_loss_tmo = lpfc_nodev_tmo + 5;
}
Mike
James Smart wrote:
+static void
+mptfc_set_rport_loss_tmo(struct fc_rport *rport, uint32_t timeout)
+{
+ if (timeout > 0)
+ rport->dev_loss_tmo = timeout;
+ else
+ rport->dev_loss_tmo = mptfc_dev_loss_tmo;
+}
The only function of the if-test here is checking for 0 or >0, as
the fc transport ensures it is nothing else. What bothers me is
if the value is 0, then you are overriding it with the mptfc default
value without any warning or error report to the user.
Perhaps we should be dealing with a zero value differently in the
transport.
The rest looks ok...
-- james s
-
: 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
-
: 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