On Mon, 11 Jul 2016, Huang, Huki wrote: > When end user inserts a usb3 device and put dut to s3. What does "dut" mean? > Then hotplug the usb3 disk under s3. Do you mean that the device is unplugged and the USB disk then is plugged into the same port? Or do you mean that the device remains plugged in and the disk is plugged into a different port? > The device will be lost upon resuming from s3. If the device is unplugged then it _should_ be lost. > There is a corner case that the hub->change_bits for > the usb3 port is not set when usb port change event happens. Under what conditions does this corner case occur? > This will cause hub driver ignore the device enumeration > in the end of port_event in hub.c > > Signed-off-by: huki.huang@xxxxxxxxx > --- > drivers/usb/core/hub.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index bee1351..859adcb 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -4747,6 +4747,7 @@ static void hub_port_connect(struct usb_hub *hub, int port1, u16 portstatus, > if (hcd->usb_phy && !hdev->parent) > usb_phy_notify_disconnect(hcd->usb_phy, udev->speed); > usb_disconnect(&port_dev->child); > + set_bit(port1, hub->change_bits); Why is this needed? The only reason for setting hub->change_bits is to tell hub_event() that it needs to call port_event() and to tell port_event() that it needs to call hub_port_connect_change(). Once hub_port_connect_change() is running, there is no reason to set hub->change_bits. > } > > /* We can forget about a "removed" device when there's a physical 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
