On Fri, Dec 10, 2021 at 02:06:10PM +0800, Kai-Heng Feng wrote: > On Fri, Dec 10, 2021 at 12:04 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Dec 09, 2021 at 09:19:24AM +0800, Kai-Heng Feng wrote: > > > On Thu, Dec 9, 2021 at 5:45 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, Dec 08, 2021 at 03:08:33PM +0800, Kai-Heng Feng wrote: > > > > > When a new USB device gets plugged to nested hubs, the affected hub, > > > > > which connects to usb 2-1.4-port2, doesn't report there's any change, > > > > > hence the nested hubs go back to runtime suspend like nothing happened: > > > > > > > > That's a bug in the hub. When there's a change in the connection status > > > > of one of its ports, it should report this change to the kernel. > > > > > > I think it should, but when I searched through the USB spec and I > > > can't find anywhere specify hub requires to report it in change > > > status. > > > > USB-2.0 spec, section 11.24.2.7.2.1 (C_PORT_CONNECTION): > > > > This bit is set when the PORT_CONNECTION bit changes because of an > > attach or detach detect event (see Section 7.1.7.3). This bit will be > > cleared to zero by a ClearPortFeature(C_PORT_CONNECTION) request or > > while the port is in the Powered-off state. > > It's indeed set for the hub's downstream facing port, and that's why > wake up the hub and check its ports can still find connect event. > But I can't find anywhere stats how hub's upstream facing port should be set. It looks like the port status-change bits don't get set in response to a wakeup signal, for SuperSpeed links. Section C.1.2.3 in the USB-3.1 spec says: Note that C_PORT_LINK_STATE is not asserted in the event of a remote wakeup. As discussed previously, in the event of a Remote Wakeup the associated function sends the host a Function Wake device notification packet. I don't know if we receive those Function Wake notification packets, or what we do with them. In any case, section C.1.4.5 says that during remote wakeup, all of the links from the remote wakeup device up to the controlling hub transition to U0. But your log extract showed: [ 281.110147] usb 2-1.4-port2: status 0263 change 0000 So even though the 2-1.4.2 hub originated a wakeup signal, the upstream link to the 2-1.4 hub remained in U3 according to these status bits. Could it be that we need to include an extra delay, so the link has enough time to get into the U0 state? Maybe Mathias can help investigate this issue. Alan Stern
