Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
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