* libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2
@ 2010-06-09 21:59 Nicholas A. Bellinger
2010-06-09 22:12 ` [Open-FCoE] " Robert Love
2010-06-09 22:23 ` Joe Eykholt
0 siblings, 2 replies; 5+ messages in thread
From: Nicholas A. Bellinger @ 2010-06-09 21:59 UTC (permalink / raw)
To: Joe Eykholt; +Cc: openfcoe-devel, linux-scsi, Love, Robert W
Greetings Joe,
While doing a pull recently for v2.6.35-rc2, I ran into a merge conflict
below in drivers/scsi/libfc/fc_rport.c:fc_rport_recv_pril_req()
with the original PLOGI driven target provider hooks changes that I have
been including into the lio-core-2.6.git tree for tcm_fc.
>From taking a quick look, I assume that active and passing prov->prli()
calls need to appear under the new roles assignment, namely under:
if (fcp_parm & FCP_SPPF_TARG_FCN)
roles |= FC_RPORT_ROLE_FCP_TARGET;
for the upstream e44a21b726 commit. Is there anything else that should
be taken into consideration to get this running again..?
Best,
--nab
<<<<<<< HEAD
/*
* Go through all the service parameter pages and build
* response. If plen indicates longer SPP than standard,
* use that. The entire response has been pre-cleared above.
*/
spp = &pp->spp;
mutex_lock(&fc_prov_mutex);
while (len >= plen) {
spp->spp_type = rspp->spp_type;
spp->spp_type_ext = rspp->spp_type_ext;
resp = 0;
if (rspp->spp_type < FC_FC4_PROV_SIZE) {
prov = fc_active_prov[rspp->spp_type];
if (prov)
resp = prov->prli(rdata, plen, rspp, spp);
prov = fc_passive_prov[rspp->spp_type];
if (prov) {
passive = prov->prli(rdata, plen, rspp, spp);
if (!resp || passive == FC_SPP_RESP_ACK)
resp = passive;
}
}
if (!resp) {
if (spp->spp_flags & FC_SPP_EST_IMG_PAIR)
resp |= FC_SPP_RESP_CONF;
else
resp |= FC_SPP_RESP_INVL;
}
spp->spp_flags |= resp;
len -= plen;
rspp = (struct fc_els_spp *)((char *)rspp + plen);
spp = (struct fc_els_spp *)((char *)spp + plen);
}
mutex_unlock(&fc_prov_mutex);
/*
* Send LS_ACC. If this fails, the originator should retry.
*/
f_ctl = FC_FC_EX_CTX | FC_FC_LAST_SEQ;
f_ctl |= FC_FC_END_SEQ | FC_FC_SEQ_INIT;
ep = fc_seq_exch(sp);
fc_fill_fc_hdr(fp, FC_RCTL_ELS_REP, ep->did, ep->sid,
FC_TYPE_ELS, f_ctl, 0);
lport->tt.seq_send(lport, sp, fp);
=======
/* reinitialize remote port roles */
rdata->ids.roles = FC_RPORT_ROLE_UNKNOWN;
/*
* Go through all the service parameter pages and build
* response. If plen indicates longer SPP than standard,
* use that. The entire response has been pre-cleared above.
*/
spp = &pp->spp;
while (len >= plen) {
spp->spp_type = rspp->spp_type;
spp->spp_type_ext = rspp->spp_type_ext;
spp->spp_flags = rspp->spp_flags & FC_SPP_EST_IMG_PAIR;
resp = FC_SPP_RESP_ACK;
switch (rspp->spp_type) {
case 0: /* common to all FC-4 types */
break;
case FC_TYPE_FCP:
fcp_parm = ntohl(rspp->spp_params);
if (fcp_parm & FCP_SPPF_RETRY)
rdata->flags |= FC_RP_FLAGS_RETRY;
rdata->supported_classes = FC_COS_CLASS3;
if (fcp_parm & FCP_SPPF_INIT_FCN)
roles |= FC_RPORT_ROLE_FCP_INITIATOR;
if (fcp_parm & FCP_SPPF_TARG_FCN)
roles |= FC_RPORT_ROLE_FCP_TARGET;
rdata->ids.roles = roles;
spp->spp_params = htonl(lport->service_params);
break;
default:
resp = FC_SPP_RESP_INVL;
break;
}
spp->spp_flags |= resp;
len -= plen;
rspp = (struct fc_els_spp *)((char *)rspp + plen);
spp = (struct fc_els_spp *)((char *)spp + plen);
}
/*
* Send LS_ACC. If this fails, the originator should retry.
*/
f_ctl = FC_FC_EX_CTX | FC_FC_LAST_SEQ;
f_ctl |= FC_FC_END_SEQ | FC_FC_SEQ_INIT;
ep = fc_seq_exch(sp);
fc_fill_fc_hdr(fp, FC_RCTL_ELS_REP, ep->did, ep->sid,
FC_TYPE_ELS, f_ctl, 0);
lport->tt.seq_send(lport, sp, fp);
>>>>>>> e44a21b7268a022c7749f521c06214145bd161e4
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Open-FCoE] libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2
2010-06-09 21:59 libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2 Nicholas A. Bellinger
@ 2010-06-09 22:12 ` Robert Love
2010-06-09 22:21 ` Nicholas A. Bellinger
2010-06-09 22:23 ` Joe Eykholt
1 sibling, 1 reply; 5+ messages in thread
From: Robert Love @ 2010-06-09 22:12 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: Joe Eykholt, openfcoe-devel, linux-scsi
On Wed, 2010-06-09 at 14:59 -0700, Nicholas A. Bellinger wrote:
> Greetings Joe,
>
> While doing a pull recently for v2.6.35-rc2, I ran into a merge conflict
> below in drivers/scsi/libfc/fc_rport.c:fc_rport_recv_pril_req()
> with the original PLOGI driven target provider hooks changes that I have
> been including into the lio-core-2.6.git tree for tcm_fc.
>
> >From taking a quick look, I assume that active and passing prov->prli()
> calls need to appear under the new roles assignment, namely under:
>
> if (fcp_parm & FCP_SPPF_TARG_FCN)
> roles |= FC_RPORT_ROLE_FCP_TARGET;
>
> for the upstream e44a21b726 commit. Is there anything else that should
> be taken into consideration to get this running again..?
>
FYI, there are a bunch of rport related patches in my fcoe-next tree
that I'll mail to linux-scsi soon. You might want to pull them or just
be aware that they're coming. I'm not sure if they'll cause conflicts
with your patches or not.
//Rob
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Open-FCoE] libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2
2010-06-09 22:12 ` [Open-FCoE] " Robert Love
@ 2010-06-09 22:21 ` Nicholas A. Bellinger
0 siblings, 0 replies; 5+ messages in thread
From: Nicholas A. Bellinger @ 2010-06-09 22:21 UTC (permalink / raw)
To: Robert Love; +Cc: Joe Eykholt, openfcoe-devel, linux-scsi
On Wed, 2010-06-09 at 15:12 -0700, Robert Love wrote:
> On Wed, 2010-06-09 at 14:59 -0700, Nicholas A. Bellinger wrote:
> > Greetings Joe,
> >
> > While doing a pull recently for v2.6.35-rc2, I ran into a merge conflict
> > below in drivers/scsi/libfc/fc_rport.c:fc_rport_recv_pril_req()
> > with the original PLOGI driven target provider hooks changes that I have
> > been including into the lio-core-2.6.git tree for tcm_fc.
> >
> > >From taking a quick look, I assume that active and passing prov->prli()
> > calls need to appear under the new roles assignment, namely under:
> >
> > if (fcp_parm & FCP_SPPF_TARG_FCN)
> > roles |= FC_RPORT_ROLE_FCP_TARGET;
> >
> > for the upstream e44a21b726 commit. Is there anything else that should
> > be taken into consideration to get this running again..?
> >
>
> FYI, there are a bunch of rport related patches in my fcoe-next tree
> that I'll mail to linux-scsi soon. You might want to pull them or just
> be aware that they're coming. I'm not sure if they'll cause conflicts
> with your patches or not.
>
Ok, will do.. Thanks for the heads up Robert.
Best,
--nab
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2
2010-06-09 21:59 libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2 Nicholas A. Bellinger
2010-06-09 22:12 ` [Open-FCoE] " Robert Love
@ 2010-06-09 22:23 ` Joe Eykholt
2010-06-09 22:28 ` Nicholas A. Bellinger
1 sibling, 1 reply; 5+ messages in thread
From: Joe Eykholt @ 2010-06-09 22:23 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: openfcoe-devel, linux-scsi, Love, Robert W
On 6/9/10 2:59 PM, Nicholas A. Bellinger wrote:
> Greetings Joe,
>
> While doing a pull recently for v2.6.35-rc2, I ran into a merge conflict
> below in drivers/scsi/libfc/fc_rport.c:fc_rport_recv_pril_req()
> with the original PLOGI driven target provider hooks changes that I have
> been including into the lio-core-2.6.git tree for tcm_fc.
>
>> From taking a quick look, I assume that active and passing prov->prli()
> calls need to appear under the new roles assignment, namely under:
>
> if (fcp_parm& FCP_SPPF_TARG_FCN)
> roles |= FC_RPORT_ROLE_FCP_TARGET;
>
> for the upstream e44a21b726 commit. Is there anything else that should
> be taken into consideration to get this running again..?
Most of the code in the HEAD version is right.
Just add the two lines initializing the roles to unknown
to the version above the ==== separator and then keep that version.
The provider prli() functions will take care of the roles.
Cheers,
Joe
> Best,
>
> --nab
>
> <<<<<<< HEAD
>
> /*
> * Go through all the service parameter pages and build
> * response. If plen indicates longer SPP than standard,
> * use that. The entire response has been pre-cleared above.
> */
> spp =&pp->spp;
> mutex_lock(&fc_prov_mutex);
> while (len>= plen) {
> spp->spp_type = rspp->spp_type;
> spp->spp_type_ext = rspp->spp_type_ext;
> resp = 0;
>
> if (rspp->spp_type< FC_FC4_PROV_SIZE) {
> prov = fc_active_prov[rspp->spp_type];
> if (prov)
> resp = prov->prli(rdata, plen, rspp, spp);
> prov = fc_passive_prov[rspp->spp_type];
> if (prov) {
> passive = prov->prli(rdata, plen, rspp, spp);
> if (!resp || passive == FC_SPP_RESP_ACK)
> resp = passive;
> }
> }
> if (!resp) {
> if (spp->spp_flags& FC_SPP_EST_IMG_PAIR)
> resp |= FC_SPP_RESP_CONF;
> else
> resp |= FC_SPP_RESP_INVL;
> }
> spp->spp_flags |= resp;
> len -= plen;
> rspp = (struct fc_els_spp *)((char *)rspp + plen);
> spp = (struct fc_els_spp *)((char *)spp + plen);
> }
> mutex_unlock(&fc_prov_mutex);
>
> /*
> * Send LS_ACC. If this fails, the originator should retry.
> */
> f_ctl = FC_FC_EX_CTX | FC_FC_LAST_SEQ;
> f_ctl |= FC_FC_END_SEQ | FC_FC_SEQ_INIT;
> ep = fc_seq_exch(sp);
> fc_fill_fc_hdr(fp, FC_RCTL_ELS_REP, ep->did, ep->sid,
> FC_TYPE_ELS, f_ctl, 0);
> lport->tt.seq_send(lport, sp, fp);
>
> =======
>
> /* reinitialize remote port roles */
> rdata->ids.roles = FC_RPORT_ROLE_UNKNOWN;
Add the above two lines to the HEAD version.
> /*
> * Go through all the service parameter pages and build
> * response. If plen indicates longer SPP than standard,
> * use that. The entire response has been pre-cleared above.
> */
> spp =&pp->spp;
> while (len>= plen) {
> spp->spp_type = rspp->spp_type;
> spp->spp_type_ext = rspp->spp_type_ext;
> spp->spp_flags = rspp->spp_flags& FC_SPP_EST_IMG_PAIR;
> resp = FC_SPP_RESP_ACK;
>
> switch (rspp->spp_type) {
> case 0: /* common to all FC-4 types */
> break;
> case FC_TYPE_FCP:
> fcp_parm = ntohl(rspp->spp_params);
> if (fcp_parm& FCP_SPPF_RETRY)
> rdata->flags |= FC_RP_FLAGS_RETRY;
> rdata->supported_classes = FC_COS_CLASS3;
> if (fcp_parm& FCP_SPPF_INIT_FCN)
> roles |= FC_RPORT_ROLE_FCP_INITIATOR;
> if (fcp_parm& FCP_SPPF_TARG_FCN)
> roles |= FC_RPORT_ROLE_FCP_TARGET;
> rdata->ids.roles = roles;
>
> spp->spp_params = htonl(lport->service_params);
> break;
> default:
> resp = FC_SPP_RESP_INVL;
> break;
> }
> spp->spp_flags |= resp;
> len -= plen;
> rspp = (struct fc_els_spp *)((char *)rspp + plen);
> spp = (struct fc_els_spp *)((char *)spp + plen);
> }
>
> /*
> * Send LS_ACC. If this fails, the originator should retry.
> */
> f_ctl = FC_FC_EX_CTX | FC_FC_LAST_SEQ;
> f_ctl |= FC_FC_END_SEQ | FC_FC_SEQ_INIT;
> ep = fc_seq_exch(sp);
> fc_fill_fc_hdr(fp, FC_RCTL_ELS_REP, ep->did, ep->sid,
> FC_TYPE_ELS, f_ctl, 0);
> lport->tt.seq_send(lport, sp, fp);
>
>>>>>>>> e44a21b7268a022c7749f521c06214145bd161e4
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2
2010-06-09 22:23 ` Joe Eykholt
@ 2010-06-09 22:28 ` Nicholas A. Bellinger
0 siblings, 0 replies; 5+ messages in thread
From: Nicholas A. Bellinger @ 2010-06-09 22:28 UTC (permalink / raw)
To: Joe Eykholt; +Cc: openfcoe-devel, linux-scsi, Love, Robert W
On Wed, 2010-06-09 at 15:23 -0700, Joe Eykholt wrote:
> On 6/9/10 2:59 PM, Nicholas A. Bellinger wrote:
> > Greetings Joe,
> >
> > While doing a pull recently for v2.6.35-rc2, I ran into a merge conflict
> > below in drivers/scsi/libfc/fc_rport.c:fc_rport_recv_pril_req()
> > with the original PLOGI driven target provider hooks changes that I have
> > been including into the lio-core-2.6.git tree for tcm_fc.
> >
> >> From taking a quick look, I assume that active and passing prov->prli()
> > calls need to appear under the new roles assignment, namely under:
> >
> > if (fcp_parm& FCP_SPPF_TARG_FCN)
> > roles |= FC_RPORT_ROLE_FCP_TARGET;
> >
> > for the upstream e44a21b726 commit. Is there anything else that should
> > be taken into consideration to get this running again..?
>
> Most of the code in the HEAD version is right.
>
> Just add the two lines initializing the roles to unknown
> to the version above the ==== separator and then keep that version.
>
> The provider prli() functions will take care of the roles.
>
Ok, I will add the initial unknown role assignment to HEAD and make a
quick test run shortly.
Thanks for your comments!
Best,
--nab
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-06-09 22:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-09 21:59 libfc fc_rport_recv_prli_req() changes for v2.6.35-rc2 Nicholas A. Bellinger
2010-06-09 22:12 ` [Open-FCoE] " Robert Love
2010-06-09 22:21 ` Nicholas A. Bellinger
2010-06-09 22:23 ` Joe Eykholt
2010-06-09 22:28 ` Nicholas A. Bellinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox