From: Dmytro Bagrii <dimich.dmb@gmail.com>
To: linux-nvme@lists.infradead.org
Subject: Workaround proposition for pre-2.0 controllers
Date: Wed, 12 Aug 2026 21:13:44 +0300 [thread overview]
Message-ID: <7098b4f3-8ee9-4e80-a517-4204726308a0@gmail.com> (raw)
Hi All,
There is a known issue with pre-2.0 controllers that causes non-volatile
ErrCount to increment at every boot. An example of such controller is
144d:a808 SM981/PM981/PM983 NVMe SSD Controller found in Samsung SSD 970
PRO.
This is definitely a flaw of firmware implementations that treat Invalid
Field in Command as an error worth loging and incrementing the counter,
rather than simply return an error code. However, it is unlikely that
firmwares for existing devices will ever be updated, especially by
manufacturers that no longer active.
The issue confuses userspace disk health monitoring tools and make users
prone to overlooking real errors.
My proposition is to allow to workaround the issue with a quirk flag.
Since it is known that specific controller does not support
nvme_admin_identify opcode with cns=5 and cns=6, issuing these commands
can be omitted. Using quirk module option allows users to decide whether
to workaround the issue or not.
Whether to add a quirk to nvme_id_table[] for known affected controllers
is out of scope of this proposition.
Option 1: re-use NVME_QUIRK_IDENTIFY_CNS by extending its effect for
versions >= 1.2.0, not only for 1.1.0 <= version < 1.2.0.
Pros: Minor code changes.
Cons:
It's not yet clear to me whether the driver can issue
nvme_admin_identify with cns > 6 if controller already rejected cns=5
and cns=6.
The impact for devices that already have NVME_QUIRK_IDENTIFY_CNS set
but claim support for version > 1.1.0 is unclear, if any such devices exist.
By the way, the comment for NVME_QUIRK_IDENTIFY_CNS in
drivers/nvme/host/nvme.h is misleading: it states that "The controller
doesn't handle Identify value others than 0 or 1 correctly" but
nvme_id_cns_ok() actually allows cns values up to 3.
Option 2: introduce another quirk flag.
Pros: Independent control, with no devices potentially affected by default.
Cons: More code changes.
I would also prefer to leave ioctl() behavior as is, allowing userspace
to issue nvme_admin_identify with any cns value.
I could try to prepare a patch if the idea isn't rejected outright.
--
With best regards,
Dmytro Bagrii
reply other threads:[~2026-08-12 18:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=7098b4f3-8ee9-4e80-a517-4204726308a0@gmail.com \
--to=dimich.dmb@gmail.com \
--cc=linux-nvme@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox