Karan Tilak Kumar <kartilak@cisco.com> says:
Hi Martin, reviewers,
This series adds functionality for NVMe initiator to the fnic driver.
The changes enable the fnic driver to act as an NVMe initiator over
Fibre Channel (FC-NVMe), allowing the host to discover and communicate
with NVMe targets using the existing fnic infrastructure. The patches
prepare the driver for full FC-NVMe initiator operation while
maintaining existing SCSI/FC functionality.
These are some of the salient patches:
o. Make fnic debug logging usable by SCSI and NVMe initiator roles.
o. Use fnic instance numbers for non-SCSI-facing identifiers.
o. Decode firmware roles for FCP, NVMe, and unsupported targets.
o. Advertise NVMe initiator service parameters during FC discovery.
o. Add FDLS role handling for NVMe initiator discovery flows.
o. Add the NVMe/FC transport path and port registration.
o. Route completions, resets, and LS frames by initiator role.
o. Add NVMe LS timeouts, statistics, and debugfs state reporting.
Even though the patches have been made into a series, some patches are
heavier than others. But, every effort has been made to keep the
purpose of each patch as a single-purpose, and to compile cleanly.
All the individual patches compile cleanly. The compiler used is GCC
14.2.
This patch set has been tested as a whole. Therefore, the tested-by
fields have been added only to one patch in the set.
I've refrained from adding tested-by to most of the patches, so as to
not mislead the reviewer/reader.
A brief note on the unit tests:
o. Configure multipathing, and run link flaps on single link. IOs drop
briefly, but pick up as expected.
o. Configure multipathing, and run link flaps on two links, with a 30
second delay in between. IOs drop briefly, but pick up as expected.
o. Repeat the above tests with 1 queue and 64 queues.
o. Perform tests with Netapp and Pure targets.
All tests were successful.
This set of patches was reviewed before submitting upstream,
and the following review comments were incorporated.
Incorporate review comments from Hannes Reinecke:
Decode target roles explicitly and report unsupported roles.
Remove the empty line before the FLOGI completion else block.
Add a short comment for the NVMe ERSP completion case.
Incorporate review comments from Lee Duncan:
Replace the NVMe LS OXID switch with a direct frame-type check.
Rename the NVMe frame helper to follow fnic function naming style.
Convert the NVMe opcode stats helper to a switch statement.
Share NVMe completion stats accounting and compute duration once.
Link: https://patch.msgid.link/20260724174811.5118-1-kartilak@cisco.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add FNIC_ROLE_CONFIG_MASK and use it to decode firmware role bits when
reading vNIC configuration and probing the PCI device.
Accept FCP and NVMe initiator roles, report FC target and FC-NVMe target
roles explicitly as unsupported, and keep truly undefined role settings on
the existing FC initiator default path.
Log the configured role flags and expose role names for trace output.
Reviewed-by: Sesidhar Baddela <sebaddel@cisco.com>
Reviewed-by: Arulprabhu Ponnusamy <arulponn@cisco.com>
Reviewed-by: Gian Carlo Boffa <gcboffa@cisco.com>
Reviewed-by: Arun Easi <aeasi@cisco.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Karan Tilak Kumar <kartilak@cisco.com>
Co-developed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260724174811.5118-4-kartilak@cisco.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Make the fnic debug macros take struct fnic instead of struct Scsi_Host so
FCP and NVMe initiator roles can share the same logging interface.
Add fnic_printk() to route FCP initiator messages through shost_printk()
and non-SCSI role messages through printk(). Add role and non-SCSI role
messages through printk(). Add role predicates and separate FDLS, FIP, and
NVMe logging masks.
Convert FCS, FIP, SCSI, ISR, and main debug call sites to pass the fnic
instance directly, and keep FIP VLAN MAC descriptors skipped while
reporting unexpected descriptor types.
Reviewed-by: Sesidhar Baddela <sebaddel@cisco.com>
Reviewed-by: Arulprabhu Ponnusamy <arulponn@cisco.com>
Reviewed-by: Gian Carlo Boffa <gcboffa@cisco.com>
Reviewed-by: Arun Easi <aeasi@cisco.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Karan Tilak Kumar <kartilak@cisco.com>
Co-developed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260724174811.5118-2-kartilak@cisco.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Nihar Panda <niharp@linux.ibm.com> says:
Hi Martin and James,
We are submitting zfcp enhancement designed to improve trace logging
for the upcoming v7.3 release.
Regarding the sashiko bot feedback: the majority of the reported
findings are legacy issues rather than regressions caused by this
series. We plan to resolve those separately.
Link: https://patch.msgid.link/20260728044857.2532646-1-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
sysfs unit add failures are seen during FCP devices manual SCSI LUN scans,
indicating the kernel cannot add a LUN, usually because the device is
offline, already exists, no memory or the target port is incorrectly
configured.
Add a new trace to debug zfcp sysfs unit add failures with tag id
ZFCP_DBF_HBA_UAS. This traces wwpn, fcp lun id, return value (error
condition) and associated hba of the device.
Typical unit add store failures as seen below example syslog messages,
Feb 2 10:47:25 systemd-udevd[823]: rport-1:0-2: /etc/udev/
rules.d/41-zfcp-lun-0.0.50c0:0x500507680b26c449:0x01d2000000000000.rules:10
Failed to write ATTR{/sys/devices/css0/0.0.0015/0.0.50c0/0x500507680b26c449
/unit_add}, ignoring: File exists
Feb 2 10:50:03 systemd-udevd[801]: rport-2:0-3: /etc/udev/
rules.d/41-zfcp-lun-0.0.50c0:0x500507680b26c448:0x01d2000000000000.rules:10
Failed to write ATTR{/sys/devices/css0/0.0.0015/0.0.50c0/0x500507680b26c448
/unit_add}, ignoring: Cannot allocate memory
Example zfcpdbf traces for both the errors:
Timestamp : 2026-03-05-07:28:34:029797
Area : HBA
Subarea : 00
Level : 3
Exception : -
CPU ID : 0002
Caller : 0x000001fe345e6d0e
Record ID : 6
Tag : syuast2
Description : syuast2 HBA, unit add, failed, unable to add unit
Request ID : 0x00000000ffffffff
Request status : 0xffffffff
FSF cmnd : 0xffffffff
FSF sequence no: 0xffffffff
WWPN : 0x500507680b25c448
LUN : 0x01d3000000000000
Return Value : 0xfffffff4
Timestamp : 2026-03-05-07:33:04:151807 <== the last record
Area : HBA
Subarea : 00
Level : 3
Exception : -
CPU ID : 0002
Caller : 0x000001fe345e6d0e
Record ID : 6
Tag : syuast2
Description : syuast2 HBA, unit add, failed, unable to add unit
Request ID : 0x00000000ffffffff
Request status : 0xffffffff
FSF cmnd : 0xffffffff
FSF sequence no: 0xffffffff
WWPN : 0x500507680b25c449
LUN : 0x01d0000000000000
Return Value : 0xfffffff4
Link: https://patch.msgid.link/20260728044857.2532646-4-niharp@linux.ibm.com
Signed-off-by: Chinmaya Kajagar <chinmayk@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The FCP channel optionally returns the content of PLOGI and PRLI within
open port response. This information is needed to debug unexpected open
port responses. Pack both PLOGI and PRLI information back-to-back into a
PAYload trace record of type "fsf_els" within existing HBA trace record.
The length of both parts, and thus also the offset of the second part, are
added to the corresponding HBA trace record. Be extra careful regarding
bounds checking.
Since auto port scan in multi-initiator zoning environments can cause a lot
of failed open port responses and trace is enabled by default in the HBA
trace area, chose a trace level 4 above the default of 3 for the
corresponding PAYload trace record to contain PLOGI/PRLI data. This way, it
avoids flooding the PAY area by default.
In the spirit of commit 35f040df97 ("zfcp: retain trace level for SCSI
and HBA FSF response records"), pass the level here. For this, introduce an
additional argument 'level' for zfcp_dbf_pl_write().
zfcpdbf tool partial trace example with PLOGI/PRLI log info after changes:
PLOGI length : 116
PRLI length : 20
Payload time : 2026-01-29-06:19:15:626629
PLOGI/PRLIinfo : 02000000 00000000 80000800 000a0002
00000000 2002000e 1115c62f 2001000e
1115c62f 00000000 00000000 00000000
00000000 80000000 00000000 00000000
00000000 80000000 00000000 000a0000
00010000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 02100014 08002100 00000000
00000000 00000112
Reviewed-by: M Nikhil <nikh1092@linux.ibm.com>
Reviewed-by: Nihar Panda <niharp@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Co-developed-by: Chinmaya Kajagar <chinmayk@linux.ibm.com>
Signed-off-by: Chinmaya Kajagar <chinmayk@linux.ibm.com>
Link: https://patch.msgid.link/20260728044857.2532646-3-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
SRB trace records are logged through hba trace event zfcp_dbf_hba_fsf_uss.
Presently, this trace event has few missing fields in fsf status read
buffer trace records. To fully trace incoming fsf status read buffer (SRB),
the remaining fields are needed to be added to zfcp_dbf_hba_uss structure.
Append all the remaining SRB fields to the existing unsolicited status
trace records.
Extend driver to get 3 bytes source id s_id value from fsf status read
buffer's existing reserved field res3.
To display this change, we also change the external tool `zfcpdbf` in the
s390-tools package.
zfcpdbf tool trace example for HBA area after changes:
Timestamp : 2025-08-22-05:52:04:171750
Area : HBA
Subarea : 00
Level : 2
Exception : -
CPU ID : 0003
Caller : 0x0000021e278c07c8
Record ID : 2
Tag : fssrh_4
Description : fssrh_4 HBA, FSF unsolicited status
Request ID : 0x0000000000004bfc
Request status : 0x00000000
FSF cmnd : 0x00006305
FSF sequence no: 0x00000000
SRB stat type : 0x00000002
SRB stat sub : 0x00000000
SRB D_ID : 0x00fffffd
SRB LUN : 0x0000000000000000
SRB q-design. : 0x0000000000000000
SRB length : 0x0000004c
SRB res1 : 00000000
SRB res2 : 00
SRB class : 0x00000000
SRB res3 : 00
SRB S_ID : 0x0033c048
SRB res4 : 00000000 00000000 00000000 00000000
00000000
SRB pay length : 12
Payload time : 2025-08-22-05:52:04:171743
SRB info : 6104000c 0033c024 0033c02e
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Chinmaya Kajagar <chinmayk@linux.ibm.com>
Link: https://patch.msgid.link/20260728044857.2532646-2-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
David Strahan <david.strahan@microchip.com> says:
These patches are based on Martin Petersen's 7.2/scsi-queue tree
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
7.2/scsi-queue
This patch series includes four patches, with two main functional changes:
1. smartpqi-Fix-AIO-retry-marker-cleared-by-SCSI-core-between-dispatches
On recent Linux kernels the driver can enter a retry loop on the
AIO fast path when a request is retried, looping until timeout, and
a diagnostic path that takes a physical drive offline on AIO-bypass
failure is never entered.
Registers a per-command initialization callback with the SCSI core
so its presence causes the core to skip the per-dispatch clear of
the retry marker, letting it survive the requeue so the AIO-to-RAID
fallback proceeds as intended.
2. smartpqi-add-support-for-CCISS_BIG_PASSTHRU-ioctl
Adds pqi_big_passthru_ioctl() to handle CCISS_BIG_PASSTHRU ioctl
requests. The existing passthru ioctl uses a 16-bit integer for the
I/O buffer size, limiting transfers to 64KB. The big passthru ioctl
uses BIG_IOCTL_Command_struct, which stores the buffer size as a
32-bit integer, allowing the larger transfers required by some
management utilities.
The other two patches:
3. smartpqi-add-new-pci-device-ids
Adds PCI IDs for new Hurray Data, ZTE, and Ramaxel controllers.
No functional changes.
4. smartpqi-update-driver-version-to-2.1.42-011
Updates the driver version string.
No functional changes.
Link: https://patch.msgid.link/20260722220401.6357-1-david.strahan@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
On recent Linux kernels the driver can enter a retry loop on the AIO fast
path when a request is retried, looping until timeout. A diagnostic path
that takes a physical drive offline on AIO-bypass failure is also never
entered on affected kernels.
Register a per-command initialization callback with the SCSI core. Its
presence causes the core to skip the per-dispatch clear, so the retry
marker now survives across the requeue and the AIO-to-RAID fallback
proceeds as intended. The driver takes over the marker's lifetime: it is
zeroed at tag allocation, preserved across the retry requeue so the error
path can act on it, and cleared on terminal completion so the tag starts
clean on its next use.
Fixes: dce5c4afd0 ("scsi: core: Clear driver private data when retrying request")
Co-developed-by: Mike McGowen <mike.mcgowen@microchip.com>
Signed-off-by: Mike McGowen <mike.mcgowen@microchip.com>
Acked-by: Don Brace <don.brace@microchip.com>
Signed-off-by: David Strahan <david.strahan@microchip.com>
Link: https://lore.kernel.org/linux-scsi/20260722220401.6357-1-david.strahan@microchip.com/
Link: https://patch.msgid.link/20260722220401.6357-2-david.strahan@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
- Use the correct name for a struct in kernel-doc
- Add kernel-doc for missing struct members or correct the name
Warning: ./include/ufs/ufshcd.h:201 Excess struct member 'task_tag'
description in 'ufshcd_lrb'
Warning: ./include/ufs/ufshcd.h:220 expecting prototype for struct
ufs_query_resp. Prototype was for struct ufs_query_res instead
Warning: ./include/ufs/ufshcd.h:577 struct member 'suspend_on_no_request'
not described in 'ufs_clk_scaling'
Warning: ./include/ufs/ufshcd.h:1269 struct member 'nortt' not described
in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1269 struct member 'trigger_eh_attr' not
described in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1269 struct member 'timeout_attr' not
described in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1269 struct member 'lsdb_sup' not
described in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1269 struct member 'vcc_off_delay_us' not
described in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1269 Excess struct member 'desc_size'
description in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1269 Excess struct member 'res'
description in 'ufs_hba'
Warning: ./include/ufs/ufshcd.h:1309 struct member 'sq_tail_slot' not
described in 'ufs_hw_queue'
Warning: ./include/ufs/ufshcd.h:1309 Excess struct member 'sq_tp_slot'
description in 'ufs_hw_queue'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260720013759.2979593-1-rdunlap@infradead.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tyrel Datwyler <tyreld@linux.ibm.com> says:
This series adds NVMe/FC initiator support to the ibmvfc driver, enabling
IBM POWER virtual machines to discover and use NVMe namespaces presented by
the IBM Virtual I/O Server (VIOS) over the existing NPIV transport.
The ibmvfc driver communicates with the VIOS via a CRQ-based protocol. With
this series the VIOS can present both SCSI/FCP and NVMe/FC targets through
parallel sets of protocol-specific MAD opcodes, fabric login flows, and
sub-CRQ channels.
The series is organized into three phases:
Patches 1-5: Bug fixes and preparatory refactoring
Four pre-existing bugs are fixed before any NVMe/FC work is introduced:
a deadlock in the MAD send-failure path (locked done variant called with
host_lock already held), a race during driver teardown where
rport_add_work_q work items can outlive the FC host, a NULL event
dereference in ibmvfc_tgt_implicit_logout_and_del, and an allocator
mismatch where mempool-allocated ibmvfc_target structs are freed via kfree
rather than mempool_free. Patch 5 moves the target list and count from
struct ibmvfc_host into struct ibmvfc_channels as the structural
prerequisite for independent per-protocol target tracking.
Patches 6-27: Protocol interface and driver scaffolding
Patch 6 extends ibmvfc.h with NVMe/FC protocol definitions: MAD opcodes,
capability flags, the v3 command layout, the fabric login MAD, async
sub-CRQ event format, and updated channel enquiry/setup fields. Patch 7
splits ibmvfc.c into ibmvfc-core.c and the new ibmvfc-nvme.c/h, registers
an nvme_fc_port_template with stub callbacks, and adds NVMe module
parameters. The remaining patches build the NVMe/FC plumbing: NVMe
channel-group initialization, sub-CRQ lifecycle management, protocol-
specific fabric login flow, target discovery, PLOGI/PRLI/query-target,
implicit logout, move-login, protocol-driven target allocation, NVMe
target deletion, state machine updates, and local/remote port registration
with the NVMe-FC transport layer.
Patches 28-33: NVMe-FC LLDD callbacks and I/O path
Implements the full nvme_fc_port_template: create_queue/delete_queue map
NVMe controller queues to sub-CRQ handles; ls_req submits FC-LS frames via
the ibmvfc passthru MAD; fcp_io builds and submits NVMe FCP commands via
the NVMe sub-CRQ and completes them via nvme_fc_rcv_fcp_rsp(); ls_abort
and fcp_abort cancel outstanding requests via NVMF cancel MADs. Patch 33
extends the purge path to fail outstanding NVMe FCP and LS requests during
host reset and link-down events.
Link: https://patch.msgid.link/20260723000149.969416-1-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The current purge code for flushing outstanding commands during a
transport reset only deals with SCSI commands. Rename the
ibmvfc_scsi_eh_done completion handler to ibmvfc_vfc_eh_done and wire it
to correctly complete nvme fcp and ls commands when flushing the
inflight command list during a reset.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-34-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Implement the NVMe-FC FCP abort callback by issuing an NVMF cancel MAD
on the same submission queue used by the original FCP request.
Use the original request event stored in abort_req->private to recover
the associated ibmvfc queue, then allocate a new event from that queue
so the cancel is sent on the matching nvme_scrq. Factor the TMF setup
into a dedicated helper, mirroring the LS abort path, and populate the
cancel key, task tag, target WWPN, and association ID needed for the
VIOS NVMF abort request.
The abort path sends the cancel synchronously, waits for completion,
frees the temporary event, and logs non-zero MAD status values for
debugging.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-33-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Implement the NVMe FC-LS abort callback by issuing an ibmvfc cancel MAD
to the VIOS for the outstanding link-service request.
Use the saved event pointer from the original FC-LS request to identify
the command to cancel, submit the cancel operation, and complete the
abort request based on the returned status.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-32-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add helpers to initialize an ibmvfc command from an nvmefc_fcp_req,
map request scatterlists into either an inline descriptor or an external
DMA pool list, and submit the request on the selected NVMe hardware
queue. On completion, translate ibmvfc status into the NVMe-FC response
format, including transferred length and CQE handling for no-DMA
responses.
Also store the NVMe request pointer in struct ibmvfc_event so the
completion path can finish the original request.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-31-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
NVMe FC Link Service commands are required to use the ibmvfc_passthru
MAD. Initialize a pssthru mad for the target port including the DMA
addresses for the FC4_LS request and response as well as the max length
of each IU as provided in the nvmefc_ls_req struct. FC4_LS commands are
sent via the primary CRQ. Further, store the assoc_id during a create
association request as this is a required field in our vfc_cmd struct
for nvme_fcp_io commands.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-30-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Implement the NVMe-FC queue create and delete callbacks and map NVMe
controller queues onto ibmvfc hardware queues.
Use qidx of NVMe controller queue to map onto a ibmvfc_queue channel.
The Admin queue is always qidx 0 and general practice among other
drivers is to map both the Admin queue and first IO queue to the same HW
queue. Add a new ibmvfc_nvme_qhandle struct that will be used as the
opaque queue handle by the NVMe-FC layer when issuing fcp IO.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-29-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some common functions will require visibility by both SCSI and NVMe
protocols. Make common ibmvfc helper routines available to the NVMe
support code.
Remove static from the core event allocation, event initialization,
event free, target release, command error, and event send helpers, and
declare them in ibmvfc.h. This allows ibmvfc-nvme.c to reuse the
existing event and target infrastructure.
No functional change is intended.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-28-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Export ibmvfc_debug so the NVMe support code can use the
existing ibmvfc_dbg logging macro.
The debug control variable is currently file-local to the core driver,
which prevents protocol-specific code in ibmvfc-nvme.c from using the
shared debug infrastructure. Make the variable global within the module
and declare it in ibmvfc-nvme.h.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-27-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add an NVMe-specific remote-port add helper and update the rport worker
thread to walk the NVMe target list, register new NVMe remote ports, and
rescan existing ones through the NVMe-FC midlayer. Also handle delete
and delete-with-logout transitions for NVMe remote ports in the same
worker context used for SCSI rports.
This keeps remote-port registration serialized in the existing worker
model while allowing NVMe targets to participate in the common target
state machine.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-26-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Register the local NVMe/FC port only after fabric login has completed.
The VIOS returns the client port ID in the fabric login response, and
that port ID is required to populate the local-port information passed
to the NVMe-FC midlayer. Delay local-port registration until that data
is available and update the registration helper accordingly.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-25-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Implement the initial NVMe/FC local-port and remote-port registration
functions that notify the NVMe-FC midlayr of port discovery and loss.
Register the local port with the NVMe-FC transport, register discovered
remote ports against that local port, and add matching unregister paths
that wait for the NVMe-FC core to complete asynchronous deletion before
dropping driver references. Also store driver-private host and target
pointers in the registered NVMe-FC port objects.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-24-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Update the host work loop and target state-machine helpers to process
NVMe targets in addition to SCSI targets.
Check both protocol-specific target lists when determining whether there
is initialization or logout work pending, and extend the query, target
init, and target delete phases to dispatch work for NVMe targets using
the same common state-machine callbacks.
This allows the existing discovery and login state machine to drive
NVMe/FC targets through query, login, and deletion without duplicating
the control flow.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-23-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Extend target deletion paths to process NVMe targets as well as SCSI
targets.
Update link-down, and host reinitialization flows to walk both the SCSI
and NVMe target lists when marking targets for deletion. This ensures
that protocol-specific target state stays consistent across adapter
resets and fabric events.
Rename ibmvfc_relogin to ibmvfc_scsi_relogin as it acts on a scsi
command.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-22-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Allocate discovered targets onto the channel-group list that matches
their protocol.
When a target is created, use the discovered protocol type to decide
which list it belongs on. This keeps protocol-specific discovery
results isolated and allows later state-machine and remote-port code to
walk the correct target set.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-21-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Extend PRLI handling code to support NVMe/FC targets.
When the target protocol is NVMe/FC, issue the NVMe process login MAD,
set the NVMe FC-4 type, and populate NVMe-specific service parameters.
On completion, decode the returned PRLI service parameters and derive
the appropriate remote-port roles for NVMe initiator, target, and
discovery ports.
Keep the existing SCSI PRLI flow unchanged while allowing the common
target state machine to complete login for NVMe/FC targets.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-19-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Expand the target login path to issue the NVMe/FC-specific port login
MAD for NVMe targets.
Select the correct PLOGI MAD opcode based on the target protocol and
include the protocol name in success and failure logging. The rest of
the target login flow remains shared with the existing SCSI
implementation.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-18-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add protocol-specific handling for implicit logout and move-login
operations on NVMe/FC targets.
Select the NVMe/FC-specific implicit logout opcode when operating on an
NVMe target and update the associated logging so protocol-specific
operations are visible in debug output. This extends the existing target
relogin and migration-related flows to work with NVMe targets as well as
SCSI targets.
These changes are needed so target reauthentication and target movement
continue to work once NVMe/FC targets are added to the driver's state
machine.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-17-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Extend target discovery to send protocol-specific discover-target MADs
for NVMe/FC.
Use the protocol-aware discovery helper to build an NVMe discover-target
request, submit it when NVMe/FC support is active, and process the
returned target count using the NVMe channel group's discovery buffer.
This allows the driver to discover NVMe/FC targets in parallel with the
existing SCSI discovery flow while keeping protocol-specific target data
separate.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-16-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
