RFC USB: HCD/EHCI: giveback of URB in tasklet context
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
Quoted 11 lines · On Tuesday 11 June 2013 17:27:28 Ming Lei wrote:
Quoted 5 lines · Oliver Neukum
On Tuesday 11 June 2013 16:14:25 Ming Lei wrote:
The driver itself may have submitted a timer and race against it. What locking do you need in
complete()and a timer to lock against each other?Good catch.
The problem will come if only
spin_lock()is called insidecomplete(), I will check main USB drivers in tree to see if there is such use case.
All network drivers race against timeout. I think they just unlink the URB, but there's a lot of them.
Quoted 5 lines
Quoted 2 lines
But it makes no sense to go to a tasklet when you are already in task context. In those cases you need to do something, essentially blocking the tasklet.
At least now, always doing
complete()in tasklet handler can simplify implementation since these cases aren't in hot path.
Well, I am afraid this is not simply the case. These cases are partially synchronous. For example you need to make sure all calls to complete() are finished before you disconnect a HCD itself. The same applies to a device being disconnected.
It the same area, what happens if an URB is unlinked between the irq handler and the tasklet?
Regards
Oliver