Hi,
Alan Stern writes:
>> Alan Stern writes:
>> >> So I am not sure how the Gadget driver can figure out that it needs to
>> >> usb_ep_queue() another request for status stage when handling the
>> >> no-data control?
>> >
>> > Gadget
Hi,
Baolin Wang writes:
>>> > Baolin Wang writes:
>>> (One possible approach would be to have the setup routine return
>>> different values for explicit and implicit status stages -- for
>>> example, return 1 if it wants to submit
Hi,
On 28 February 2017 at 06:11, Alan Stern wrote:
> On Tue, 21 Feb 2017, Baolin Wang wrote:
>
>> On 17 February 2017 at 16:04, Felipe Balbi wrote:
>> >
>> > Hi,
>> >
>> > Baolin Wang writes:
>> (One possible approach
On Tue, 28 Feb 2017, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
> >> So I am not sure how the Gadget driver can figure out that it needs to
> >> usb_ep_queue() another request for status stage when handling the
> >> no-data control?
> >
> > Gadget drivers
Hi,
Alan Stern writes:
>> So I am not sure how the Gadget driver can figure out that it needs to
>> usb_ep_queue() another request for status stage when handling the
>> no-data control?
>
> Gadget drivers already queue status-stage requests for no-data
> control-OUT
On Tue, 21 Feb 2017, Baolin Wang wrote:
> On 17 February 2017 at 16:04, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Baolin Wang writes:
> (One possible approach would be to have the setup routine return
> different values for explicit and implicit
On 17 February 2017 at 16:04, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
(One possible approach would be to have the setup routine return
different values for explicit and implicit status stages -- for
example, return 1 if it
On 17 February 2017 at 16:04, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
(One possible approach would be to have the setup routine return
different values for explicit and implicit status stages -- for
example, return 1 if it
Hi,
Baolin Wang writes:
>>> (One possible approach would be to have the setup routine return
>>> different values for explicit and implicit status stages -- for
>>> example, return 1 if it wants to submit an explicit status request.
>>> That wouldn't be very different
On 23 January 2017 at 19:57, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
>> On Mon, 16 Jan 2017, Felipe Balbi wrote:
>>
>>> > The gadget driver never calls usb_ep_queue in order to receive the next
>>> > SETUP packet; the UDC driver takes care
Hi,
Alan Stern writes:
> On Mon, 16 Jan 2017, Felipe Balbi wrote:
>
>> > The gadget driver never calls usb_ep_queue in order to receive the next
>> > SETUP packet; the UDC driver takes care of SETUP handling
>> > automatically.
>>
>> yeah, that's another thing I'd
On Mon, 16 Jan 2017, Felipe Balbi wrote:
> > The gadget driver never calls usb_ep_queue in order to receive the next
> > SETUP packet; the UDC driver takes care of SETUP handling
> > automatically.
>
> yeah, that's another thing I'd like to change. Currently, we have no
> means to either try to
Hi,
On 17 January 2017 at 18:39, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
When handing the SETUP packet by composite_setup(), we will release the
dwc->lock. If we get the
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
>>> When handing the SETUP packet by composite_setup(), we will release the
>>> dwc->lock. If we get the 'USB_GADGET_DELAYED_STATUS' result from setup
>>> function, which means we
Hi,
On 16 January 2017 at 20:06, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Hi,
>>
>> On 16 January 2017 at 19:29, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
Hi,
On
Hi,
Alan Stern writes:
> On Mon, 16 Jan 2017, Felipe Balbi wrote:
>
>> Another point here is that the really robust way of fixing this is to
>> get rid of USB_GADGET_DELAYED_STATUS altogether and just make sure
>> gadget drivers know how to queue
On Mon, 16 Jan 2017, Felipe Balbi wrote:
> Another point here is that the really robust way of fixing this is to
> get rid of USB_GADGET_DELAYED_STATUS altogether and just make sure
> gadget drivers know how to queue requests for all three phases of a
> Control Transfer.
>
Hi,
Baolin Wang writes:
> Hi,
>
> On 16 January 2017 at 19:29, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang writes:
>>> Hi,
>>>
>>> On 16 January 2017 at 18:56, Felipe Balbi wrote:
Hi,
Hi,
On 16 January 2017 at 19:29, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Hi,
>>
>> On 16 January 2017 at 18:56, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
When handing the
Hi,
Baolin Wang writes:
> Hi,
>
> On 16 January 2017 at 18:56, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang writes:
>>> When handing the SETUP packet by composite_setup(), we will release the
>>> dwc->lock. If we get the
Hi,
On 16 January 2017 at 18:56, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> When handing the SETUP packet by composite_setup(), we will release the
>> dwc->lock. If we get the 'USB_GADGET_DELAYED_STATUS' result from setup
>> function, which
Hi,
Baolin Wang writes:
> When handing the SETUP packet by composite_setup(), we will release the
> dwc->lock. If we get the 'USB_GADGET_DELAYED_STATUS' result from setup
> function, which means we need to delay handling the STATUS phase.
this sentence needs a little
When handing the SETUP packet by composite_setup(), we will release the
dwc->lock. If we get the 'USB_GADGET_DELAYED_STATUS' result from setup
function, which means we need to delay handling the STATUS phase.
But during the lock release period, maybe the request for handling delay
STATUS phase
23 matches
Mail list logo