> > > > That summary _does_ assume a working system. ... > > > > > > I don't see what's really different? If the HC halted due to error, > > > wouldn't the devices disappear that are on the root hub? > > > > What, you mean as if by magic without the HCD doing anything > > at all? Hardly not! (Peals of laughter.) Absolutely everything > > needs to be cleaned up "by hand" as it were. > > What I meant was why is this any different from disconnecting a device? > Everything is cleaned up fine in that code path.
Good question. Wasn't I talking about the disconnect code path and explaining how it's cleaned up that way ... even in that error case? > > > > > When you remove all of that extra code, it appears to reduce down to a > > > > > single pci_pool_free call. Is that correct? > > > > > > > > No extra code ... that's wrong. As I said, it's possible that a QH > > > > may still be linked to the hardware after its URBs are unlinked. > > > > (Or for OHCI, an ED.) > > > > > > > > We know that (modulo bugs) all URBs will be unlinked when > > > > that code is called. We can't know that all QHs will be, since > > > > that involves a hardware handshake that for various reasons > > > > may not have been completed -- or even started -- by then. > > > > > > Then don't decrement the reference count until the QH is fully unlinked. > > > > I guess I don't see how what you suggest relates to anything. > > In what sense is that not being done already? > > Because when it is done, you'll decrement the reference count and then > you'll finally get your ->deallocate() callback. QH != dev. _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
