On Tue, 9 Oct 2018 13:27:02 +0200 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 09, 2018 at 10:51:53AM +0100, Mayuresh Kulkarni wrote: > > With all due respect, one of the possible reason for this could be, > > power saving on mobile/tablet platforms (running Android). These > > platforms usually have a single USB port. Specifically from our point > > of view, these platforms are removing 3.5 mm jack and hence the only > > interface available for headsets is USB. > > But the USB audio interface uses the in-kernel driver, which should > handle the power management issues automatically. There is no need to > use usbfs for hardware like this. > > So what real-world example are you having that requires this that does > not use a kernel driver? And why can you not just close the device? > (As you probably might have guessed), we have a composite USB device with USB audio and USB HID. However, to support our specific features (USP) that does not fit into either USB-audio or USB-HID spec, we have another interface. Some of the controls exposed by it indirectly affect the audio pipeline. It is this part of system which is in user-space and uses USB-FS driver to talk to interface. We are looking into closing the device instance during normal operation i.e.: only open/close device when needed. However, we still have one particular use-case where our USB device sends async notification to USB-host via the above interface. For that, as of now, we queue a URB from user-space. But because, the link never enters suspend (L2), we receive this async notification. I am not sure, how this use-case will work, if we open-close device only when needed. Assuming we have PM calls moved from open/close to ioctl or some other appropriate method, is the following sequence possible - * Queue an URB -> suspend (L2) * Device does remote wake & sends async notification * URB above returns with that notification > thanks, > > greg k-h P.S.: Oliver N - I hope above comment also acts as a response to your comment in previous part of mail thread. Thanks,
