All of lore.kernel.org
 help / color / mirror / Atom feed
From: david-b@pacbell.net (David Brownell)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG] pxa27x_udc: possible recursive locking detected in pxa_ep_queue
Date: Sun, 6 Dec 2009 12:23:00 -0800	[thread overview]
Message-ID: <200912061223.00528.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0912061458540.7903-100000@netrider.rowland.org>

On Sunday 06 December 2009, Alan Stern wrote:
> That's what other device controller drivers do. ?There's no choice. ?
> (Except that I'm not sure they have individual locks for endpoints -- 
> just one single big spinlock.)

Right; such fine grain locking tends to be more hassle than it's
worth.  ISTR studies from a while back showing locks need to be
quite heavily contended before splitting them is worth much.  Any
per-controller lock for a UDC is unlikely to see much contention.


> In fact, host controller drivers do the analogous thing. ?When they
> give back completed URBs, they release their private spinlocks.

For *exactly* the same reason.  Upper level driver code shouldn't
need to worry about whether it's re-entering some random bit of
lower level code.  As a rule, it can't know about that code.

  reply	other threads:[~2009-12-06 20:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-05 10:57 [BUG] pxa27x_udc: possible recursive locking detected in pxa_ep_queue Antonio Ospite
2009-12-06 18:34 ` Robert Jarzmik
2009-12-06 20:01   ` Alan Stern
2009-12-06 20:23     ` David Brownell [this message]
2009-12-10 17:58       ` Robert Jarzmik
2009-12-10 21:01         ` David Brownell
2009-12-06 20:13   ` David Brownell
2009-12-10 17:49     ` Robert Jarzmik
2009-12-12 14:28 ` Robert Jarzmik
2009-12-12 16:31   ` Antonio Ospite
2009-12-20 18:36     ` Robert Jarzmik
2009-12-22 23:53       ` Antonio Ospite
2009-12-28 20:23         ` Robert Jarzmik
2009-12-28 23:03           ` Antonio Ospite
2010-01-17 12:41             ` Antonio Ospite
2010-01-17 19:33               ` Robert Jarzmik
2010-03-30 21:26           ` Michael Trimarchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200912061223.00528.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.