Re: [BUG] Root port fails to match with port driver on non-RCH topology

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Thu, 15 Jun 2023 18:43:59 -0400
Gregory Price <gregory.price@memverge.com> wrote:

> On Thu, Jun 15, 2023 at 02:51:13PM -0400, Gregory Price wrote:
> > On Thu, Jun 15, 2023 at 02:46:13PM -0400, Gregory Price wrote:  
> > > On Thu, Jun 15, 2023 at 12:16:05PM -0400, Gregory Price wrote:
> > > follow up with more context, there is a subsequent error on
> > > cxl_port_probe which causes dev->driver to remain NULL.
> > > 
> > > 
> > > [   15.561313] cxl_mem mem0: CXL port topology root0 not enabled
> > > [   15.561315] cxl_mem mem0: call_driver_probe failed  
> > 
> > wrong prints here, this should have read:
> > 
> > [   15.549316] cxl root0: driver set to cxl_port
> > [   15.549732] cxl_port root0: call_driver_probe failed
> > 
> > I confirmed that call_driver_probe sinks down to a call to
> > cxl_port_probe and that is failing on cxl_port_probe(root0).
> > 
> > Rest of the commentary below is accurate.
> >   
> 
> 
> so cxl_switch_port_probe fails on this stack:
> 
> - cxl_switch_port_probe
>   - devm_cxl_port_enumerate_dports
>     - cxl_port_to_pci_bus
> 
> int devm_cxl_port_enumerate_dports(struct cxl_port *port)
> {
>         struct pci_bus *bus = cxl_port_to_pci_bus(port);
>         struct cxl_walk_context ctx;
>         int type;
> 
>         if (!bus)
>                 return -ENXIO;
> ...
> }
> 
> struct pci_bus *cxl_port_to_pci_bus(struct cxl_port *port)
> {
>     /* There is no pci_bus associated with a CXL platform-root port */
>     if (is_cxl_root(port))
>         return NULL;
> ...
> }
> 
> 
> I presume then that for the root port, we should just return 0 to note
> success?  The rest of the devices should register themselves correctly
> with the root as they're iterated over - i think?
> 
> What I can't figure out is why this doesn't happen on QEMU, which also
> presents a similar topology.
> 
> Still not sure what is correct vs incorrect here, will need to dig
> around in the spec and system settings unless someone has an idea.

Interestingly on QEMU we never get near the path that's failing on root0
as no driver is associated with that particular device.  There are plenty of
child devices with drivers though - just not the top level one.
I wonder if a rescan or something similar is causing the probe on your
system but not qemu?

Dan, should we be seeing a driver binding to root0 or not?

Jonathan



 

> 
> ~Gregory