On Wed, 2019-06-19 at 11:19 +0200, Oliver Neukum wrote: > Am Dienstag, den 18.06.2019, 11:50 -0400 schrieb Alan Stern: > > > > On Tue, 18 Jun 2019, Mayuresh Kulkarni wrote: > > > > > > > > > > > > > You're right that the program needs to know when the device is > > > > about > > > > to > > > > be suspended. But waiting for an ioctl to return isn't a good > > > > way > > > > to do it; this needs to be a callback of some sort. That is, > > > > the > > > > kernel also needs to know when the program is ready for the > > > > suspend. > > > > > > > > I don't know what is the best approach. > > > This is becoming tricky now. > > Yes. There probably are mechanisms already in use in other parts > > of > > the kernel that would be suitable here, but I don't know what they > > are. > > We could try asking some other people for advice. > Waiting for an ioctl() is horrible. If you really want to do this > poll() would be the obvious API. It is made for waiting for changes > of states. > Understood and agreed. > [..] > > > > The suspend callback is _not_ responsible for actually suspending > > the > > device; that is handled by the USB subsystem core. > > > > These ideas are indeed applicable to programs using usbfs. The > > kernel > Not fully. Usbfs has the same issue as FUSE here. Drivers are per > interface but power management is per device. Hence every driver > is in the block IO path for these issues. You cannot do block IO > in user space. The best you can do is notify of state changes, > but you cannot wait for them. > > > > > needs to have a way to inform the program that the device is about > > enter (or has just left) a low-power state, so that the program can > > stop (or start) trying to communicate with the device. And the > > kernel > > needs to know when the program is ready for the state change. > That has difficulties based in fundamental issues. We can let user > space block power transitions. We can notify it. But we cannot > block on it. > > It would be easiest to export the usb_autopm_* API to user space. AFAIU, usb_autopm_* API operate on interface rather than on device. Due to this, they are *indirectly* exposed by appropriate class drivers to the user-space class drivers cater to. E.g.: USB audio class driver calls usb_autopm_* APIs when user space calls pcm_open(playback_stream). > > Regards > Oliver >
