scsi: lpfc: Relax PRLI issue conditions after GID_FT response

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>
Link: https://lore.kernel.org/r/20240628172011.25921-4-justintee8345@gmail.comSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>

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,