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. > > So because of this buggy hub, you now want to wake up _every_ hub in the > > system whenever any wakeup event occurs? Is this really a good idea? > > Is there a better way to solve the problem, such as a special quirk > > flag? > > If there's no other activities, the USB hub should go back to suspend > immediately, so the impact is minimal. Not immediately, but after a few seconds. However your patch will affect every hub, not just the one that the new device was plugged into. > I've seen several similar bug reports so I think this solution should > be applied for all hubs. Maybe those bug reports all had something in common, such as the type of hub or the bus speed they were running at. Did you check? Alan Stern
