On 08/01/2013 03:33 PM, Clemens Ladisch wrote:
Qiao Zhou wrote:
when usb audio device removes, it doesn't notify the ALSA read /
write thread. due to no data transmitting any more, those threads
wait for a long timeout(10s), then detects IO error. it causes
long time blocking in upper layer read/write.
to fix this issue, wake up potential sleep thread if necessary
when audio unbind.
+ if (substream && substream->runtime && substream->runtime->twake)
+ wake_up(&substream->runtime->tsleep);
The PCM stream should be properly stopped, which automatically takes
care of notifying userspace. See this code for an example:
<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/line6/pcm.c?id=86f0b5b86d142b9323432fef078a6cf0fb5dda74#n392>
It's reasonable. will update the patch accordingly. thanks.
substream & pcm may still be used after audio unbind, and we
should only set null to it in audio_pcm_close.
What happens when the application immediately tries to restart the
stream? Many USB audio drivers set a "disconnected" flag to prevent
this, but I don't know if the gadget driver has races that would require
such a check.
I just met an issue with a SS phone + ADK2012 HW. when the ADK2012 HW
removed from usb I/F, the flow in gadget/audio file is like this:
android_disconnect-> android_disable-> audio_unbind ->
audio_unbind_config -> android_enable -> audio_source_bind_config ->
audio_bind -> android_disable-> audio_unbind -> audio_unbind_config.
the wake up in the 1st audio_unbind can't wake up the sleep thread, and
I need to do it one more time in 2nd audio_unbind. The substream is
still needed.
To me, I didn't see races since it only points to pcm substream and
won't cause trouble in audio file driver. please instruct me if you have
more comments.
Regards,
Clemens
--
Best Regards
Qiao
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
