Hi,
But you don't check for asynchronousity, you check for in_interrupt().Got patch? :)Not the complicated patch you prefer. I don't know enough about ehci yet. I'd likely kill the driver.
That's a one-liner. I think it won't actually affect much, but its clearly wrong and should get fixed. Which is why code review, "many eyes", is a good thing.
In that case I suspect that since hcd.c already checked for the bogus in_interrupt()/synchronous case, this code only needs to check forThe check itself is bogus.
Neither check is bogus. Only synchronous unlink calls are allowed to delay much more aggressively than spinlocking. That more "complicated" patch would address a different issue.
if (urb->transfer_flags | URB_ASYNC_UNLINK) { udelay(...);That'd do nasty things for latency, and the implication seems to be that the interrupt handler would recurse...Why? I thought udelay() spins?
In this case, with IRQs locked out, waiting for a state change that's performed by the IRQ handler. We do have code that unlinks urbs out of completion handlers, that needs to work. - Dave
No, likely a simpler solution would be to flag that qh as needing to unlink, and make end_unlink_async() do the extra work if some qh is flagged that way. ... That'd abolish the whole need to block on that path, too.Good. Regards Oliver
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
