Patch "nvme/quirk: Add a delay before checking for adapter readiness" has been added to the 4.4-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
nvme/quirk: Add a delay before checking for adapter readiness
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
nvme-quirk-add-a-delay-before-checking-for-adapter-readiness.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
54adc01055b75ec8769c5a36574c7a0895c0c0b2Mon Sep 17 00:00:00 2001
From: "Guilherme G. Piccoli" <[email protected]>
Date: Tue, 14 Jun 2016 18:22:41 -0300
Subject: nvme/quirk: Add a delay before checking for adapter readiness
From: Guilherme G. Piccoli <[email protected]>
commit 54adc01055b75ec8769c5a36574c7a0895c0c0b2 upstream.
When disabling the controller, the specification says the register NVME_REG_CC should be written and then driver needs to wait the adapter to be ready, which is checked by reading another register bit (NVME_CSTS_RDY). There's a timeout validation in this checking, so in case this timeout is reached the driver gives up and removes the adapter from the system.
After a firmware activation procedure, the PCI_DEVICE(0x1c58, 0x0003) (HGST adapter) end up being removed if we issue a reset_controller, because driver keeps verifying the NVME_REG_CSTS until the timeout is reached. This patch adds a necessary quirk for this adapter, by introducing a delay before nvme_wait_ready(), so the reset procedure is able to be completed. This quirk is needed because just increasing the timeout is not enough in case of this adapter - the driver must wait before start reading NVME_REG_CSTS register on this specific device.
--- drivers/nvme/host/nvme.h | 7 +++++++ drivers/nvme/host/pci.c | 10 ++++++++++ 2 files changed, 17 insertions(+)
drivers/nvme/host/nvme.h +7 -0
@@ -27,6 +27,13 @@ enum { NVME_NS_LIGHTNVM = 1, }; +/* The below value is the specific amount of delay needed before checking +* readiness in case of the PCI_DEVICE(0x1c58, 0x0003), which needs the +* NVME_QUIRK_DELAY_BEFORE_CHK_RDY quirk enabled. The value (in ms) was +* found empirically. +*/ +#define NVME_QUIRK_DELAY_AMOUNT 2000 +/* * Represents an NVM Express device. Each nvme_dev is a PCI function. */
drivers/nvme/host/pci.c +10 -0
@@ -1633,10 +1633,20 @@ static int nvme_wait_ready(struct nvme_d*/ static int nvme_disable_ctrl (struct nvme_dev *dev,u64 cap) { +struct pci_dev *pdev =to_pci_dev (dev->dev); + dev->ctrl_config &= ~NVME_CC_SHN_MASK ; dev->ctrl_config &= ~NVME_CC_ENABLE ;writel (dev->ctrl_config, &dev->bar->cc); +/* Checking for dev->tagset is a trick to avoid sleeping on module +* load, since we only need the quirk on reset_controller. Notice +* that the HGST device needs this delay only in firmware activation +* procedure; unfortunately we have no (easy) way to verify this. +*/ +if (pdev->vendor ==0x1c58 && pdev->device ==0x0003 && dev->tagset) +msleep (NVME_QUIRK_DELAY_AMOUNT ); +return nvme_wait_ready (dev, cap, false); }
Patches currently in stable-queue which might be from [email protected] are
queue-4.4/nvme-apply-delay_before_chk_rdy-quirk-at-probe-time-too.patch queue-4.4/nvme-quirk-add-a-delay-before-checking-for-adapter-readiness.patch