linux-toradex.git/include/linux/nvme-fc-driver.h, branch v6.1

scsi: nvme-fc: Add new routine nvme_fc_io_getuuid()

2022-05-20T00:24:56+00:00

Add nvme_fc_io_getuuid() to the nvme-fc transport. The routine is invoked
by the FC LLDD on a per-I/O request basis.  The routine translates from the
FC-specific request structure to the bio and the cgroup structure in order
to obtain the FC appid stored in the cgroup structure. If a value is not
set or a bio is not found, a NULL appid (aka uuid) will be returned to the
LLDD.

Link: https://lore.kernel.org/r/20220519123110.17361-2-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke 
Reviewed-by: Himanshu Madhani 
Acked-by: Christoph Hellwig 
Signed-off-by: Muneendra Kumar 
Signed-off-by: James Smart 
Signed-off-by: Martin K. Petersen

nvme-fc: fix a typo

2022-02-28T11:45:04+00:00

subsytem -> subsystem

Signed-off-by: Qinghua Jin 
Signed-off-by: Christoph Hellwig

nvme-fc: add support for ->map_queues

2021-10-20T17:16:00+00:00

NVMe FC don't have support for map queues, unlike the PCI, RDMA and TCP
transports.  Add a ->map_queues callout for the LLDDs to provide such
functionality.

Signed-off-by: Saurav Kashyap 
Signed-off-by: Nilesh Javali 
Signed-off-by: Christoph Hellwig

nvme-fc: drop a duplicated word in a comment

2020-07-29T05:45:20+00:00

Drop the repeated word "a" in a comment.

Signed-off-by: Randy Dunlap 
Signed-off-by: Christoph Hellwig

nvme-fc and nvmet-fc: revise LLDD api for LS reception and LS request

2020-05-09T22:18:33+00:00

The current LLDD api has:
  nvme-fc: contains api for transport to do LS requests (and aborts of
    them). However, there is no interface for reception of LS's and sending
    responses for them.
  nvmet-fc: contains api for transport to do reception of LS's and sending
    of responses for them. However, there is no interface for doing LS
    requests.

Revise the api's so that both nvme-fc and nvmet-fc can send LS's, as well
as receiving LS's and sending their responses.

Change name of the rcv_ls_req struct to better reflect generic use as
a context to used to send an ls rsp. Specifically:
  nvmefc_tgt_ls_req -> nvmefc_ls_rsp
  nvmefc_tgt_ls_req.nvmet_fc_private -> nvmefc_ls_rsp.nvme_fc_private

Change nvmet_fc_rcv_ls_req() calling sequence to provide handle that
can be used by transport in later LS request sequences for an association.

nvme-fc nvmet_fc nvme_fcloop:
  Revise to adapt to changed names in api header.
  Change calling sequence to nvmet_fc_rcv_ls_req() for hosthandle.
  Add stubs for new interfaces:
    host/fc.c: nvme_fc_rcv_ls_req()
    target/fc.c: nvmet_fc_invalidate_host()

lpfc:
  Revise to adapt code to changed names in api header.
  Change calling sequence to nvmet_fc_rcv_ls_req() for hosthandle.

Signed-off-by: James Smart 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Himanshu Madhani 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

nvme-fc: Revert "add module to ops template to allow module references"

2020-04-04T07:09:39+00:00

The original patch was to resolve the lldd being able to be unloaded
while being used to talk to the boot device of the system. However, the
end result of the original patch is that any driver unload while a nvme
controller is live via the lldd is now being prohibited. Given the module
reference, the module teardown routine can't be called, thus there's no
way, other than manual actions to terminate the controllers.

Fixes: 863fbae929c7 ("nvme_fc: add module to ops template to allow module references")
Cc:  # v5.4+
Signed-off-by: James Smart 
Reviewed-by: Himanshu Madhani 
Signed-off-by: Christoph Hellwig

nvme_fc: add module to ops template to allow module references

2019-11-26T17:48:27+00:00

In nvme-fc: it's possible to have connected active controllers
and as no references are taken on the LLDD, the LLDD can be
unloaded.  The controller would enter a reconnect state and as
long as the LLDD resumed within the reconnect timeout, the
controller would resume.  But if a namespace on the controller
is the root device, allowing the driver to unload can be problematic.
To reload the driver, it may require new io to the boot device,
and as it's no longer connected we get into a catch-22 that
eventually fails, and the system locks up.

Fix this issue by taking a module reference for every connected
controller (which is what the core layer did to the transport
module). Reference is cleared when the controller is removed.

Acked-by: Himanshu Madhani 
Reviewed-by: Christoph Hellwig 
Signed-off-by: James Smart 
Signed-off-by: Keith Busch

scsi: qla2xxx: Modify NVMe include directives

2019-08-13T01:34:08+00:00

Since struct sg_table is used in nvme-fc-driver.h, include
 from that header file.

Since no definitions or declarations from  are used in the
qla_nvme.h header file, do not include  from that header
file.

Cc: Himanshu Madhani 
Signed-off-by: Bart Van Assche 
Tested-by: Himanshu Madhani 
Reviewed-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen

nvmet-fc: add transport discovery change event callback support

2019-06-21T09:08:37+00:00

This patch adds support for the nvmet discovery_change transport op.
In turn, the transport adds it's own LLDD api callback discovery_event
op to request the LLDD to generate an RSCN for the discovery change.

Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Arun Easi 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig

scsi: scsi_transport_fc: nvme: display FC-NVMe port roles

2019-04-13T00:09:34+00:00

Currently the FC-NVMe driver is leverating the SCSI FC transport class to
access the remote ports. Which means that all FC-NVMe remote ports will be
visible to the fc transport layer, but due to missing definitions the port
roles will always be 'unknown'.  This patch adds the missing definitions to
the fc transport class to that the port roles are correctly displayed.

Signed-off-by: Hannes Reinecke 
Reviewed-by: James Smart 
Reviewed-by: Ewan D. Milne 
Reviewed-by: Giridhar Malavali 
Reviewed-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen