On 24.08.22 18:09, JFLF wrote: > By process of elimination the controllers themselves were identified as > the cause of the problem. Through trial and error the issue was solved > by using USB_QUIRK_RESET_RESUME for both chips. Hi, aside from the aspects of getting this properly signed off and merged, this opens up a question. What does resetting a hub do to its children? That is if the request to wake up comes from a child, do we a) lose state in the child? b) retain the knowledge which port requested the wakeup? How far has this patch been tested? Regards Oliver