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
