[Top] [All Lists]

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

Subject: Re: [PATCH] usb: gadget: bcm63xx UDC driver
From: Kevin Cernekee <>
Date: Tue, 21 Aug 2012 08:20:43 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xsFcsyq6UYpLfeIqmBZsDj4SxSvK4QL5aRNPpkQvz6o=; b=d4Xg7b6L1OLaarsJpIpFzbKnIIzgq6ElQlOAdcjaL0PlCUurCWedRS18RKWUFoYtjR D53PTGC3pwKj2GLAlp3BfjH6MjQ1FFCj7/HoEBWxo9agX9tPtw98AhW0lyDCIIjn/zwD tBPjP3BrHc6h86/kRNkPMAlruC50H/sRGQTkbyR6Ionf0uCY+L8nLdNMA2AxDWKWkoIf 80AjjVV573aP+0/bQblH8KtwiLIcK9tZpanKpsRo5LaPonBdgmoCJ90GlJYCmDFdhZ0y vQP+OzIfY3AlE55RWBO6oWGXRJzxr8CQbF+6Ck+QLfDI20x0gCHtiqYQtFmza0CIlxBg MCmw==
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: <>
References: <97cb21b8063a02a9664baf8b749ae200@localhost> <> <> <>
On Tue, Aug 21, 2012 at 5:04 AM, Felipe Balbi <> wrote:
> On Mon, Aug 20, 2012 at 08:48:11PM -0700, Kevin Cernekee wrote:
>> On Mon, Aug 20, 2012 at 12:40 AM, Felipe Balbi <> wrote:
>> > no workqueues, please either handle the IRQ here or use threaded_irqs.
>> >
>> > again, no workqueues.
>> Felipe,
>> I am seeing all sorts of deadlocks now, after removing the workqueue
>> (patch V2).  Some have easy fixes, but for others it is not as
>> obvious.  The code was much simpler when I could just trigger a
>> deferred worker function.
>> Workqueues are used in at91_udc, lpc32xx_udc, mv_udc_core, and
>> pch_udc.  Could you please clarify why it is not OK to use one in
>> bcm63xx_udc?
> Because threaded_irqs were added in order to drop such workqueues.
> threaded_irqs also have the highest priority possible (only lower than
> hardirq handlers), so you'll get scheduled much sooner.
> Could it be that most of your deadlocks is because you're not setting

The deadlocks involve ep0 processing that is triggered through
bcm63xx_udc_queue().  e.g. gadget driver queues a new request, it's a
reply to a spoofed SET_CONFIGURATION / SET_INTERFACE transaction, and
the UDC driver calls the completion immediately.

So, not all of the ep0 work is being done in response to an IRQ from
the controller HW, and I think that is where this driver diverges from
most of the others.

Would it be OK to use a workqueue, or maybe a tasklet, given these


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