On Wed, Sep 21, 2022 at 12:05 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 9/12/22 13:30, Andy Shevchenko wrote: > > On Sun, Sep 11, 2022 at 07:16:41PM +0200, Hans de Goede wrote: ... > >> + case ATOMISP_DEVICE_STREAMING_STOPPING: > >> + dev_err(pipe->isp->dev, "IOCTL issued while stopping\n"); > >> + return -EBUSY; > > > > Wouldn't -EAGAIN match better in this case? > > The original checks this replaces used -EIO (which seems like a poor > choice) resp. -EBUSY (in the streamon callback) so I decided to > keep the -EBUSY here. > > Also AFAIK -EAGAIN will make the C-library retry the syscal itself > in some cases ? (not sure if this applies to ioctls though). > > This is not what we want, this scenario can only be hit when an app: > 1. Uses both the preview and the actual capture /dev/video# nodes > at the same time (this is allows) > 2. Then stops the stream at 1 of them, this transitions the state > to STOPPING > 3. Then does some ioctl other then streamoff on the other /dev/video# > > Basically when using more then 1 /dev/video# node then the app must > stop all of them when stopping things. The driver enforces this > by rejecting all calls other the streamoff until all /dev/video# > node streans are off. > > This means that simply trying again will result in the same error, > so -EBUSY seems like the best error for this. Thanks for the explanation, now it's clear to me. -- With Best Regards, Andy Shevchenko
