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

[Pankaj Raghav]

jn Thu, Mar 09, 2023 at 11:43:33PM +0530, Rajat Khandelwal wrote:
> > > > > > 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?
> > > The issue is sporadic in nature, witnessed even during reboots with the device
> > > attached.
> > > Is such a scenario even possible (BAR not getting written by the hardware)?
> > It's not supposed to be possible, but your analysis checking the BAR register
> > with setpci seems pretty convincing that that is happening.

A bit more context on this issue FWIW:

Monish contacted me a while ago regarding this issue happening in
Samsung X5. I failed to reproduce this issue in an Intel 6th gen
(skylake) laptop. I tried hotplugging the device multiple times but the
device came up without any issue. That laptop used a JHL6540 Thunderbolt 3
Bridge. I get from your email that you started seeing this issue from Alderlake. 

To isolate if this is an issue with the device, I repeated the same
steps on an Apple Mac M1 but couldn't reproduce this error. 

Unfortunately this device is already EOL, so our Firmware team is unable
to help here.

--
Pankaj