On 23.08.2016 17:53, Alan Stern wrote:
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
True
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.
Ok, thanks, that makes sense.
xhci driver shouldn't assume usb2_hcd->primary_hcd exists.
It was unnecessary anyway as xhci_to_hcd() returns the primary hcd
-Mathias
--
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
