From: Sebastian Herbszt <herbszt@gmx.de>
To: james.smart@emulex.com
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 01/14] lpfc: The lpfc driver does not issue RFF_ID and RFT_ID in the correct sequence
Date: Wed, 6 May 2015 00:10:21 +0200 [thread overview]
Message-ID: <20150506001021.00001006@localhost> (raw)
In-Reply-To: <55491ADF.80102@emulex.com>
James Smart wrote:
>
> On 4/21/2015 7:23 AM, Sebastian Herbszt wrote:
> > James Smart wrote:
> >> The lpfc driver does not issue RFF_ID and RFT_ID in the correct sequence
> >>
> >> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com>
> >> Signed-off-by: James Smart <james.smart@emulex.com>
> >> ---
> >> drivers/scsi/lpfc/lpfc_hbadisc.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
> >> index 2500f15..f2db89f 100644
> >> --- a/drivers/scsi/lpfc/lpfc_hbadisc.c
> >> +++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
> >> @@ -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);
> > Can you please elaborate on the correct command order?
> > SLI_CTNS_RFF_ID was added last in 2fb9bd8 and moved to the top in
> > 92d7f7b with the comment "Do this first!". Now it's moved back.
> >
> > The libfc code suggests this is correct because it uses the same order.
> > qla2xxx on the other hand uses RFT_ID, RFF_ID, RNN_ID, RSNN_NN, but in
> > any case RFF_ID follows RFT_ID.
> >
> > Sebastian
>
> 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 above 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.
>
> -- james s
>
Reviewed-by: Sebastian Herbszt <herbszt@gmx.de>
Sebastian
prev parent reply other threads:[~2015-05-05 22:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-20 13:56 [PATCH 01/14] lpfc: The lpfc driver does not issue RFF_ID and RFT_ID in the correct sequence James Smart
2015-04-21 9:58 ` Hannes Reinecke
2015-04-21 11:23 ` Sebastian Herbszt
2015-05-05 19:32 ` James Smart
2015-05-05 22:10 ` Sebastian Herbszt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150506001021.00001006@localhost \
--to=herbszt@gmx.de \
--cc=james.smart@emulex.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox