[PATCH] nvme-pci: Remove O2 Queue Depth quirk

[Robert Beckett]

 ---- On Tue, 29 Oct 2024 18:58:40 +0000  Gwendal Grignou  wrote --- 
 > On Tue, Oct 29, 2024 at 12:41 AM Christoph Hellwig hch at lst.de> wrote:
 > >
 > > On Mon, Oct 28, 2024 at 07:42:36PM -0700, Gwendal Grignou wrote:
 > > > PCI_DEVICE(0x1217, 0x8760) (O2 Micro, Inc. FORESEE E2M2 NVMe SSD)
 > > > is a NMVe to eMMC bridge, that can be used with different eMMC
 > > > memory devices.
 > >
 > > Holy f**k, what an awful idea..
 > >
 > > > The NVMe device name contains the eMMC device name, for instance:
 > > > `BAYHUB SanDisk-DA4128-91904055-128GB`
 > > >
 > > > The bridge is known to work with many eMMC devices, we need to limit
 > > > the queue depth once we know which eMMC device is behind the bridge.
 > >
 > > Please work with Tobert to quirk based on the identify data for "his"
 > > device to keep it quirked instead of regressing it.
 > 
 > The issue is we would need to base the quirk on the model name
 > (subsys->model) that is not available in `nvme_id_table`. Beside,
 > `q_depth` is set in `nvme_pci_enable`, called at probe time before
 > calling `nvme_init_ctrl_finish` that will indirectly populate
 > `subsys`.
 > 
 > Bob, to address the data corruption problem from user space, adding a
 > udev rule to set `queue/nr_requests` to 1 when `device/model` matches
 > the device used in the Steam Deck would most likely be too late in the
 > boot process, wouldn't it?

I've never seen the corruption outside of severe stress testing.
In the field, people reported it during and after os image updates (more stress testing).
However, as this concerns data integrity, it seems risky to me to rely on a fix
after bootup.

 > 
 > Gwendal.
 >