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. [..] > 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. Regards Oliver
