From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Is there any plan to add "quirk" mechanism to SPDK?
Date: Fri, 09 Sep 2016 18:03:39 +0000 [thread overview]
Message-ID: <1473444217.2810.17.camel@intel.com> (raw)
In-Reply-To: CAAZN+A1iQPYhXMfJCrwN3eL1aeYoY6YM+nqDaWoAz8heiyNbjQ@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]
Currently we have no mechanism for adding device-specific quirks to the SPDK NVMe driver. We'd certainly consider adding quirks in the same fashion as the Linux kernel driver though, and would welcome patches that improved the applicability of SPDK to a wider range of (potentially out of spec) devices. I'm sure over time the team at Intel working on SPDK will add this, but it is not on our immediate roadmap, so patches from the community would be the best way to get this going.
Thanks,
Ben
On Thu, 2016-09-08 at 14:25 +0800, Wang Weber wrote:
Hi,
In online FW upgrade process, the memblaze Pblaze4 NVMe device requires an extra delay during controller reset process. The following patch email from HGST describes the similar issue in detail.
Subject: [PATCH v3] nvme/quirk: Add a delay before checking for adapter readiness
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.
The standard Linux NVMe driver now has quirk “NVME_QUIRK_DELAY_BEFORE_CHK_RDY” for HGST and memblaze devices. Is there any plan to add this to SPDK?
Thanks,
-Wenbo
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org<mailto:SPDK(a)lists.01.org>
https://lists.01.org/mailman/listinfo/spdk
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3345 bytes --]
next reply other threads:[~2016-09-09 18:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 18:03 Walker, Benjamin [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-09-28 16:33 [SPDK] Is there any plan to add "quirk" mechanism to SPDK? Walker, Benjamin
2016-09-28 2:16 Wang Weber
2016-09-12 16:20 Daniel Verkamp
2016-09-08 6:25 Wang Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1473444217.2810.17.camel@intel.com \
--to=spdk@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.