[v3] usb: warm-reset ports on hub resume, if requested

[Alan Stern <stern@rowland.harvard.edu>]

On Thu, 31 Jan 2019, Jan-Marek Glogowski wrote:

> >Perhaps you didn't notice that at the end, hub_activate() calls
> >kick_hub_wq().  That routine calls
> >usb_autopm_get_interface_no_resume(), which will prevent the hub trim
> >suspending until hub_event() calls usb_autopm_put_interface().  
> >Therefore to make things work correctly, hub_activate() has to ensure
> >that the hub->event_bits and hub->change_bits fields are set correctly,
> >so that hub_event() will do the right thing when it runs (before the 
> >hub is allowed to go back into suspend).
> >
> >Therefore if a port is in a funny state, hub_activate() should detect
> >this and set one of these bit fields appropriately.  That's one reason
> >why it contains all those tests for portstatus and portchange.  If a
> >missing test needs to be added, that's what you should do.
> 
> That would be like the v3 of my patch, which started this thread and
> detected and handled the warm-reset request of the port in
> hub_activate() on resume. Maybe we can set some of these bits
> instead, or its already handled by the hub_port_reset() call; have to
> check.

Suppose instead of making hub_activate() do the warm reset during
resume, you merely have it set the port's bit in hub->event_bits.  
Then hub_event() would see that it needed to call port_event() for that
port.  Near the end of port_event() there is code that checks whether a
warm reset is needed; would that existing code be able to solve your
problem?

> I also included a patch in some previous mail after Mathias Nyman
> commented about the NULL status_urb, which added
> usb_hcd_poll_rh_status directly after the root hubs usb_remote_wakeup
> call.
> 
> A lot of stuff is deferred via workqueue or polled. As I understand
> it - in my case - resume, suspend and status race and miss each other
> in some endless loop.

This indicates that something is not using the existing synchronization 
mechanisms properly.  For example, something sees that a status request 
is needed but doesn't store that information in the right way to 
prevent a suspend from happening before the status information has been 
retrieved.

> As things are, I just have the new desktop HWs and a single usb-c
> device to test the ports of them. I have no idea what would happen
> with an additional non-root hub, but I can probably organize one, if
> I have to test it.

I don't know if it would tell us anything, but if you want to get a 
USB-C hub and see how well it works, that would be great.

Alan Stern