Hi, Alan Stern <[email protected]> writes: >> Alan Stern <[email protected]> writes: >> > There's a similar race at the hardware level. What happens if the >> > controller receives a new SETUP packet and concurrently the driver is >> > setting up the controller registers for a response to an earlier >> > SETUP? I don't know how real controllers handle this. >> >> That's HW implementation detail. DWC3, for instance, will ignore the >> TRBs and return me the status "setup packet pending". Then I just start >> a new SETUP TRB. > > You mean the UDC hardware sets a "setup pending" flag in some register, > and then ignores any attempts to do anything with ep0 until the driver > clears this flag?
Yes, except that the "flag" is a status on the TRB itself (TRB is dwc3's
DMA transfer descriptor).
>> > You mean, should we allow function drivers to queue the data-stage
>> > request after the setup handler has returned? I don't see any reason
>>
>> that's already done:
>>
>> static void dwc3_ep0_xfer_complete(struct dwc3 *dwc,
>> const struct dwc3_event_depevt *event)
>> {
>> struct dwc3_ep *dep = dwc->eps[event->endpoint_number];
>>
>> dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
>> dep->resource_index = 0;
>> dwc->setup_packet_pending = false;
>>
>> switch (dwc->ep0state) {
>> case EP0_SETUP_PHASE:
>> dwc3_ep0_inspect_setup(dwc, event);
>> break;
>> [...]
>> }
>
> ...
>
> You mean, it's already done in DWC3. What about other UDC drivers?
if they're not implementing this possibility, then that's a bug on
those UDC drivers :)
>> > why not. After all, some drivers may require this. Likewise for the
>> > data stage of a control-IN.
>> >
>> > Another thing we should do is give function drivers a way to send a
>> > STALL response for the status stage. Currently there's no way to do
>> > it, if a data stage is present.
>>
>> Status stage can only be stalled if host tries to move data on the wrong
>> direction.
>
> The USB-2 spec disagrees. See Table 8-7 in section 8.5.3.1 and the
> following paragraphs. (Although, I can't see why a function would ever
> fail to complete the command sequence for a control-IN transfer after
> the data had already been sent.)
I can't see how we could ever STALL after returning the data requested
by the host. Seems like that wasn't well thought out.
--
balbi
signature.asc
Description: PGP signature
