On 07/06/16 16:09, Felipe Balbi wrote:
> 
> Hi,
> 
> (guys, please make sure to break lines at 80-columns)
> 
> Roger Quadros <rogerq@ti.com> writes:
>>>>>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
>>>>>>    int dwc3_gadget_init(struct dwc3 *dwc)
>>>>>>    {
>>>>>>        int                    ret;
>>>>>> +    struct resource *res;
>>>>>> +    struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>>>>>> +
>>>>>> +    dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>>>>>> +    if (dwc->irq_gadget <= 0) {
>>>>>
>>>>> Is it expected to get -EPROBE_DEFER here?
>>>>
>>>> Probably not as we don't have any chance of deferring probe here. We've already
>>>> probed successfully and are just turning on the gadget mode here.
>>>
>>> In general, you can't say that you've been probed successfully if not
>>> all resources are ready, and irq is a resource :) It's expected that
>>> all resources will be requested in probe, but here you are trying to
>>> get resource outside of probe. As result, it will be perfectly
>>> possible to get -EPROBE_DEFER here if on some HW GPIO IRQ will be
>>> used as peripheral, or host or otg irq (for example), because GPIO
>>> IRQ controller might not be ready at the moment when IRQ resource is
>>> requested.
>>
>> I agree with you.
>>
>> Felipe, are you ok with moving the IRQ resource obtaining code to probe?
> 
> You mean that probe() would setup all gadget_irq, otg_irq and host_irq
> while the other pieces (otg.c, gadget.c and host.c) only use it?
> 
> yeah, that should be fine. No problems.
> 
OK great. I'll fix this up then. Thanks.

cheers,
-roger