On Tuesday 02 May 2017 06:24 PM, Bin Liu wrote:
> 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 <abailon@xxxxxxxxxxxx>
>>> ---
>>> 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.
The kernel-doc comment for dma_request_chan() says it can return any
error pointer and not just -EPROBE_DEFER. So rather than depending on
the current implementation which might change couple of kernel versions
later, we should assume any error pointer can be returned.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
