@@ -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,
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(-)