[PATCH 3/8] lpfc: Relax PRLI issue conditions after GID_FT response

[Justin Tee <justintee8345@gmail.com>]

If previously in REG_LOGIN_ISSUE state, then remove the requirement that
PLOGI must have been received from the remote port before issuing a PRLI.
After GID_FT completes, it does not matter whether the driver itself sent a
PLOGI or received one.  The fact that we're in REG_LOGIN_ISSUE state simply
means that the next state should be issuing the PRLI to continue discovery
of the remote port.

Signed-off-by: Justin Tee <justin.tee@broadcom.com>
---
 drivers/scsi/lpfc/lpfc_ct.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 376d0f958b72..2dedd1493e5b 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -1553,22 +1553,14 @@ lpfc_cmpl_ct_cmd_gft_id(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
 			if (ndlp->nlp_state == NLP_STE_REG_LOGIN_ISSUE &&
 			    ndlp->nlp_fc4_type) {
 				ndlp->nlp_prev_state = NLP_STE_REG_LOGIN_ISSUE;
-				/* This is a fabric topology so if discovery
-				 * started with an unsolicited PLOGI, don't
-				 * send a PRLI.  Targets don't issue PLOGI or
-				 * PRLI when acting as a target. Likely this is
-				 * an initiator function.
-				 */
-				if (!(ndlp->nlp_flag & NLP_RCV_PLOGI)) {
-					lpfc_nlp_set_state(vport, ndlp,
-							   NLP_STE_PRLI_ISSUE);
-					lpfc_issue_els_prli(vport, ndlp, 0);
-				}
+				lpfc_nlp_set_state(vport, ndlp,
+						   NLP_STE_PRLI_ISSUE);
+				lpfc_issue_els_prli(vport, ndlp, 0);
 			} else if (!ndlp->nlp_fc4_type) {
 				/* If fc4 type is still unknown, then LOGO */
 				lpfc_printf_vlog(vport, KERN_INFO,
 						 LOG_DISCOVERY | LOG_NODE,
-						 "6443 Sending LOGO ndlp x%px,"
+						 "6443 Sending LOGO ndlp x%px, "
 						 "DID x%06x with fc4_type: "
 						 "x%08x, state: %d\n",
 						 ndlp, did, ndlp->nlp_fc4_type,
-- 
2.38.0