From: Dave Marquardt <davemarq@linux.ibm.com>
To: Tyrel Datwyler <tyreld@linux.ibm.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Brian King <brking@linux.ibm.com>,
Greg Joyce <gjoyce@linux.ibm.com>,
Kyle Mahlkuch <kmahlkuc@linux.ibm.com>
Subject: Re: [PATCH 3/5] ibmvfc: make ibmvfc login to fabric
Date: Thu, 07 May 2026 17:34:04 -0500 [thread overview]
Message-ID: <87ik8yetnn.fsf@linux.ibm.com> (raw)
In-Reply-To: <e8dfa3f2-2b2b-43c0-97a1-6bccb748ca6e@linux.ibm.com> (Tyrel Datwyler's message of "Wed, 6 May 2026 22:03:22 -0700")
Tyrel Datwyler <tyreld@linux.ibm.com> writes:
> On 4/8/26 10:07 AM, Dave Marquardt via B4 Relay wrote:
>> From: Dave Marquardt <davemarq@linux.ibm.com>
>>
>> Make ibmvfc login to fabric when NPIV login returns SUPPORT_SCSI or
>> SUPPORT_NVMEOF capabilities.
>
> Again better commit log message here and developer sign off tag.
>
>> ---
>> drivers/scsi/ibmvscsi/ibmvfc.c | 100 ++++++++++++++++++++++++++++++++++++++---
>> drivers/scsi/ibmvscsi/ibmvfc.h | 20 +++++++++
>> 2 files changed, 115 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
>> index 808301fa452d..803fc3caa14d 100644
>> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
>> @@ -5205,6 +5205,89 @@ static void ibmvfc_discover_targets(struct ibmvfc_host *vhost)
>> ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
>> }
>>
>> +static void ibmvfc_fabric_login_done(struct ibmvfc_event *evt)
>> +{
>> + struct ibmvfc_fabric_login *rsp = &evt->xfer_iu->fabric_login;
>> + u32 mad_status = be16_to_cpu(rsp->common.status);
>> + struct ibmvfc_host *vhost = evt->vhost;
>> + int level = IBMVFC_DEFAULT_LOG_LEVEL;
>> +
>> + ENTER;
>> +
>> + switch (mad_status) {
>> + case IBMVFC_MAD_SUCCESS:
>> + vhost->logged_in = 1;
>
> I'm not sure I see the point of setting logged_in here since we already set it
> in npiv_login_done.
Agreed.
>> + vhost->fabric_capabilities = rsp->capabilities;
>
> The way this is currently spec'd out there are no linux relevant capabilities
> coming from fabric login. So, I'm not sure there is a reason to save them at
> this point.
Okay.
>> + fc_host_port_id(vhost->host) = be64_to_cpu(rsp->nport_id);
>> + ibmvfc_free_event(evt);
>> + break;
>> +
>> + case IBMVFC_MAD_FAILED:
>> + if (ibmvfc_retry_cmd(be16_to_cpu(rsp->status), be16_to_cpu(rsp->error)))
>> + level += ibmvfc_retry_host_init(vhost);
>> + else
>> + ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
>> + ibmvfc_log(vhost, level, "Fabric Login failed: %s (%x:%x)\n",
>> + ibmvfc_get_cmd_error(be16_to_cpu(rsp->status), be16_to_cpu(rsp->error)),
>> + be16_to_cpu(rsp->status), be16_to_cpu(rsp->error));
>> + ibmvfc_free_event(evt);
>> + LEAVE;
>> + return;
>> +
>> + case IBMVFC_MAD_CRQ_ERROR:
>> + ibmvfc_retry_host_init(vhost);
>> + fallthrough;
>> +
>> + case IBMVFC_MAD_DRIVER_FAILED:
>> + ibmvfc_free_event(evt);
>> + LEAVE;
>> + return;
>> +
>> + default:
>> + dev_err(vhost->dev, "Invalid fabric Login response: 0x%x\n", mad_status);
>> + ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
>> + ibmvfc_free_event(evt);
>> + LEAVE;
>> + return;
>> + }
>> +
>> + ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_QUERY);
>> + wake_up(&vhost->work_wait_q);
>> +
>> + LEAVE;
>> +}
>> +
>> +static void ibmvfc_fabric_login(struct ibmvfc_host *vhost)
>> +{
>> + struct ibmvfc_fabric_login *mad;
>> + struct ibmvfc_event *evt = ibmvfc_get_reserved_event(&vhost->crq);
>> + int level = IBMVFC_DEFAULT_LOG_LEVEL;
>> +
>> + if (!evt) {
>
> I think we need to hard reset here or we are dead in the water if there are no
> events.
I will add a hard reset here.
>> + ibmvfc_log(vhost, level, "Fabric Login failed: no available events\n");
>> + return;
>> + }
>> +
>> + ibmvfc_init_event(evt, ibmvfc_fabric_login_done, IBMVFC_MAD_FORMAT);
>> + mad = &evt->iu.fabric_login;
>> + memset(mad, 0, sizeof(*mad));
>> + if (vhost->scsi_scrqs.protocol == IBMVFC_PROTO_SCSI)
>> + mad->common.opcode = cpu_to_be32(IBMVFC_FABRIC_LOGIN);
>> + else if (vhost->scsi_scrqs.protocol == IBMVFC_PROTO_NVME)
>> + mad->common.opcode = cpu_to_be32(IBMVFC_NVMF_FABRIC_LOGIN);
>
> The VIOS won't return NVMF support unless we advertise it. So, I think its best
> to omit any NVMF releveant changes that are spec'd as they aren't being applied
> in a proper workflow here anyways. If the driver advertised both SCSI and NVMF
> support the current code would never do a NVMF fabric login as it would never
> fall through here.
Okay, I'll removed the NVMF changes.
>> + else {
>> + ibmvfc_log(vhost, level, "Fabric Login failed: unknown protocol\n");
>> + return;
>> + }
>> + mad->common.version = cpu_to_be32(1);
>> + mad->common.length = cpu_to_be16(sizeof(*mad));
>> +
>> + ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_INIT_WAIT);
>> +
>> + if (ibmvfc_send_event(evt, vhost, default_timeout))
>> + ibmvfc_link_down(vhost, IBMVFC_LINK_DOWN);
>> +}
>> +
>> static void ibmvfc_channel_setup_done(struct ibmvfc_event *evt)
>> {
>> struct ibmvfc_host *vhost = evt->vhost;
>> @@ -5251,8 +5334,12 @@ static void ibmvfc_channel_setup_done(struct ibmvfc_event *evt)
>> return;
>> }
>>
>> - ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_QUERY);
>> - wake_up(&vhost->work_wait_q);
>> + if (ibmvfc_check_caps(vhost, (IBMVFC_SUPPORT_SCSI | IBMVFC_SUPPORT_NVMEOF))) {
>> + ibmvfc_fabric_login(vhost);
>
> Again drop the NVMEOF code.
Okay.
>> + } else {
>> + ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_QUERY);
>> + wake_up(&vhost->work_wait_q);
>> + }
>> }
>>
>> static void ibmvfc_channel_setup(struct ibmvfc_host *vhost)
>> @@ -5443,9 +5530,12 @@ static void ibmvfc_npiv_login_done(struct ibmvfc_event *evt)
>> vhost->host->can_queue = be32_to_cpu(rsp->max_cmds) - IBMVFC_NUM_INTERNAL_REQ;
>> vhost->host->max_sectors = npiv_max_sectors;
>>
>> - if (ibmvfc_check_caps(vhost, IBMVFC_CAN_SUPPORT_CHANNELS) && vhost->do_enquiry) {
>> - ibmvfc_channel_enquiry(vhost);
>> - } else {
>> + if (ibmvfc_check_caps(vhost, IBMVFC_CAN_SUPPORT_CHANNELS)) {
>> + if (vhost->do_enquiry)
>> + ibmvfc_channel_enquiry(vhost);
>
> I'm not sure I understand expanding this code to a second if block as there is
> no functional change.
Agreed.
>> + } else if (ibmvfc_check_caps(vhost, (IBMVFC_SUPPORT_SCSI | IBMVFC_SUPPORT_NVMEOF)))
>
> Again drop NVMEOF and NVMF related changes.
Yes.
>> + ibmvfc_fabric_login(vhost);
>> + else {
>> vhost->do_enquiry = 0;
>> ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_QUERY);
>> wake_up(&vhost->work_wait_q);
>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h
>> index cd0917f70c6d..4f680c5d9558 100644
>> --- a/drivers/scsi/ibmvscsi/ibmvfc.h
>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.h
>> @@ -138,6 +138,8 @@ enum ibmvfc_mad_types {
>> IBMVFC_CHANNEL_ENQUIRY = 0x1000,
>> IBMVFC_CHANNEL_SETUP = 0x2000,
>> IBMVFC_CONNECTION_INFO = 0x4000,
>> + IBMVFC_FABRIC_LOGIN = 0x8000,
>> + IBMVFC_NVMF_FABRIC_LOGIN = 0x8001,
>> };
>>
>> struct ibmvfc_mad_common {
>> @@ -227,6 +229,8 @@ struct ibmvfc_npiv_login_resp {
>> #define IBMVFC_MAD_VERSION_CAP 0x20
>> #define IBMVFC_HANDLE_VF_WWPN 0x40
>> #define IBMVFC_CAN_SUPPORT_CHANNELS 0x80
>> +#define IBMVFC_SUPPORT_NVMEOF 0x100
>> +#define IBMVFC_SUPPORT_SCSI 0x200
>> #define IBMVFC_SUPPORT_NOOP_CMD 0x1000
>> __be32 max_cmds;
>> __be32 scsi_id_sz;
>> @@ -590,6 +594,19 @@ struct ibmvfc_connection_info {
>> __be64 reserved[16];
>> } __packed __aligned(8);
>>
>> +struct ibmvfc_fabric_login {
>> + struct ibmvfc_mad_common common;
>> + __be64 flags;
>> +#define IBMVFC_STRIP_MERGE 0x1
>> +#define IBMVFC_LINK_COMMANDS 0x2
>> + __be64 capabilities;
>> + __be64 nport_id;
>> + __be16 status;
>> + __be16 error;
>> + __be32 pad;
>> + __be64 reserved[16];
>> +} __packed __aligned(8);
>> +
>> struct ibmvfc_trace_start_entry {
>> u32 xfer_len;
>> } __packed;
>> @@ -709,6 +726,7 @@ union ibmvfc_iu {
>> struct ibmvfc_channel_enquiry channel_enquiry;
>> struct ibmvfc_channel_setup_mad channel_setup;
>> struct ibmvfc_connection_info connection_info;
>> + struct ibmvfc_fabric_login fabric_login;
>> } __packed __aligned(8);
>>
>> enum ibmvfc_target_action {
>> @@ -921,6 +939,8 @@ struct ibmvfc_host {
>> struct work_struct rport_add_work_q;
>> wait_queue_head_t init_wait_q;
>> wait_queue_head_t work_wait_q;
>> + __be64 fabric_capabilities;
>> + unsigned int login_cap_index;
>
> Lets drop these as they serve no purpose for Linux. If the spec changes to
> introduce capabilites releveant to Linux we can add it then.
Okay. You discussed fabric_capabilities. I think login_cap_index isn't
useful until patch 4 or 5, so I'll drop it from patch 4.
-Dave
next prev parent reply other threads:[~2026-05-07 22:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 17:07 [PATCH 0/5] ibmvfc: make ibmvfc support FPIN messages Dave Marquardt
2026-04-08 17:07 ` Dave Marquardt via B4 Relay
2026-04-08 17:07 ` [PATCH 1/5] ibmvfc: add basic FPIN support Dave Marquardt
2026-04-08 17:07 ` Dave Marquardt via B4 Relay
2026-05-07 4:12 ` Tyrel Datwyler
2026-05-07 22:22 ` Dave Marquardt
2026-04-08 17:07 ` [PATCH 2/5] ibmvfc: Add NOOP command support Dave Marquardt
2026-04-08 17:07 ` Dave Marquardt via B4 Relay
2026-05-07 4:17 ` Tyrel Datwyler
2026-05-07 22:25 ` Dave Marquardt
2026-04-08 17:07 ` [PATCH 3/5] ibmvfc: make ibmvfc login to fabric Dave Marquardt
2026-04-08 17:07 ` Dave Marquardt via B4 Relay
2026-05-07 5:03 ` Tyrel Datwyler
2026-05-07 22:34 ` Dave Marquardt [this message]
2026-04-08 17:07 ` [PATCH 4/5] ibmvfc: use async sub-queue for FPIN messages Dave Marquardt
2026-04-08 17:07 ` Dave Marquardt via B4 Relay
2026-05-07 5:41 ` Tyrel Datwyler
2026-05-07 22:40 ` Dave Marquardt
2026-05-08 17:25 ` Tyrel Datwyler
2026-04-08 17:07 ` [PATCH 5/5] ibmvfc: handle extended FPIN events Dave Marquardt
2026-04-08 17:07 ` Dave Marquardt via B4 Relay
2026-05-07 5:48 ` Tyrel Datwyler
2026-05-08 14:38 ` Dave Marquardt
2026-04-30 16:25 ` [PATCH 0/5] ibmvfc: make ibmvfc support FPIN messages Martin K. Petersen
2026-05-07 22:15 ` Dave Marquardt
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=87ik8yetnn.fsf@linux.ibm.com \
--to=davemarq@linux.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=brking@linux.ibm.com \
--cc=chleroy@kernel.org \
--cc=gjoyce@linux.ibm.com \
--cc=kmahlkuc@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=martin.petersen@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=tyreld@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.