Commit b8da7400 authored by Jens Axboe's avatar Jens Axboe
Browse files

Merge tag 'nvme-6.17-2025-07-22' of git://git.infradead.org/nvme into for-6.17/block 

Pull NVMe updates from Christoph:

"- try PCIe function level reset on init failure (Keith Busch)
 - log TLS handshake failures at error level (Maurizio Lombardi)
 - pci-epf: do not complete commands twice if nvmet_req_init() fails
   (Rick Wertenbroek)
 - misc cleanups (Alok Tiwari)"

* tag 'nvme-6.17-2025-07-22' of git://git.infradead.org/nvme:
  nvme-pci: try function level reset on init failure
  nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails
  nvme-tcp: log TLS handshake failures at error level
  docs: nvme: fix grammar in nvme-pci-endpoint-target.rst
  nvme: fix typo in status code constant for self-test in progress
  nvmet: remove redundant assignment of error code in nvmet_ns_enable()
  nvme: fix incorrect variable in io cqes error message
  nvme: fix multiple spelling and grammar issues in host drivers
parents 675f9405 5b2c214a

Documentation/nvme/nvme-pci-endpoint-target.rst

+11 −11
Original line number Diff line number Diff line
@@ -6,21 +6,21 @@ NVMe PCI Endpoint Function Target 


:Author: Damien Le Moal <dlemoal@kernel.org>



The NVMe PCI endpoint function target driver implements a NVMe PCIe controller

using a NVMe fabrics target controller configured with the PCI transport type.

The NVMe PCI endpoint function target driver implements an NVMe PCIe controller

using an NVMe fabrics target controller configured with the PCI transport type.



Overview

========



The NVMe PCI endpoint function target driver allows exposing a NVMe target

The NVMe PCI endpoint function target driver allows exposing an NVMe target

controller over a PCIe link, thus implementing an NVMe PCIe device similar to a

regular M.2 SSD. The target controller is created in the same manner as when

using NVMe over fabrics: the controller represents the interface to an NVMe

subsystem using a port. The port transfer type must be configured to be

"pci". The subsystem can be configured to have namespaces backed by regular

files or block devices, or can use NVMe passthrough to expose to the PCI host an

existing physical NVMe device or a NVMe fabrics host controller (e.g. a NVMe TCP

host controller).

existing physical NVMe device or an NVMe fabrics host controller (e.g. a NVMe

TCP host controller).



The NVMe PCI endpoint function target driver relies as much as possible on the

NVMe target core code to parse and execute NVMe commands submitted by the PCIe
@@ -181,10 +181,10 @@ Creating an NVMe endpoint device is a two step process. First, an NVMe target 
subsystem and port must be defined. Second, the NVMe PCI endpoint device must

be setup and bound to the subsystem and port created.



Creating a NVMe Subsystem and Port

----------------------------------

Creating an NVMe Subsystem and Port

-----------------------------------



Details about how to configure a NVMe target subsystem and port are outside the

Details about how to configure an NVMe target subsystem and port are outside the

scope of this document. The following only provides a simple example of a port

and subsystem with a single namespace backed by a null_blk device.
@@ -234,8 +234,8 @@ Finally, create the target port and link it to the subsystem:: 
        # ln -s /sys/kernel/config/nvmet/subsystems/nvmepf.0.nqn \

                /sys/kernel/config/nvmet/ports/1/subsystems/nvmepf.0.nqn



Creating a NVMe PCI Endpoint Device

-----------------------------------

Creating an NVMe PCI Endpoint Device

------------------------------------



With the NVMe target subsystem and port ready for use, the NVMe PCI endpoint

device can now be created and enabled. The NVMe PCI endpoint target driver
@@ -303,7 +303,7 @@ device controller:: 


        nvmet_pci_epf nvmet_pci_epf.0: Enabling controller



On the host side, the NVMe PCI endpoint function target device will is

On the host side, the NVMe PCI endpoint function target device is

discoverable as a PCI device, with the vendor ID and device ID as configured::



        # lspci -n

drivers/nvme/host/apple.c

