The wrong usage of NVME_QUIRK_IGNORE_DEV_SUBNQN

[AlanCui4080 <me@alancui.cc>]

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.