* 'Greg Kroah-Hartman' | 2014-12-09 11:54:15 [-0500]: >> You can unbind the HCD driver from the PCI-device via sysfs and this is >> not something not only a developer does. This "unbind" calls the remove >> function of the driver and the only difference between unbind and rmmod >> is that the module remains inserted (but this is no news for you). > >If unbind causes a problem, it's the same problem that could happen if >the hardware is hot-unplugged (like on a PCI card.) Stuff like that >_does_ need to be fixed, and if your test shows this is a problem, I am >all for fixing that. so I tried this with unbind and it didn't explode as assumed. On musb, for some reason the hcd struct never gets cleaned up. The driver free(s) URB memory after the hcd_pools are gone but since its size is 32KiB it uses dma_free_coherent() and this seems to work fine (sice the device is still there). So tried the same thing with EHCI. EHCI-hcd cleans up its HCD-struct as expected so I would have to poke at musb and figure out why it does not happen. Also, there is another difference: with EHCI I see first removal of buffers followed by removal of the pools. So it happens after disconnect but before the HCD pools are gone. I'm not sure why this happens with EHCI but not with MUSB. It seems that for some reason unbind triggers an error on /dev/video0 which makes gst-launch close that file. Once all users are gone, that hcd struct is cleaned up. Again, it works as I would expect it with EHCI but not with MUSB. So maybe, once I learned how MUSB dafeated the userspace notification about a gone device I might gain the same behavior that EHCI has. Also not freed hcd struct of musb looks also important :) >thanks, > >greg k-h Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