+2 −2
Original line number Diff line number Diff line
@@ -301,8 +301,8 @@ static void apple_nvme_submit_cmd(struct apple_nvme_queue *q, 
	memcpy(&q->sqes[tag], cmd, sizeof(*cmd));



	/*

	 * This lock here doesn't make much sense at a first glace but

	 * removing it will result in occasional missed completetion

	 * This lock here doesn't make much sense at a first glance but

	 * removing it will result in occasional missed completion

	 * interrupts even though the commands still appear on the CQ.

	 * It's unclear why this happens but our best guess is that

	 * there is a bug in the firmware triggered when a new command

drivers/nvme/host/constants.c

+2 −2
Original line number Diff line number Diff line
@@ -133,7 +133,7 @@ static const char * const nvme_statuses[] = { 
	[NVME_SC_NS_NOT_ATTACHED] = "Namespace Not Attached",

	[NVME_SC_THIN_PROV_NOT_SUPP] = "Thin Provisioning Not Supported",

	[NVME_SC_CTRL_LIST_INVALID] = "Controller List Invalid",

	[NVME_SC_SELT_TEST_IN_PROGRESS] = "Device Self-test In Progress",

	[NVME_SC_SELF_TEST_IN_PROGRESS] = "Device Self-test In Progress",

	[NVME_SC_BP_WRITE_PROHIBITED] = "Boot Partition Write Prohibited",

	[NVME_SC_CTRL_ID_INVALID] = "Invalid Controller Identifier",

	[NVME_SC_SEC_CTRL_STATE_INVALID] = "Invalid Secondary Controller State",

drivers/nvme/host/core.c

+1 −1
Original line number Diff line number Diff line
@@ -4286,7 +4286,7 @@ static void nvme_scan_ns(struct nvme_ctrl *ctrl, unsigned nsid) 
	}



	/*

	 * If available try to use the Command Set Idependent Identify Namespace

	 * If available try to use the Command Set Independent Identify Namespace

	 * data structure to find all the generic information that is needed to

	 * set up a namespace.  If not fall back to the legacy version.

	 */

drivers/nvme/host/fc.c

+5 −5
Original line number Diff line number Diff line
@@ -899,7 +899,7 @@ EXPORT_SYMBOL_GPL(nvme_fc_set_remoteport_devloss); 
 * may crash.

 *

 * As such:

 * Wrapper all the dma routines and check the dev pointer.

 * Wrap all the dma routines and check the dev pointer.

 *

 * If simple mappings (return just a dma address, we'll noop them,

 * returning a dma address of 0.
@@ -1955,8 +1955,8 @@ nvme_fc_fcpio_done(struct nvmefc_fcp_req *req) 
	}



	/*

	 * For the linux implementation, if we have an unsucceesful

	 * status, they blk-mq layer can typically be called with the

	 * For the linux implementation, if we have an unsuccessful

	 * status, the blk-mq layer can typically be called with the

	 * non-zero status and the content of the cqe isn't important.

	 */

	if (status)
@@ -2429,7 +2429,7 @@ static bool nvme_fc_terminate_exchange(struct request *req, void *data) 


/*

 * This routine runs through all outstanding commands on the association

 * and aborts them.  This routine is typically be called by the

 * and aborts them.  This routine is typically called by the

 * delete_association routine. It is also called due to an error during

 * reconnect. In that scenario, it is most likely a command that initializes

 * the controller, including fabric Connect commands on io queues, that
@@ -2622,7 +2622,7 @@ nvme_fc_unmap_data(struct nvme_fc_ctrl *ctrl, struct request *rq, 
 * as part of the exchange.  The CQE is the last thing for the io,

 * which is transferred (explicitly or implicitly) with the RSP IU

 * sent on the exchange. After the CQE is received, the FC exchange is

 * terminaed and the Exchange may be used on a different io.

 * terminated and the Exchange may be used on a different io.

 *

 * The transport to LLDD api has the transport making a request for a

 * new fcp io request to the LLDD. The LLDD then allocates a FC exchange