> > ... though I wonder if the way uhci.c works, it might not leave the
> > qh->dev field valid rather "late" after unlinking associated URBs.
> 
> qh->dev is always valid.
> 
> > That'd be fine, except uhci_free_dev() doesn't ensure that such
> > device state is all gone.  (No such logic in usb-uhci.c either.)
> 
> What device state?

Those non-null qh->dev pointers.


>     If reference counting is working like it should be,
> the only time uhci_free_dev is called is when there are no URB's, TD's
> and QH's assigned to that device.

Well, certainly no URBs ... but the higher level code can't know
anything about HCD level state (TDs, QHs/EDs, etc).  That's
what I'd understood the HCD deallocate() call -- in this case
called uhci_free_dev() -- was responsible for cleaning.

If, as you say, deallocate() shouldn't handle that, then what does?

Yes, I just noticed that deallocate is called after the refcount goes
to zero.  While that's something I want to call a bug, it clearly won't
affect UHCI (that call is a NOP) or OHCI or EHCI (other reasons),
another reading is that something else (but what?) is expected to
clear that state.  OHCI and EHCI both use that call as the "clean
up device state" hook; seems we're into areas where the HCDs
interpret the same usbcore calls differently (trouble).

Like I said, I was just wondering ... I don't know the uhci innards,
but noticed that uhci_pci_remove() calls a routine in that BUG()
stack -- uhci_free_pending_qhs() -- only _after_ all the drivers
were disconnected.  That sure looks like uhci.c expected some
TD/QH type state to linger on and so need "late" cleanup, so it
provided the "something else" on that code path.

What I was trying to to point out was that such cleanup would also
be needed in more typical disconnect cases, and I don't see any
way to force it to happen ... certainly not where I'd have expected
it to be, in the deallocate() code!

- Dave



_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to