[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiDSCuT6uK+qGJJus=s2DjsnvqxKg4ek9xbssOw5bpmQm_e-A@mail.gmail.com>
Date: Wed, 22 Nov 2023 10:55:16 +0100
From: Ricardo Ribalda <ribalda@...omium.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Guenter Roeck <linux@...ck-us.net>,
Tomasz Figa <tfiga@...omium.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Alan Stern <stern@...land.harvard.edu>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
Sean Paul <seanpaul@...omium.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: Re: [PATCH v3 2/3] media: uvcvideo: Do not halt the device after disconnect
Hi Sergey
On Wed, 22 Nov 2023 at 09:01, Sergey Senozhatsky
<senozhatsky@...omium.org> wrote:
>
> On (23/11/22 16:47), Sergey Senozhatsky wrote:
> > Can the following happen?
>
> Consider the following case (when CPU1 experienced a delay, a preemption
> or anything):
>
> > CPU0 CPU1
> > uvc_disconnect()
> > uvc_video_stop_streaming()
> > usb_set_intfdata()
> > uvc_unregister_video()
> >
> > if (!smp_load(&dev->disconnected))
> >
> > smp_store_release(&dev->disconnected, true);
> >
> > kref_put(&dev->ref, uvc_delete);
>
> > uvc_video_halt()
>
> That uvc_video_halt() cannot be legal, right?
This patch only takes care of calls to uvc_video_stop_streaming()
after .disconnect.
Guenter's patch from this series should take care of the concurrent
calls. I will resend making it explicit.
Thanks!
--
Ricardo Ribalda
Powered by blists - more mailing lists