Hi,
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes:
>> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
