https://bugzilla.kernel.org/show_bug.cgi?id=220491 --- Comment #25 from Paul Ausbeck (paula@xxxxxxxxxxxxxxxxxxx) --- Alan, I think there is some confusion over my terminology. When I say that something reliably disconnects, that means the disconnect happens on every suspend resume. The emb-qm77 disconnect happens on every suspend/resume, whereas on the Samsung machine the disconnect only happens say 20% of the time. When I say that a disconnect happens, it is invariably followed by a reconnection. This means that in every case the device continues to work just fine. The problem is that the usb_storage, or uas, context is lost and the device must be remounted. When I suggest to extend the kernel's usb_persist mechanism, I make a purely philosophical point. In all cases at issue here, the device is not actually being disconnected/reconnected, the D/R is being simulated via software. I feel like such a software simulated disconnect/reconnect falls into the same philosophical area as the current usb_persist mechanism. If the disconnect/reconnect is happening in order to "cure" the device, then somehow the connection state should be preserved so that higher level actors, such as usb_storage and uas don't know about the disconnect/reconnect. Currently, when a disconnect/reconnect happens, the reconnected device gets a new "device number", and since this "device number" is visible up the chain, the chain inherently fails and must be re-established all the up to filesystem mount.. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
