Hi,
(I have added you to another thread which is where we'll be collecting
discussion about this, however ...)
Alan Stern writes:
> On Fri, 14 Oct 2016, Felipe Balbi wrote:
>
>> argh, we have nested spinlocks :-( Well, we shouldn't call
>> usb_ep_disable() with locks held AFAICR. So the followi
On Fri, 14 Oct 2016, Felipe Balbi wrote:
> argh, we have nested spinlocks :-( Well, we shouldn't call
> usb_ep_disable() with locks held AFAICR. So the following should be
> enough:
>
> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> index 919d7d1b611c..2e9359c58eb9
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
>>> I see what the problem is. Databook tells us we *must* set CMDIOC
>>> when
>>> issuing EndTransfer command and we should always wait for Command
>>> Complete IRQ. However, we took a shortcut and just delayed for
Hi Felipe,
On 14 October 2016 at 15:46, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> I see what the problem is. Databook tells us we *must* set CMDIOC
>> when
>> issuing EndTransfer command and we should always wait for Command
>> Complete IRQ. However,
Hi,
Baolin Wang writes:
> I see what the problem is. Databook tells us we *must* set CMDIOC when
> issuing EndTransfer command and we should always wait for Command
> Complete IRQ. However, we took a shortcut and just delayed for 100us
> after issuing End Transfer
Hi Felipe,
On 13 October 2016 at 21:34, Felipe Balbi wrote:
>
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
>> Baolin Wang writes:
>> I'm thinking this is a bug in configfs interface of Gadget API, not
>> dwc3. The only reason for this to happen would be if we get
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
> Baolin Wang writes:
> I'm thinking this is a bug in configfs interface of Gadget API, not
> dwc3. The only reason for this to happen would be if we get to
> ->udc_stop() with endpoints still enabled.
>
>>
Hi Felipe,
On 13 October 2016 at 19:23, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
Baolin Wang writes:
I'm thinking this is a bug in configfs interface of Gadget API, not
dwc3. The only reason for this to happen would be if we get to
->udc_stop() with en
Hi,
Baolin Wang writes:
>>> Baolin Wang writes:
>>> I'm thinking this is a bug in configfs interface of Gadget API, not
>>> dwc3. The only reason for this to happen would be if we get to
>>> ->udc_stop() with endpoints still enabled.
>>>
>>> Can you check if that's the case?
On 13 October 2016 at 18:56, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Balbi writes:
>> Hi,
>>
>> Baolin Wang writes:
>> I'm thinking this is a bug in configfs interface of Gadget API, not
>> dwc3. The only reason for this to happen would be if we get to
>> ->udc_stop() with endpoints s
Hi,
Felipe Balbi writes:
> Hi,
>
> Baolin Wang writes:
> I'm thinking this is a bug in configfs interface of Gadget API, not
> dwc3. The only reason for this to happen would be if we get to
> ->udc_stop() with endpoints still enabled.
>
> Can you check if that's the case? i.
Hi,
Baolin Wang writes:
I'm thinking this is a bug in configfs interface of Gadget API, not
dwc3. The only reason for this to happen would be if we get to
->udc_stop() with endpoints still enabled.
Can you check if that's the case? i.e. can you check if any endpoints
>>>
Hi,
On 13 October 2016 at 15:51, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Hi,
>>
>> On 13 October 2016 at 15:02, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
@@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
dwc->gadget_driver
Hi,
Baolin Wang writes:
> Hi,
>
> On 13 October 2016 at 15:02, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang writes:
>>> @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
>>> dwc->gadget_driver = NULL;
>>> spin_unlock_irqrestore(&dwc->lock, flags);
>>>
Hi,
On 13 October 2016 at 15:02, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
>> dwc->gadget_driver = NULL;
>> spin_unlock_irqrestore(&dwc->lock, flags);
>>
>> + /*
>> + * Since the xHCI
Hi,
Baolin Wang writes:
> @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
> dwc->gadget_driver = NULL;
> spin_unlock_irqrestore(&dwc->lock, flags);
>
> + /*
> + * Since the xHCI will share the same interrupt with gadget, thus when
> + * f
When we change the USB function with configfs frequently, sometimes it will
hang the system to crash. The reason is the gadget driver can not hanle the
end transfer complete event after free the gadget irq (since the xHCI will
share the same interrupt number with gadget, thus when free the gadget i
17 matches
Mail list logo
