On Thu, 17 May 2007 12:08:15 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> > > As it happens, USB callbacks cannot be interrupted. That's a somewhat > > > artificial restriction; in theory there's no reason we couldn't allow > > > interrupts. > > > > Do you remember why we're doing this? I did not touch that part since > > the attempt to keep usb->lock across the callback (read: years back). > > HCDs have, for historical reasons, issued URB completions in their IRQ > handlers. > > In order to do that correctly -- since completion handlers need to be > able to submit URBs -- that must be done while (a) dropping the HCD's > internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit > more subtly (c) ensuring certain HCD-internal state doesn't change until > after the completion returns. I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Linux already guarantees that interrupt handlers are not re-entered. If the interrupt controller on the platform allows it, this is done by masking a specific IRQ. If that is impossible, interrupts are masked in the CPU (maybe only partially, e.g. on SPARC). However it is done though, the local_irq_save that we do adds nothing that I can see. -- Pete ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
