On Tue, 23 Aug 2016, Mathias Nyman wrote:
> Or then this happens:
> (I'll call the hcds usb2_hcd and usb3_hcd to keep track of them, usb2_hcd is the primary_hcd)
>
> to begin with:
Actually, to begin with neither usb2_hcd nor usb3_hcd exists. Then
usb2_hcd is registered, at which point we have:
usb2_hcd->primary_hcd = NULL
usb2_hcd->shared_hcd = NULL
Then usb3_hcd is registered, at which point we have:
> usb2_hcd->primary_hcd = usb2_hcd
> usb2_hcd->shared_hcd = usb3_hcd
>
> usb3_hcd->primary_hcd = usb2_hcd
> usb3_hcd->shared_hcd = usb2_hcd
>
>
> usb3_host is removed first:
> xhci_pci_remove(struct pci_dev *dev)
> usb_remove_hcd(xhci->shared_hcd); // remove usb3_hcd
> usb_put_hcd(xhci->shared_hcd)
> hcd_release(..)
> if (hcd->shared_hcd) { //true
> struct usb_hcd *peer = hcd->shared_hcd; //peer is now usb2_hcd
> peer->shared_hcd = NULL; //sets usb2_hcd->shared_hcd to NULL
> peer->primary_hcd = NULL; // sets usb2_hcd->primary_hcd to NULL. Why do we do this??
We do this because then the state is exactly the same as it was after
usb2_hcd was registered but before usb3_hcd was registered.
So what happened here is very much like what would happen if something
went wrong during probing, after the primary hcd was registered and
before the secondary hcd was registered.
Alan Stern
--
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
