Am Dienstag, 9. Dezember 2003 15:55 schrieb Alan Stern:
> On Mon, 8 Dec 2003, Oliver Neukum wrote:
>
> > Why are these new problems?
> > The newly submitted URB cannot complete because the hardware or SMP code
> > will prevent an IRQ handler from being reentered.
> > You yourself have solved the problem or you couldn't fail resubmission
> > under these circumstances.
> > Could you elaborate?
>
> Your argument is weak. There's no law saying an HC driver has to be in an
> IRQ handler when it calls giveback_urb. The only requirement is that the
from usb_hcd_giveback_urb()
* @urb: urb being returned to the USB device driver.
* @regs: pt_regs, passed down to the URB completion handler
* Context: in_interrupt()
If you wish to drop that requirement you'll have to audit all drivers with
respect to spinlocks.
> hardware must not no longer access the URB. If the driver could establish
> during the unlink call that the hardware had not even _begun_ to access
> the URB, it would be a perfectly valid optimization to call giveback_urb
> right then and there.
Yes, under an irqsave spinlock or equivalent thereof. David has done a
very crafty job of ensuring this in the hcd layer. His use of
local_irq_disable() seemed like black magic to me at first.
> I don't know that any HC drivers currently do this, but there's no reason
> they couldn't.
>
> > > As far as I'm concerned, this is all 2.7 stuff.
> >
> > Well, you are saying that there are numerous bugs in the drivers concerning
> > usb_unlink_urb(). Shouldn't something be done?
>
> I see a few choices. We could leave the core unchanged and audit all the
> drivers, making them use correct locking and synchronization. That's the
> most conservative approach and it could be done during the 2.6 development
> cycle. We could alter the core to provide a more driver-friendly API --
> for example, deprecate synchronous unlinking and add some form of
> usb_wait_for_urb -- and change the drivers to use the new API. That would
> be somewhat easier because the audits wouldn't require analyzing the
> drivers in as much detail. Finally, we could do something like what I
> suggested: leave the drivers alone and change the semantics of the
> existing API. That would be rather invasive and probably should wait
> until 2.7 starts up.
Hm, I am unsure.
Couldn't we eliminate most uses of usb_unlink_urb() from 2.6 anyway?
David, can we rely on the core nuking URBs in all cases, even software driven
disconnect?
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
