On Tue, Feb 07, 2012 at 03:46:53PM +0100, Thomas Dahlmann wrote: > On 04.02.2012 18:55, Sebastian Andrzej Siewior wrote: > >The disconnect code is scheduled in a tasklet. I don't see the point in > >doing this and the comment says that we may want do this in the irq. This > >patch is doing so. > > > > The disconnect code should stay in a tasklet as a controller soft > reset is done there. I remember issues when doing a controller soft > reset inside interrupt context because the whole controller is wiped > by reset. Interresting. The disconnect is the last thing you do i.e. you are not doing anything after you triggered that tasklet. So it should not make that much of a difference. > Soft reset on disconnect was needed for disconnects in the middle of > a transfer. Then controller buffers and registers may remain in a > kind of stuck state which can be resolved by a soft reset only. Nice. > I have to build up a system to play with the driver a little bit > (haven't done that for a while). Okay. I was going rid of the tasklet because it did not look perfomance critical or anything _and_ I was going to get rid of global variables. You mask interrupts before disconnect and then you enable them later after the reset. Do you think a workqueue would do the work? > Sebastian, thank you very much for your work. You are welcome. Do you want me to repost the code with tasklet/workqueue or do you want to look at it by yourself? > Thomas Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
