Re: [PATCH 1/3] cxl/mem: Quiet port walking warning

[Dan Williams <dan.j.williams@intel.com>]

Jonathan Cameron wrote:
> On Wed, 4 Jan 2023 10:36:13 +0100
> Robert Richter <rrichter@amd.com> wrote:
> 
> > On 03.01.23 13:07:18, Dan Williams wrote:
> > > Robert Richter wrote:  
> > > > On 16.12.22 17:33:32, Dan Williams wrote:  
> > 
> > > > > diff --git a/drivers/cxl/core/port.c b/drivers/cxl/core/port.c
> > > > > index 810e60cc331c..6296d2bc909a 100644
> > > > > --- a/drivers/cxl/core/port.c
> > > > > +++ b/drivers/cxl/core/port.c
> > > > > @@ -1400,8 +1400,8 @@ int devm_cxl_enumerate_ports(struct cxl_memdev *cxlmd)
> > > > >  
> > > > >           uport_dev = dport_dev->parent;
> > > > >           if (!uport_dev) {
> > > > > -                 dev_warn(dev, "at %s no parent for dport: %s\n",
> > > > > -                          dev_name(iter), dev_name(dport_dev));
> > > > > +                 dev_dbg(dev, "at %s no parent for dport: %s\n",
> > > > > +                         dev_name(iter), dev_name(dport_dev));
> > > > >                   return -ENXIO;  
> > > > 
> > > > Maybe we should also change the return code to the common -EAGAIN for
> > > > this case here too? It looks like it is just passed to
> > > > cxl_mem_probe(), so there are probably no side effects of this change.
> > > > The probe is triggered then again by the base driver.  
> > > 
> > > Good point, might as well explicitly return EPROBE_DEFER rather than let
> > > the driver core turn EAGAIN into EPROBE_DEFER. Tests seem to pass with
> > > that change as well.  
> > 
> > Yes, EPROBE_DEFER is the one used in the Deferred Probe
> > infrastructure.
> 
> If doing that, can we add a dev_err_probe() call so that the deferred probing
> infrastructure gets a nice error message for anyone wondering why this
> deferred.  That calls the device_set_deferred_probe_reason() in the
> -EPROBE_DEFER call and deals with dev_dbg print for this case for us.

Ah, sure that's better.