At Wed, 09 Oct 2013 10:41:57 +0200, Clemens Ladisch wrote: > > Takashi Iwai wrote: > >> On Tue, 8 Oct 2013 baum...@hotmail.com wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=62691 > >>> > >>> Summary: no reset_resume for driver snd-usb-audio for logitech headset > >>> H600 > > > > How about simply applying the same resume for reset_resume like below? > > > > --- > > > > diff --git a/sound/usb/card.c b/sound/usb/card.c > > index 9d9de8d..c591a83 100644 > > --- a/sound/usb/card.c > > +++ b/sound/usb/card.c > > @@ -747,6 +747,7 @@ static struct usb_driver usb_audio_driver = { > > .disconnect = usb_audio_disconnect, > > .suspend = usb_audio_suspend, > > .resume = usb_audio_resume, > > + .reset_resume = usb_audio_resume, > > .id_table = usb_audio_ids, > > .supports_autosuspend = 1, > > }; > > When the device was reset, the state of all mixer controls has been > lost. Disconnecting the card (the default behaviour without > reset_resume) is the correct thing to do in this situation.
Ah, I somehow thought we resume the mixer control values as well (as they are cached in the driver). So it's possible to resume these in reset_resume case, in theory, too. But, not all stuff has been cached, e.g. the quirk stuff may be handled exceptionally. > Userspace should pick up the USB device again when it reappears. > (But it doesn't. Is this a PulseAudio or a KDE problem?) PulseAudio shows the problem, AFAIK. IIRC, it's a bit tricky to achieve this because it can be other > And why does the kernel whine about the lack of a callback that is > documented as being optional? Indeed... Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
