On Tue, 10 Dec 2013, Vikas Sajjan wrote: > > Finally, I don't see why you put this in hub_activate(). Isn't it more > > closely connected with the reset-resume procedure for the child device? > > > I was trying to add a FIX in usb_port_resume(), but in our case we > have CONFIG_USB_DEFAULT_PERSIST disabled. > > Interestingly, if I disable the CONFIG_USB_DEFAULT_PERSIST, then the > function usb_port_resume() will never be called and transcend Jetflash > device Suspend-to-RAM fails.
I don't know what you mean by "fails". The system goes to sleep and then later on wakes up, doesn't it? Do you mean that the Jetflash device gets disconnected when the system wakes up? That's _supposed_ to happen under those circumstances. When hub_activate() sees HUB_RESET_RESUME, all child devices get disconnected except those where udev->persist_enabled is set. > In normal scenario (ie., CONFIG_USB_DEFAULT_PERSIST=y) the sequence is: > =========================================================================== > Step 1: For Root HUB : > usb_resume_both() ---> usb_resume_device() -> generic_resume() --> > hcd_bus_resume() --> xhci_bus_resume(). > | > |-->usb_resume_interface() ---> > hub_reset_resume() --> xhci_update_hub_device() > > Step 2: For the Device connected > usb_resume_both() ---> usb_resume_device() -> > generic_resume()-->usb_port_resume()-->hub_port_logical_disconnect() You lost me there. Why does usb_port_resume call hub_port_logical_disconnect? Does this happen because check_port_resume_type returns an error code? What are the values of the portchange and portstatus arguments to check_port_resume_type? > --> hub_port_disable() --> hub_usb3_port_disable(). > > > In our scenario (ie., CONFIG_USB_DEFAULT_PERSIST=N) the sequence is: > =============================================================================== > Step 1: For Root HUB > usb_resume_both() ---> usb_resume_device() -> generic_resume() --> > hcd_bus_resume() --> xhci_bus_resume(). > | > |-->usb_resume_interface() ---> > hub_reset_resume() --> xhci_update_hub_device() > > Step 2 : Never occurs That's exactly right. > So Suspend-to-RAM fails. No, it succeeds in behaving the way it is intended to behave. > Hence i added a FIX in hub_reset_resume(). > > Let me know if I am wrong. I can't tell at this point. It depends on the reason why hub_port_logical_disconnect got called. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
