From: Tyrel Datwyler <tyreld@linux.ibm.com>
To: davemarq@linux.ibm.com,
"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>
Cc: 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 v2 3/7] ibmvfc: make ibmvfc login to fabric
Date: Fri, 12 Jun 2026 16:11:50 -0700 [thread overview]
Message-ID: <bfb7ff08-e4ec-46a2-b368-12d5c77f0ee4@linux.ibm.com> (raw)
In-Reply-To: <20260608-ibmvfc-fpin-support-v2-3-d41f540fba5c@linux.ibm.com>
On 6/8/26 11:30 AM, Dave Marquardt via B4 Relay wrote:
> From: Dave Marquardt <davemarq@linux.ibm.com>
>
> Add support for fabric login in order to support the asynchronous
> event queue with its own interrupt as required by NPIV specification
> to support the asynchronous sub-queue and interrupt in order to
> support full and extended FPIN messages.
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 94 ++++++++++++++++++++++++++++++++++++++++--
> drivers/scsi/ibmvscsi/ibmvfc.h | 16 +++++++
> 2 files changed, 106 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index 88386d7c9106..a18861808325 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -5244,6 +5244,86 @@ 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:
> + 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) {
> + ibmvfc_log(vhost, level, "Fabric Login failed: no available events\n");
> + ibmvfc_hard_reset_host(vhost);
> + 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 {
> + ibmvfc_log(vhost, level, "Fabric Login failed: unknown protocol\n");
> + return;
> + }
This check is pretty pedantic. Seeing as you are directly referencing the scsi
sub-crqs. The protocol field exists so we can pass the sub-crqs blindly and the
code once NVMf comes along can determine the protocol.
Also, if somehow this was ever possibly the case you would leak the event
structure. I think we can drop the check all together.
-Tyrel
next prev parent reply other threads:[~2026-06-12 23:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 18:30 [PATCH v2 0/7] ibmvfc: make ibmvfc support FPIN messages Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 1/7] ibmvfc: add basic FPIN support Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-12 22:35 ` Tyrel Datwyler
2026-06-08 18:30 ` [PATCH v2 2/7] ibmvfc: Add NOOP command support Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 3/7] ibmvfc: make ibmvfc login to fabric Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-12 23:11 ` Tyrel Datwyler [this message]
2026-06-15 13:42 ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 4/7] ibmvfc: define asynchronous sub-queue Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-15 19:27 ` Tyrel Datwyler
2026-06-15 20:15 ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 5/7] ibmvfc: allocate " Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-15 19:54 ` Tyrel Datwyler
2026-06-08 18:30 ` [PATCH v2 6/7] ibmvfc: register and use " Dave Marquardt via B4 Relay
2026-06-08 18:30 ` Dave Marquardt
2026-06-08 18:30 ` [PATCH v2 7/7] ibmvfc: handle extended FPIN events Dave Marquardt via B4 Relay
2026-06-08 18:30 ` 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=bfb7ff08-e4ec-46a2-b368-12d5c77f0ee4@linux.ibm.com \
--to=tyreld@linux.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=brking@linux.ibm.com \
--cc=chleroy@kernel.org \
--cc=davemarq@linux.ibm.com \
--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 \
/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.