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 16:14:25 Ming Lei wrote:
Quoted 10 lines · Oliver Neukum
Quoted 8 lines · On Tuesday 11 June 2013 13:40:20 Ming Lei wrote:
Quoted 1 line · Alan Stern
On Mon, 10 Jun 2013, Ming Lei wrote:
If
complete()callback runs in one tasklet context,spin_lock()insidecomplete()is enough, just like hard irq, the tasklet itself is disabled duringcomplete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources betweencomplete().
Quoted 6 lines
Quoted 1 line
We also have exclusion between
complete()and other contexts, i.e. timers.The patch also converts the
complete()called in timers to tasklet context too.So could you let me know if that eases your concern? If not, could you explain your concern about other contexts in a bit detail?
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?
Quoted 7 lines
Quoted 3 lines
Even now we cannot guarantee that all calls to
complete()are in irq. There is the case of HCD hotunplug and other cases, like timeouts. They will have to be verified.All URBs are completed via
usb_hcd_giveback_urb(), so there should be no differences between these cases and the common one about introducing the patchset.
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.
Regards
Oliver