On Tue, May 02, 2017 at 11:21:54AM +0530, Sekhar Nori wrote:
> Hi Alexandre,
>
> On Friday 28 April 2017 09:34 PM, Alexandre Bailon wrote:
> > If dma_request_slave_channel() failed to return a channel,
> > then the driver will print an error and request to defer probe.
> > Update the error message to explain we are defrering probe.
> >
> > Signed-off-by: Alexandre Bailon <abai...@baylibre.com>
> > ---
> > drivers/usb/musb/musb_cppi41.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> > index e7c8b1b..e6b9161 100644
> > --- a/drivers/usb/musb/musb_cppi41.c
> > +++ b/drivers/usb/musb/musb_cppi41.c
> > @@ -676,6 +676,7 @@ static int cppi41_dma_controller_start(struct
> > cppi41_dma_controller *controller)
> > dc = dma_request_slave_channel(dev->parent, str);
> > if (!dc) {
> > dev_err(dev, "Failed to request %s.\n", str);
> > + dev_info(dev, "Deferring probe.\n");
> > ret = -EPROBE_DEFER;
> > goto err;
> > }
>
> It looks like you will be better-off using dma_request_chan() instead so
> you can get an error pointer back and not return -EPROBE_DEFER
> irrespective of the actual error.
I thought about it, but -EPROBE_DEFER is the only error code returned in
dma_request_chan(), so nothing else to distinguish here, improving the
dev_err message would be an simpler fix.
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
