The wrong usage of NVME_QUIRK_IGNORE_DEV_SUBNQN

The wrong usage of NVME_QUIRK_IGNORE_DEV_SUBNQN

[AlanCui4080]

Hi Busch,

Sorry for my bad, but the prior patch which is merged into mainline may
be a mistake:
nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808
(7f991e3f9b8f044640bcb5fa8570350a68932843 at mainline).

At first, I searched around the web, many many customer grade devices breaks
compliance with specification, and some answers tell to add quirk for the device
https://bbs.archlinux.org/viewtopic.php?id=296004
> If you do not want to see the warning you need to ask the kernel developers to add
> NVME_QUIRK_IGNORE_DEV_SUBNQN for whatever the device is that does not support SUBNQN.

https://forum.corsair.com/forums/topic/166499-mp600-1tb-linux-firmware-113-nvme-protocol-quirk/
> This issue with invalid SUBNQN field is a known issue in a number of NVMe units.
> If you look at the kernel code you will see that it has a dedicated quirk for it.
> See NVME_QUIRK_IGNORE_DEV_SUBNQN in ...

Then I did a search on "SUBNQN" on mailling list, then a patch:
[PATCH] nvme: Add quirks for Lexar 256GB SSD
(6e6a6828c517fb6819479bf5187df5f39084eb9e at mainline)
(https://lists.infradead.org/pipermail/linux-nvme/2021-February/023121.html)
said: 
> ... and add NVME_QUIRK_IGNORE_DEV_SUBNQN to avoid a warning.

I think the way to resolve the warning is quirk for it, so did i.


But, the NVMe specification said:
> Support for this field (SUBNQN) is mandatory if the controller supports
> revision 1.2.1 or later.

And the code in kernel is
```
if (ctrl->vs >= NVME_VS(1, 2, 1))
	dev_warn(ctrl->device, "missing or invalid SUBNQN field.\n");
```

So the warning "nvme nvme0: missing or invalid SUBNQN field." is appropriate and since
the device will not report itself supports SUBNQN at all, it will not cause any problem
and it do break the NVMe compliance, in order to that, the NVME_QUIRK_IGNORE_DEV_SUBNQN
in my patch for "Samsung PM981/983/970 EVO Plus" and in the Terjans' patch for
"Lexar 256 GB SSD" should be reverted, however, leave them there should not cause any problem.

I can confirm the "Samsung PM981/983/970 EVO Plus" can work well without the
prior patch, I do believe the "Lexar 256 GB SSD" can also, because Terjan said
the quirk on SUBNQN is only for suppressing the "missing or invalid SUBNQN field".
This mail is copied to Terjan for fact checking.

Since the missing SUBNQN is a known issue in a massive number of NVMe units.
I'd suggest add a chapter for it in Documentation/nvme/feature-and-quirk-policy.rst to
tell users the missing SUBNQN is a firmware bug of drives, so warning for the device
is appropriate, and it will affect nothing like performance etc.

I apologize for my recklessness and lack of due diligence again.

Alan.

Re: The wrong usage of NVME_QUIRK_IGNORE_DEV_SUBNQN

[Keith Busch]

On Fri, May 08, 2026 at 02:20:30AM +0800, AlanCui4080 wrote:
> Sorry for my bad, but the prior patch which is merged into mainline may
> be a mistake:
> nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808
> (7f991e3f9b8f044640bcb5fa8570350a68932843 at mainline).

Okay, please send a revert. The number of devices that got such
fundamental things wrong is truly astounding, so I generally just take
such reports and patches as a reaction to a real observation.

[PATCH] Revert "nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808"

[AlanCui4080]

This reverts commit 7f991e3f9b8f044640bcb5fa8570350a68932843 ("nvme: add quirk
NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808")

The incorrect implementations of SUBNQN is a known issue in a massive number of
NVMe units.  However, the warning "nvme nvmex: missing or invalid SUBNQN field."
is usually appropriate and will not affect performance or behavior etc.  That is
because the support for SUBNQN is mandatory if the controller supports NVMe
revision 1.2.1 or greater, and it reported itself without a SUBNQN field which
breaks compliance with the specification. It should be not quirked by the Linux
Kernel.

Signed-off-by: Alan Cui <me@alancui.cc>
---
 drivers/nvme/host/pci.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 9fd04cd7c5cb..2850fd55894b 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -4107,8 +4107,6 @@ static const struct pci_device_id nvme_id_table[] = {
 		.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
 	{ PCI_DEVICE(0x1c5f, 0x0555),	/* Memblaze Pblaze5 adapter */
 		.driver_data = NVME_QUIRK_NO_NS_DESC_LIST, },
-	{ PCI_DEVICE(0x144d, 0xa808),	/* Samsung PM981/983 */
-		.driver_data = NVME_QUIRK_IGNORE_DEV_SUBNQN, },
 	{ PCI_DEVICE(0x144d, 0xa821),   /* Samsung PM1725 */
 		.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
 	{ PCI_DEVICE(0x144d, 0xa822),   /* Samsung PM1725a */
-- 
2.54.0

Re: The wrong usage of NVME_QUIRK_IGNORE_DEV_SUBNQN

[AlanCui4080]

Hi Busch,

On Friday, 8 May 2026 16:03，you wrote：

> Okay, please send a revert. The number of devices that got such
> fundamental things wrong is truly astounding, so I generally just take
> such reports and patches as a reaction to a real observation.

The patch contains a revert has been sent to mailling list.

I've only recently started using Linux desktop on a physical machine
and am trying to contribute. Sorry for my recklessness.

A patch attached for reference. If the Linux kernel explicitly
states in documents that it won't perform a quirk in this situation,
perhaps I can go to those BBS forums to correct their statements. And
this may help to avoid wrong usage of quirks like My and Terjan's patch.

Alan.

---
diff --git a/Documentation/nvme/feature-and-quirk-policy.rst b/Documentation/nvme/feature-and-quirk-policy.rst
index e21966bf20a8..9d9e791da692 100644
--- a/Documentation/nvme/feature-and-quirk-policy.rst
+++ b/Documentation/nvme/feature-and-quirk-policy.rst
@@ -75,3 +75,18 @@ Quirks will not be added to the Linux kernel for hardware that isn't available
 on the mass market.  Hardware that fails qualification for enterprise Linux
 distributions, ChromeOS, Android or other consumers of the Linux kernel
 should be fixed before it is shipped instead of relying on Linux quirks.
+
+NVME_QUIRK_IGNORE_DEV_SUBNQN
+-------------------------
+
+The incorrect implementations of SUBNQN is a known issue in a massive number of
+NVMe units.  However, the warning "nvme nvmex: missing or invalid SUBNQN field."
+is usually appropriate and will not affect performance or behavior etc.  That is
+because the support for SUBNQN is mandatory if the controller supports NVMe
+revision 1.2.1 or greater, and it reported itself without a SUBNQN field which
+breaks compliance with the specification. This should be not quirked by the Linux
+Kernel.
+
+The intent of NVME_QUIRK_IGNORE_DEV_SUBNQN is to solve the NQN confliction caused
+by defective firmware that provides a non-globally-unique NQN.  When multiple
+such devices are installed in a system, only one will be recognized and enabled.

Re: [PATCH] Revert "nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808"

[Keith Busch]

On Fri, May 08, 2026 at 05:59:12PM +0800, AlanCui4080 wrote:
> This reverts commit 7f991e3f9b8f044640bcb5fa8570350a68932843 ("nvme: add quirk
> NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808")

Applied to nvme-7.1, thanks.