kernel/git/stable/linux.git/drivers/media/video/ov511.c, branch master

V4L/DVB: Remove obsolete ov511 driver

2010-08-02T18:26:13+00:00

obsolete v4l1 driver replaced by gspca_ov519 Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab

V4L/DVB: ov511: cleanup: remove unneeded null check

2010-05-19T15:59:13+00:00

We dereference "ov" unconditionally throughout the function so there is no way it can be NULL here. This code has been around for ages so if it were possible for "ov" to be NULL someone would have complained. Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab

V4L/DVB: ov511: Fix continuation lines

2010-05-19T15:56:43+00:00

Signed-off-by: Joe Perches Signed-off-by: Douglas Schilling Landgraf Signed-off-by: Mauro Carvalho Chehab

V4L/DVB: drivers/media/video: avoid NULL dereference

2010-05-19T15:56:42+00:00

It seems impossible for ov to be NULL at this point. The semantic match that finds the problem is as follows: (http://coccinelle.lip6.fr/) // @r exists@ expression E, E1; identifier f; statement S1,S3; iterator iter; @@ if ((E == NULL && ...) || ...) { ... when != false ((E == NULL && ...) || ...) when != true ((E != NULL && ...) || ...) when != iter(E,...) S1 when != E = E1 ( sizeof(E->f) | * E->f ) ... when any return ...; } else S3 // Signed-off-by: Julia Lawall Signed-off-by: Douglas Schilling Landgraf Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (13596): ov511.c typo: lock => unlock

2009-12-16T02:18:33+00:00

This was found with a static checker and has not been tested, but it seems pretty clear that the mutex_lock() was supposed to be mutex_unlock() Signed-off-by: Dan Carpenter Signed-off-by: Douglas Schilling Landgraf Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (13556): v4l: Remove unneeded video_device::minor assignments

2009-12-16T02:17:57+00:00

Now that the video_device registration is tested using video_is_registered(), drivers don't need to initialize the video_device::minor field to -1 anymore. Remove those unneeded assignments. [mchehab.redhat.com: removed tm6000 changes as tm6000 is not ready yet for submission even on staging] Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (13555): v4l: Use video_device_node_name() instead of the minor number

2009-12-16T02:17:57+00:00

Instead of using the minor number in kernel log messages, use the device node name as returned by the video_device_node_name() function. This makes debug, informational and error messages easier to understand for end users. [mchehab.redhat.com: removed tm6000 changes as tm6000 is not ready yet for submission even on staging] Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (13553): v4l: Use the video_is_registered function in device drivers

2009-12-16T02:17:56+00:00

Fix all device drivers to use the video_is_registered function instead of checking video_device::minor. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (12083): ov511: remove ov518 usb id's from the driver

2009-06-23T06:13:16+00:00

ov511: remove ov518 usb id's from the driver, as they have not been working ever since the decompression code got removed from the kernel, and they are no supported by the gspca_ov519 module. Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (11966): ov511: Fix unit_video parameter behavior

2009-06-16T22:07:40+00:00

Fix a regression caused by changeset 9133:64aed7485a43 - v4l: disconnect kernel number from minor Before the above changeset, ov511_probe used to allow forcing to use a certain specific set of video devices, like: modprobe ov511 unit_video=4,1,3 num_uv=3 So, assuming that you have 5 ov511 devices, and connect they one by one, they'll gain the following device numbers (at the connection order): /dev/video4 /dev/video1 /dev/video3 /dev/video0 /dev/video2 However, this was changed due to this change at video_register_device(): + nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr); With the previous behavior, a trial to register on an already allocated mirror would fail, and a loop would get the next requested minor. However, the current behavior is to get the next available minor instead of failing. Due to that, this means that the above modprobe parameter will give, instead: /dev/video5 /dev/video6 /dev/video7 /dev/video8 /dev/video9 In order to restore the original behavior, a static var were added, storing the amount of already registered devices. While there, it also fixes the locking of the probe/disconnect functions. Signed-off-by: Mauro Carvalho Chehab