On Thu, 1 Nov 2018, Mayuresh Kulkarni wrote: > On Mon, 22 Oct 2018 10:24:46 -0400 > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Apologies for late response on this thread, had been on PTOs and also > checking internally about the pros/cons of suggested approach. > > > On Mon, 22 Oct 2018, Oliver Neukum wrote: > > > > > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote: > > > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote: > > > > > > > > > > The only way to make the ioctl work properly is to have it do a > > > > > > runtime-PM put at the start and then a runtime-PM get before it > > > > > > If and only if you want to do this with one ioctl() > > > If you separate the runtime-PM put and the get, you can do it without > > > the waiting part. > > > > Sure, but you still need a runtime-PM put at the start and a runtime-PM > > get at the end. In fact, if you separate this into two calls then you > > run the risk that the user may never perform the second call, and you > > would end up with an unbalanced put. > > > > A suggestion - shall we mandate the user-space to close the device before > calling the new ioctl? > As I understand, if that is done then, we don't need to worry about pm runtime > APIs in the new ioctl handler. > > The new ioctl handler shall do the following steps: > - Check if open-count. > If !0 then return error. > If 0 then proceed to next step. > - Follow the sequence you mentioned in previous response, except no pm runtime > calls. > > Sounds reasonable, in case, the user-space forgets to close the device and call > new ioctl, then we would bail-out with error i.e. user-space cannot expect the > device to suspend/resume unless it knows it is not going to use the device. That doesn't make any sense. You can't call ioctl() for a file or device that has already been closed. Alan Stern
