[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 #26 from Paul Ausbeck (paula@alumni.cse.ucsc.edu) ---
Perhaps I should further explain another point. On the Samsung machine, when
the disconnect/reconnect does not happen, which is most of the time, the device
continues to function properly. Further, since the device number does not
change, upstream actors continue to function without knowledge of resets and
what not occurring down lower in the stack, so the associated filesystem does
not have to be remounted and any userland applications with open file handles
for the device do not have to be restarted. This situation where the
disconnect/reconnect does not happen could be viewed as a success of the
current usb_persist mechanism. What would be nice would be to extend the
usb_persist mechanism so that the connection could be persisted across pseudo
disconnect/reconnect.

I think it would be a good idea to find out if a delay of some sort would have
some utility against the problem on either or both of these machines. If
someone would post and/or email me a code snippet that accomplishes such a
delay and suggest where to place such a snippet, I have source build trees on
both of these machines and could relatively easily test. A patch would also do
but since the delay may need to be moved around to find the right location, we
may as well start with the most portable delay code possible. I don't have much
experience with linux kernel code but I do have significant software
experience, including Microsoft Windows driver experience.

I also think it may be useful to say again that the emb-qm77 machine may be the
better machine serve canonically and therefore to focus on initially. I say
this because the problem there is repeatable, the problem trace has the same
form on every suspend/resume. The Samsung machine has an asynchronous
character, the disconnect/reconnect may or may not happen, when it does happen
the exact point in the trace where it happens may differ from one occurrence to
another.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.