On Mon, Feb 17, 2025 at 06:25:35AM +0000, Pawel Laszczak wrote: > >> For this scenario during enumeration of USB LS/FS device the Cadence xHC > >reports completion error code for xHCi commands because the devices was > >not property disconnected and in result the xHC resources has not been > >correct freed. > >> XHCI specification doesn't mention that device can be reset in any order so, > >we should not treat this issue as Cadence xHC controller bug. > >> Similar as during disconnecting in this case the device should be cleared > >starting form the last usb device in tree toward the root hub. > >> To fix this issue usbcore driver should disconnect all USB devices connected > >to hub which was reconnected while suspending. > > > >No, that's not right at all. We do not want to disconnect these devices if > >there's any way to avoid it. > > > >There must be another way to tell the host controller to release the devices' > >resources. Doesn't the usb_reset_and_verify_device() call do something like > >that anyway? After all, the situation should be very similar to what happens > >when a device is simply reset. > > > >Alan Stern > > > Yes, I had such idea too, but the current solution is simpler. > I don't understand why in this case we can't do disconnect > The hub connected to host was physically disconnected during suspend, so > It seems quite logic to make disconnection. > Can you comment why we should not make disconnection? Imagine that there is a disk drive plugged into the hub, and the drive is mounted with various files open or being written when the system gets suspended. While the system is asleep, the user unplugs the hub but then plugs it back in before the system resumes. Under those circumstances, the user expects that the drive will remain mounted, the files will remain open, and there won't be any data corruption on the drive when the system starts running again. But if we said that all the devices below the hub were disconnected then none of those things would happen and the user would lose data. Note that the same sort of thing can happen on some systems even if the hub does not get unplugged, because these systems do not provide suspend power to their USB controllers. In addition, the same sort of thing happens every time a system goes into S4 hibernation. You wouldn't want to force all users to unmount their USB drives whenever they hibernate their systems, would you? This is why we should avoid saying that devices were disconnected during suspend. Alan Stern