On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote: > 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 It won't work like that. When a device goes into suspend there can't be any outstanding URBs. How about instead having a mechanism whereby your usrspace driver can tell when the device does a remote wakeup? At that point it could submit an URB via usbfs and receive the async notification. Alan Stern
