[BUG] nvme-pci: NVMe probe fails with ENODEV

[Keith Busch]

On Thu, Mar 09, 2023 at 04:12:18PM +0100, Christoph Hellwig wrote:
> On Thu, Mar 09, 2023 at 07:31:07PM +0530, Rajat Khandelwal wrote:
> > Hi,
> > I am seeking some help regarding an issue I encounter sporadically
> > with Samsung Portable TBT SSD X5.
> >
> > Right from the thunderbolt discovery to the PCIe enumeration, everything
> > is fine, until 'NVME_REG_CSTS' is tried to be read in 'nvme_reset_work'.
> > Precisely, 'readl(dev->bar + NVME_REG_CSTS)' fails.
> >
> > I handle type-C, thunderbolt and USB4 on Chrome platforms, and currently
> > we are working on Intel Raptorlake systems.
> > This issue has been witnessed from ADL time-frame and now is seen
> > on RPL as well. I would really like to get to the bottom of the problem
> > and close the issue.
> >
> > I have tried 5.10 and 6.1.15 kernels.
> 
> So we have a quirk for a device called Samsung X5 in core.c, which is a
> bit of an unusual match.  Can you check that it gets applied for the
> device that you are testing?
> 
> Also if it gets applied, can you test this patch?

That won't help here. The driver should be bailing on the device
nvme_pci_enable() before we do the ready check:

static int nvme_pci_enable(struct nvme_dev *dev)
{
...
        if (readl(dev->bar + NVME_REG_CSTS) == -1) {
                result = -ENODEV;
                goto disable;
        }

It sounds like the bridge has a valid memory window, and the kernel assigned it
to the device, but for some reason the device didn't apply it to its BAR. Maybe
the device just doesn't support hotplug?