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>

diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c
index 93f5961821452b50d0094413658c34bc37cbc9ec..bd9983b3acf3d5feba9a5523ccda22ffb82b7884 100644 (file)
--- 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);