lkml.org 
[lkml]   [2013]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
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



\
 
 \ /
  Last update: 2013-12-11 18:41    [W:0.159 / U:1.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site