> Anyway, re-reading the quote above, it sounds more like a problem > happening only via suspend. Then, this might be solved automatically > if the proper suspend/resume is implemented on usb-audio driver. > I'm not sure how alsa-lib can decide if device has been disconnected > permanently or temporary. But if you mean "closing the file descriptor > in the first time when -ENODEV occurs", it makes a lot of sense for > alsa-lib and yes, it should be there. Thanks for replies. The problem with usb_audio_disconnect() getting stuck isn't specific to suspend, although the part of it that I care about right now is. That function shouldn't be waiting for handles to be closed, as somebody can execute a DoS attack on khubd by sending SIGSTOP to any process that has the sound driver open. Perhaps the snd_device dev_disconnect and dev_unregister routines for the various abstract layers need to be changed so that sysfs/procfs entries are removed in dev_disconnect? This way it might be possible to release a slot without freeing anything that might be in use. As for implementing suspend/resume methods for snd-usb-audio, doesn't that require explicit support from the device for retaining state in some sort of low power 0.5mA mode? I don't know whether the card I'm using even supports that. -Sam Revitch _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
