On Fri, 2019-07-05 at 10:20 -0400, Alan Stern wrote: > > > Right. I do see the resume coming in, but I don't forward it to the > > gadget because here's what happens in that order: > > > > 1- Host gets shutdown (or cable disconnected) > > > > 2- Upstream bus suspend: I call ->suspend on the gadgets on all > > enabled ports that don't have USB_PORT_STAT_SUSPEND already set. I > > don't change the port status, I don't set USB_PORT_STAT_SUSPEND > > Hmmm. Does the descriptor for your hub say that it is self-powered? A > bus-powered hub would turn off completely when its upstream cable was > unplugged, thereby sending a disconnect signal to all its child > devices. > > I don't recall what the USB spec says a self-powered hub should do. > Maybe it doesn't say anything about it. Yes it's self powered. I took the cable as an example, this scenario happens with a host power off as well of course whihc is more relevant in our case since we are a BMC). > > 3- Machine gets turned back on (or cable reconnected) > > > > 4- Upstream bus resume: I call ->resume on the gadgets on all > > enabled ports that don't have USB_PORT_STAT_SUSPEND set. > > No, the upstream bus doesn't resume upon cable reconnect. It does. At least my HW detects a resume signaling right before the but reset. > A resume > would require packets to be received over the cable, but the host won't > send any packets to the hub until the upstream port has been reset and > enabled. So you should eliminate this step. It's not a step I created. I do observe resume signaling by the hub HW (it's an interrupt) right before the bus reset when the host comes back up. In any case, no impact on what happens below... > > 5- Upstream bus reset: I call ->suspend on all enabled ports after > > clearing their status (I preserve only USB_PORT_STAT_SUSPEND and > > USB_PORT_STAT_POWER which is always set for me). Note: I currently do > > this even if the port had USB_PORT_STAT_SUSPEND set, so such as port > > will get a double suspend ... maybe I shouldn't. > > I believe the upstream reset should cause the hub to clear all the > downstream port statuses. Even if the reset doesn't do this, the > Set-Config request which follows the reset should. > > Whether you tell the gadget drivers they are no longer suspended is up > to you. I suspect it doesn't matter much. Typo. I preserve POWER and CONNECTION. Not SUSPEND. POWER because I'm self powered so it's always set and CONNECTION for obvious reasons. > > 6- Hosts sets port reset: I reset the gadget since it's already > > bound/enabled. It's still "suspended". > > > > So we do have a legitimate case of "reset while suspended". > > Ah, but it doesn't contradict what I wrote earlier. There's a > difference between resuming a suspended _device_ and resuming a > suspended _port_. > > Nevertheless, in practice the difference doesn't matter and the > composite core should do the right thing. Yes :-) > > I'll tidy up the patch and submit it. > > Good. Cheers, Ben.
