On Thu, 11 Oct 2018 14:29:54 -0400 Alan Stern <[email protected]> wrote:
> On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote: > > > On Tue, 9 Oct 2018 13:27:02 +0200 > > Greg KH <[email protected]> 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 Unfortunately, that is not possible in our use-case. It is the composite USB device that needs to detect an activity and convey it to host for taking appropriate action. But since the activity depends on end-user, it can happen at anytime. We do not want to keep the link active, just to detect this, which is not good from battery life point of view.
