From 844db450e6e2cf710752af1a019a877af390b541 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sun, 9 Sep 2012 07:30:02 -0300 Subject: [media] gspca: Update / fix various comments wrt workqueue usb_lock usage Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/gspca/jl2005bcd.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'drivers/media/usb/gspca/jl2005bcd.c') diff --git a/drivers/media/usb/gspca/jl2005bcd.c b/drivers/media/usb/gspca/jl2005bcd.c index c4b4a9598db4..62ba80d9b998 100644 --- a/drivers/media/usb/gspca/jl2005bcd.c +++ b/drivers/media/usb/gspca/jl2005bcd.c @@ -306,15 +306,13 @@ static int jl2005c_stop(struct gspca_dev *gspca_dev) return retval; } -/* This function is called as a workqueue function and runs whenever the camera +/* + * This function is called as a workqueue function and runs whenever the camera * is streaming data. Because it is a workqueue function it is allowed to sleep * so we can use synchronous USB calls. To avoid possible collisions with other - * threads attempting to use the camera's USB interface the gspca usb_lock is - * used when performing the one USB control operation inside the workqueue, - * which tells the camera to close the stream. In practice the only thing - * which needs to be protected against is the usb_set_interface call that - * gspca makes during stream_off. Otherwise the camera doesn't provide any - * controls that the user could try to change. + * threads attempting to use gspca_dev->usb_buf we take the usb_lock when + * performing USB operations using it. In practice we don't really need this + * as the camera doesn't provide any controls. */ static void jl2005c_dostream(struct work_struct *work) { -- cgit v1.2.3