[Bug 220491] usb_storage connected SD card disconnects/reconnects on resume from suspend

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220491

--- Comment #25 from Paul Ausbeck (paula@alumni.cse.ucsc.edu) ---
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.