[Top] [All Lists]

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

To: Kevin Cernekee <>
Subject: Re: [PATCH] usb: gadget: bcm63xx UDC driver
From: Alan Stern <>
Date: Tue, 21 Aug 2012 16:34:33 -0400 (EDT)
Cc:, <>, <>, <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
On Tue, 21 Aug 2012, Kevin Cernekee wrote:

> On Tue, Aug 21, 2012 at 11:08 AM, Felipe Balbi <> wrote:
> > Then stick to a workqueue... but could you let me know why exactly you
> > have to fake SET_CONFIGURATION/SET_INTERFACE requests ? Is this a
> > silicon bug or a silicon feature ? That's quite weird to me.
> It is a silicon feature: the core will intercept SET_CONFIGURATION /
> SET_INTERFACE requests, store wValue/wIndex in the appropriate
> USBD_STATUS_REG field (cfg/intf/altintf), send an acknowledgement to
> the host, and raise a control interrupt.

Your explanation is not clear.  The operations you listed are exactly
what any UDC should do when it receives any control request: It should
store the bRequestType, bRequest, wValue, wIndex, and wLength values in
appropriate registers, send an ACK back to the host, and generate an
IRQ.  What's special about Set-Config and Set-Interface?

The only thing to watch out for is the status stage of the control
transfer.  The hardware must not complete the status stage for you;
that would be a violation of the USB-2 spec.  (The only exception is
for Set-Address requests.)

> I haven't found it to be terribly helpful, but I don't know of a way
> to turn it off.

Why would you want to turn this off?  Isn't is exactly what you want to 
have happen?  And why do you need a workqueue to handle the request?

Alan Stern

<Prev in Thread] Current Thread [Next in Thread>