Hi Alan, On Mon, Dec 9, 2013 at 8:54 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 9 Dec 2013, Vikas Sajjan wrote: > >> Does warm reset while activating SuperSpeed HUBs if the hub activate type >> is HUB_RESET_RESUME. >> >> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend >> USB 3.0 device connected on 3.0 port, during resume I noticed that the >> XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE. >> This behaviour is inconsistent and the connection with connected USB 3.0 device >> on 3.0 port was LOST. >> >> Doing warm reset while activating SuperSpeed HUBs if the hub >> activate type is HUB_RESET_RESUME, gets the connected device to the stable state. >> >> Reviewed at https://chromium-review.googlesource.com/#/c/177132/ >> >> Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device (8564:1000) >> >> rebased on Greg Kroah-Hartman's usb-next >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git >> >> Signed-off-by: Vikas Sajjan <vikas.sajjan@xxxxxxxxxxx> >> --- >> drivers/usb/core/hub.c | 41 +++++++++++++++++++++++++---------------- >> 1 file changed, 25 insertions(+), 16 deletions(-) >> >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >> index a7c04e2..d8432b0 100644 >> --- a/drivers/usb/core/hub.c >> +++ b/drivers/usb/core/hub.c > >> @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) >> u16 portstatus, portchange; >> >> portstatus = portchange = 0; >> + >> + /* Some connected devices might be still in unknown state even >> + * after reset-resume, a WARM_RESET gets the connected device >> + * to the normal state. >> + */ >> + if (udev && hub_is_superspeed(hub->hdev) && >> + type == HUB_RESET_RESUME) >> + hub_port_reset(hub, port1, NULL, >> + HUB_BH_RESET_TIME, true); > > Please don't do this all the time to every attached port. Do it only > when it is really needed. > > Shouldn't you pass udev as the third argument? If not, please explain > why not. yea, I have NOT tried passing udev as the third argument. > > 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. 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() --> 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 So Suspend-to-RAM fails. Hence i added a FIX in hub_reset_resume(). Let me know if I am wrong. > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |