summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorHannes Reinecke <hare@suse.de>2016-08-05 14:55:00 +0200
committerMartin K. Petersen <martin.petersen@oracle.com>2016-08-18 22:27:26 -0400
commit166f310b629c046b7f5ca846adf978cda47b06c2 (patch)
treecae068e8d8cb8975c2cc27939941cdef28f20edb /drivers
parentaceeffbb59bb91404a0bda32a542d7ebf878433a (diff)
scsi: libfc: Issue PRLI after a PRLO has been received
When receiving a PRLO it just means that the operating parameters have changed, it does _not_ mean that the port doesn't want to communicate with us. So instead of implicitly logging out we should be issueing a PRLI to figure out the new operating parameters. We can always recover once PRLI fails. Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Chad Dupuis <chad.dupuis@qlogic.com> Tested-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/scsi/libfc/fc_rport.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c
index 93f596182145..bd9983b3acf3 100644
--- a/drivers/scsi/libfc/fc_rport.c
+++ b/drivers/scsi/libfc/fc_rport.c
@@ -1877,7 +1877,7 @@ static void fc_rport_recv_prlo_req(struct fc_rport_priv *rdata,
spp->spp_type_ext = rspp->spp_type_ext;
spp->spp_flags = FC_SPP_RESP_ACK;
- fc_rport_enter_delete(rdata, RPORT_EV_LOGO);
+ fc_rport_enter_prli(rdata);
fc_fill_reply_hdr(fp, rx_fp, FC_RCTL_ELS_REP, 0);
lport->tt.frame_send(lport, fp);