On 9/25/06, Gerhard Pircher <[EMAIL PROTECTED]> wrote: > 1) The EHCI driver uses a structure called "echi_qh", which contains > both data to be accessed by the USB hardware through DMA, and > private housekeeping data.
Yes. I am currently tromping through all of this code with steel-toed boots despite not being the official maintainer. I have been seriously considering changing that design decision mainly because of the horrific typing errors that are possible (and have happened) with the slightest inattention. [snip; thanks for the analysis] > A) Rewrite qh_get() and qh_put() to use something else than > kref_get()/kref_put(). Simply using non-atomic increment and > decrement made the Oops go away, but as I don't know the design > decision behind using a struct kref, I can't say that atomicity > isn't needed, so such a simple fix might lead to race conditions. David: I very much want to know as well. I can see the obvious convenience, but is there also some other reason, eg, it's the only locking on some of the the get/puts...? If it is, we'd need to mutex anyway and then we're right back into atomic structures in shared memory. > B) Break struct ehci_qh into two parts, one allcated with > dma_pool_alloc() and one allocated with kmalloc(), where the fields > accessed by the hardware is put into the former, and the driver > private data (which includes the kref) in the latter. Safe and no > major performance hit (just one level of indirection added in some > places, and using cache-enabled memory for the internal data might > actually improve performance), but the change touches a rather > large amount of lines (patch attached). The patch collides with my pending 2500 line monster, but I have to say I like this idea the best as I have been considering doing it anyway. B has the addiitonal benefit of increasing the relative bulletproofing of the shadow schedule. Would it seriously wound the driver's cache performance? On non-PPC I mean ;-) This is my .02 and a declaration I'm willing to do it. OTOH, I'm still fishing bugs out of my own patches (even if that is going well). Monty ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
