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. > I think my point is - usbfs driver is actually doing nothing w.r.t USB- > 2.0 L2 state, right? The root-hub's suspend will invoke the USB-2.0 L2 > transitions. This will happen when all the USB devices on that port > report idle to USB-core. > I agree that usually driver's suspend/resume call-back will put the > device in its low power state. But that is not applicable to udev of > usbfs driver, right? It doesn't work quite the way you think. The suspend callback informs the driver that the device is about to enter a low-power state. The callback's job is to make the driver stop trying to communicate with the device, since all such communication attempts will fail once the device is suspended. 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 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. > So, doesn't it makes sense to tell user-space about actual USB-2.0 L2 > state transitions rather than suspend/resume entry call-backs of device- > driver model of kernel (which are stub in this context)? Yes, that's what we need to figure out. But things have to happen in the right order; otherwise you could encounter a situation where the userspace program's URBs start failing and the program doesn't learn until later that the reason is because the device is being suspended. Alan Stern
