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

[Mayuresh Kulkarni <mkulkarni@opensource.cirrus.com>]

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
>