On Wed, Feb 08, 2012 at 11:10:13AM +0100, Thomas Dahlmann wrote: > On disconnect the controller is reset (all buffers and registers are > cleared) and device interrupts are enabled after that to be able to > react on upcoming connects. At first I implemented the > disconnect/reset in the ISR and as mentioned I got system hangs due > to some kind of PCI core hang inside the CS5536 controller. I worked > together with the chip designers of CS5536 to find the root cause but > if I remember right we could not find it. Doing the reset out of ISR > solved the problem. This development happened around 2006 so I cannot > remember all circumstances. Hmm. Maybe an additional delay is required after some kind of operation. > >reset. Do you think a workqueue would do the work? > > I'm not familiar with work queues. I have read that they allow to run > in process context and can sleep. But as they function as bottom > halfs too it should work. > > Is there any benefit from replacing the tasklet by a work queue? I had to remove the global tasklet variable and that is how I learned about the tasklet. The tasklet is the last softirq that is run before returning to process context. It is usually used if you want to get something performance critical done real quick but you don't want to let it run in irq context with irqs off during that period. So an interrupt could still interrupt you because you use the spin_lock_bh() and friends and give you more work. Your use case does not fit here I think, it simply to run once the irqs has been served and I think you only rely on the delay here :) > >You are welcome. Do you want me to repost the code with tasklet/workqueue or > >do you want to look at it by yourself? > > It would be great if you could do. Within the next days it is not > possible for me to build up a development environment. > > Do you have a CS5536 hardware running for testing? I don't. I will be offline atleast for the next week but will take a look at this then :) > Thanks, > 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
