From: James Smart <james.smart@emulex.com>
To: Sebastian Herbszt <herbszt@gmx.de>
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: Tue, 05 May 2015 15:32:47 -0400 [thread overview]
Message-ID: <55491ADF.80102@emulex.com> (raw)
In-Reply-To: <20150421132312.00006862@localhost>
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
next prev parent reply other threads:[~2015-05-05 19:32 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 [this message]
2015-05-05 22:10 ` Sebastian Herbszt
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=55491ADF.80102@emulex.com \
--to=james.smart@emulex.com \
--cc=herbszt@gmx.de \
--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