OpenE2K
/
linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

lpfc: The lpfc driver does not issue RFF_ID and RFT_ID in the correct sequence 

The order (it's a shall, but hard to dictate after the fact) is given in
FC-SCM - kind of.  SCM indicates what shall be implemented, lists it as (a),
(b), (c), but actually doesn't say it has to be in that order.  The only hard
requirement, called out in FCP-4, is that you must register your FC-4 Type
(via RFT_ID) before registering FC-4 Type Features (via RFF_ID), which makes
sense. We obviously violated this and there were some switches (or newer fw in
them) that enforced it.  The other rule of thumbs are: register your data with
the switch first, then register for SCRs, then do queries about the fabric,
with the SCRs telling you of changes post the queries.

Signed-off-by: Dick Kennedy <dick.kennedy@avagotech.com>
Signed-off-by: James Smart <james.smart@avagotech.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Sebastian Herbszt <herbszt@gmx.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
This commit is contained in:
James Smart 2015-05-21 13:55:16 -04:00 committed by James Bottomley
parent 6546a02a57
commit e26422fe91
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
drivers/scsi/lpfc/lpfc_hbadisc.c
View File

@ -3868,11 +3868,11 @@ out:
if (vport->port_state < LPFC_VPORT_READY) {
/* Link up discovery requires Fabric registration. */
lpfc_ns_cmd(vport, SLI_CTNS_RFF_ID, 0, 0); /* Do this first! */
lpfc_ns_cmd(vport, SLI_CTNS_RNN_ID, 0, 0);
lpfc_ns_cmd(vport, SLI_CTNS_RSNN_NN, 0, 0);
lpfc_ns_cmd(vport, SLI_CTNS_RSPN_ID, 0, 0);
lpfc_ns_cmd(vport, SLI_CTNS_RFT_ID, 0, 0);
lpfc_ns_cmd(vport, SLI_CTNS_RFF_ID, 0, 0);
/* Issue SCR just before NameServer GID_FT Query */
lpfc_issue_els_scr(vport, SCR_DID, 0);