Re: [PATCH] usb: gadget: bcm63xx UDC driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 21, 2012 at 2:34 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>> But some requests are handled entirely in hardware, including the status phase:
>>
>> SET_ADDRESS
>> SET_CONFIGURATION
>> SET_INTERFACE
>> SET_FEATURE
>> CLEAR_FEATURE
>> GET_FEATURE
>
> I assume the features in question are endpoint-halts and
> remote-wakeup-enable.  It's hard to think of any other features that
> could be handled in hardware.

Yes, endpoint-halt is what I've seen in my testing.  Not sure on remote wakeup.

> (BTW, what happens if one of these requests arrives before a previous
> control IRQ has been acknowledged by the CPU?  Does the old data in the
> registers get overwritten and lost, or does the UDC hold off on
> carrying out the new request?)

There are separate IRQ bits for SET_CONFIGURATION, SET_INTERFACE, and
"generic setup packet."  The driver processes them in order.

Consecutive SET_INTERFACE requests could potentially get "lost," but
the controller will remember the value set in the most recent request.

> I can't imagine how any gadget driver could hope to handle a mess like
> this.  For instance, suppose a Set-Config operation fails.  There's no
> way for the driver to tell the host, because the hardware has already
> said that the operation succeeded.

Right - but looking on the bright side:

1) At least in my experience, most hosts will send a valid
SET_CONFIGURATION request so the error path won't be needed.  If it is
needed, it won't do anything really bad like hanging the interface.

2) All of this complexity is hidden inside one UDC driver, and did not
require hacking up the rest of the gadget layer.

3) After many months of struggling to get things right, the driver can
finally pass "testusb".

> Anyway, you don't need to workqueue to manage this -- just a queue of
> pending control requests.  You should be able to do everything in
> interrupt context, especially since you will ignore any responses the
> driver submits on ep0 for these transfers.

Well, in the example from my last email, I don't get any new
interrupts after SET_INTERFACE.  So after the gadget driver queues the
response to the spoofed SET_CONFIGURATION packet, I need to schedule a
workqueue (or tasklet, or timer, or something) to run the next setup
callback in a context where the gadget driver isn't holding any
spinlocks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux