- 29 Feb, 2016 40 commits
-
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Otherwise we're never going to complete a command when it is restarted just after we completed all other outstanding commands in nvme_clear_queue. The controller must be disabled prior to completing a presumed lost command, do this by directly shutting down the controller before queueing the reset work, and return EH_HANDLED from the timeout handler after we shut the controller down. Signed-off-by:
Keith Busch <keith.busch@intel.com> [hch: split and rebase] Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit e1569a16) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Don't delete the controller from dev_list before queuing a reset, instead just check for it being reset in the polling kthread. This allows to remove the dev_list_lock in various places, and in addition we can simply rely on checking the queue_work return value to see if we could reset a controller. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 To properly document how we are using a negative Linux error value to communicate request cancellations inside the driver. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 We want to be able to return bettern error values frmo nvme_timeout, which is significantly easier if the two functions are merged. Also clean up and reduce the printk spew so that we only get one message per abort. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 There is nothing it protects, but it makes lockdep unhappy in many different ways. Signed-off-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1531539Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Without this we can easily get bad derferences on nvmeq->d_db when the nvme kthread tries to poll the CQs for controllers that are in half initialized state. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Half initialized queues due to kernel error returns or timeout are still a good reason to give up on initializing a controller. Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1531539 The "|" operator has higher precedence than "?:" so this didn't work as intended. I had previously fixed this bug, but it we copied the older unfixed version when we moved the function between files. Fixes: 1673f1f0 ('nvme: move block_device_operations and ns/ctrl freeing to common code') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1531539 The nvme_user_cmd function was recently moved around from one file to another, which made a warning reappear that I had fixed before at some point: drivers/nvme/host/core.c: In function 'nvme_user_cmd': drivers/nvme/host/core.c:424:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] This applies the same workaround that we have elsewhere in the driver with an extra type cast to uintptr_t. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 1673f1f0 ("nvme: move block_device_operations and ns/ctrl freeing to common code") Link: https://lkml.org/lkml/2015/10/9/611Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Looks like I didn't test with CONFIG_NVM enabled, and neither did the build bot. Most of this is really weird crazy shit in the lighnvm support, though. Struct nvme_ns is a structure for the NVM I/O command set, and it has no business poking into it. Second this commit: commit 47b3115a Author: Wenwei Tao <ww.tao0320@gmail.com> Date: Fri Nov 20 13:47:55 2015 +0100 nvme: lightnvm: use admin queues for admin cmds Does even more crazy stuff. If a function gets a request_queue parameter passed it'd better use that and not look for another one. Signed-off-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1531539 This patch moves the blk_integrity_payload definition outside the CONFIG_BLK_DEV_INTERITY dependency and provides empty function implementations when the kernel configuration disables integrity extensions. This simplifies drivers that make use of these to map user data so they don't need to repeat the same configuration checks. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Split out a helper that just issues the Set Features and interprets the result which can go to common code, and document why we are ignoring non-timeout error returns in the PCIe driver. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 For this we need to add a proper controller init routine and a list of all controllers that is in addition to the list of PCIe controllers, which stays in pci.c. Note that we remove the sysfs device when the last reference to a controller is dropped now - the old code would have kept it around longer, which doesn't make much sense. This requires a new ->reset_ctrl operation to implement controleller resets, and a new ->write_reg32 operation that is required to implement subsystem resets. We also now store caches copied of the NVMe compliance version and the flag if a controller is attached to a subsystem or not in the generic controller structure now. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 The namespace scanning code has been mostly generic already, we just need to store a pointer to the tagset in the nvme_ctrl structure, and add a method to check if a controller is I/O incapable. The latter will hopefully be replaced by a proper controller state machine soon. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 We want to record the identify and CAP values even if no I/O queue is available. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 And add the 64-bit register read operation for it. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Remove the calculation of all the bits written into the CC register into nvme_enable_ctrl, so that they can be moved into the core NVMe driver in the future. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Add an enum for all workarounds not in the spec and identify the affected controllers at probe time. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 This moves the block_device_operations over to common code mostly as-is. The only change is that the ns and ctrl refcounting got some small refcounting to have wrappers around the kref_put operations. A new free_ctrl operation is added to allow the PCI driver to free it's ressources on the final drop. Signed-off-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Use the integrity API to pass through metadata from userspace. For PI enabled devices this means that we now validate the reftag, which seems like an unintentional ommission in the old code. Thanks to Keith Busch for testing and fixes. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Add a separate nvme_submit_user_cmd for commands that directly DMA to or from userspace. We'll add metadata support to that soon and the common version would become too messy. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 And mark them inline so that we don't slow down the I/O submission path by having to turn it into a forced out of line call. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 And mark it inline so that we don't slow down the completion path by having to turn it into a forced out of line call. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 This is the counter part to nvme_map_data. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 This "backports" the structure I've used for the fabrics driver. It mostly started out as a cleanup so that I could actually understand the code, but I think it also qualifies as a micro-optimization due to the reduced time we hold q_lock and disable interrupts. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Pass back a true/false value instead of the length which needs a compare with the bytes in the request and drop the pointless gfp_t argument. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 The new struct nvme_ctrl will be used by the common NVMe code that sits on top of struct request_queue and the new nvme_ctrl_ops abstraction. It only contains the bare minimum required, which consists of values sampled during controller probe, the admin queue pointer and a second struct device pointer at the moment, but more will follow later. Only values that are not used in the I/O fast path should be moved to struct nvme_ctrl so that drivers can optimize their cache line usage easily. That's also the reason why we have two device pointers as the struct device is used for DMA mapping purposes. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Use the vendor ID from the identify data instead of the PCI device to make the SCSI translation layer independent from the PCI driver. The NVMe spec defines them as having the same value for current PCIe devices. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 This makes life easier for future non-PCI drivers where access to the registers might be more complicated. Note that Linux drivers are pretty evenly split between the two versions, and in fact the NVMe driver already uses offsets for the doorbells. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Create a new core.c and start by adding the command submission helpers to it, which are already abstracted away from the actual hardware queues by the block layer. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 This structure is specific to the PCIe driver internals and should be moved to pci.c. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1531539Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1531539 We already have the reserved flag, and a nowait flag awkwardly encoded as a gfp_t. Add a real flags argument to make the scheme more extensible and allow for a nicer calling convention. Signed-off-by:
-
Jens Axboe authored
BugLink: http://bugs.launchpad.net/bugs/1531539 null_blk defines an empty version of this ops structure if CONFIG_NVM isn't set, but it doesn't know the type. Move those bits out of the protection of CONFIG_NVM in the main lightnvm include. Signed-off-by:
-
Matias Bjørling authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Now that a device can be managed using the system blocks, a method to reset the device is necessary as well. This patch introduces logic to reset the device easily to factory state and exposes it through an ioctl. The ioctl takes the following flags: NVM_FACTORY_ERASE_ONLY_USER By default all blocks, except host-reserved blocks are erased upon factory reset. Instead of this, only erase host-reserved blocks. NVM_FACTORY_RESET_HOST_BLKS Mark host-reserved blocks to be erased and set their type to free. NVM_FACTORY_RESET_GRWN_BBLKS Mark "grown bad blocks" to be erased and set their type to free. Signed-off-by:
Matias Bjørling <m@bjorling.me> Signed-off-by:
-
Matias Bjørling authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Use system block information to register the appropriate media manager. This enables the LightNVM subsystem to instantiate a media manager selected by the user, instead of relying on automatic detection by each media manager loaded in the kernel. A device must now be initialized before it can proceed to initialize its media manager. Upon initialization, the configured media manager is automatically initialized as well. Signed-off-by:
-
Matias Bjørling authored
BugLink: http://bugs.launchpad.net/bugs/1531539 Based on the previous patch, we now introduce an ioctl to initialize the device using nvm_init_sysblock and create the necessary system blocks. The user may specify the media manager that they wish to instantiate on top. Default from user-space will be "gennvm". Signed-off-by:
-
