Re: [PATCH v4 04/27] cxl: Establish media readiness in cxl_mem_probe()
Alex Williamson <[email protected]>
| Newsgroups | org.kernel.vger.kvm,org.kernel.vger.linux-cxl,org.kernel.vger.linux-doc,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 13 Aug 2026 15:06:08 +0530 <[email protected]> wrote: > From: Manish Honap <[email protected]> > > media_ready was only ever set by cxl_pci, in advance of registering a > memdev and with CXL Memory Device register assumptions. A consumer that > creates a memdev without cxl_pci, such as a mailbox-less Type-2 > accelerator brought up through devm_cxl_probe_mem(), therefore handed > cxl_mem a device with media_ready still false, and cxl_mem_probe() > rejected it with -EBUSY. __devm_cxl_add_memdev() turns that into -ENXIO > back to the caller and the bind fails. > > Move the readiness wait into cxl_mem_probe() so every memdev consumer > gets a ready resource regardless of how the memdev was created. When > media_ready is not already set, wait on the device's DVSEC > Mem_Info_Valid and Mem_Active bits and mark it ready. cxl_pci keeps > setting media_ready before it registers its memdev, so that path skips > the wait. > > The CXL Memory Device register group is optional and many Type-2 devices > do not implement it, so cxl_await_media_ready() must not read the Memdev > Status register unless the group is mapped. Reading regs.memdev on a > device that lacks it would fault. Gate that read on regs.memdev; the > DVSEC bits already prove readiness for such devices. > > Signed-off-by: Manish Honap <[email protected]> > --- > drivers/cxl/core/pci.c | 15 +++++++++++---- > drivers/cxl/mem.c | 9 +++++++-- > 2 files changed, 18 insertions(+), 6 deletions(-) > > diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c > index 08d4c955137d..9b372d5a1aa4 100644 > --- a/drivers/cxl/core/pci.c > +++ b/drivers/cxl/core/pci.c > @@ -151,7 +151,6 @@ int cxl_await_media_ready(struct cxl_dev_state *cxlds) > struct pci_dev *pdev = to_pci_dev(cxlds->dev); > int d = cxlds->cxl_dvsec; > int rc, i, hdm_count; > - u64 md_status; > u16 cap; > > rc = pci_read_config_word(pdev, > @@ -172,9 +171,17 @@ int cxl_await_media_ready(struct cxl_dev_state *cxlds) > return rc; > } > > - md_status = readq(cxlds->regs.memdev + CXLMDEV_STATUS_OFFSET); > - if (!CXLMDEV_READY(md_status)) > - return -EIO; > + /* > + * It is possible some Type-2 devices (CXL_DEVTYPE_DEVMEM) do not > + * implement regs.memdev; only consult the Memdev Status register when > + * the group is actually present. > + */ > + if (cxlds->regs.memdev) { > + u64 md_status = readq(cxlds->regs.memdev + CXLMDEV_STATUS_OFFSET); > + > + if (!CXLMDEV_READY(md_status)) > + return -EIO; > + } > > return 0; > } This looks like it should be two separate patches. The change below depends on the above, but the above change stands on its own. > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c > index 798e5c369cfc..9c6e99b9124c 100644 > --- a/drivers/cxl/mem.c > +++ b/drivers/cxl/mem.c > @@ -105,8 +105,13 @@ static int cxl_mem_probe(struct device *dev) > struct dentry *dentry; > int rc; > > - if (!cxlds->media_ready) > - return -EBUSY; > + if (!cxlds->media_ready) { > + rc = cxl_await_media_ready(cxlds); > + if (rc) > + return rc; > + cxlds->media_ready = true; > + dev_dbg(dev, "CXL media ready\n"); > + } > > /* > * Someone is trying to reattach this device after it lost its port LLM review is noting a plausible behavioral change here; if there is an actual media issue, it seems it's flagged in cxl_pci_probe() by leaving cxlds.media_ready false. That path can then go on to find memory devices, add a CXL_DEVICE_MEMORY_EXPANDER, and via the .probe callback reach cxl_mem_probe() and wait another timeout delay here for the same media issue. Should the mailbox-less path test and set media_ready before adding the CXL_DEVICE_MEMORY_EXPANDER and getting to this .probe callback, making it consistently tested upstream of this function? Thanks, Alex