Re: [PATCH] usb: core: devio: add ioctls for suspend and resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux