kernel/drivers/media/usb/tm6000, branch linux-4.3.y

[media] usb drivers: use BUG_ON() instead of if () BUG

2015-06-09T21:30:09Z

Some USB drivers have a logic at the VB buffer handling like: if (in_interrupt()) BUG(); Use, instead: BUG_ON(in_interrupt()); Btw, this logic looks weird on my eyes. We should convert them to use VB2, in order to avoid those crappy things. Signed-off-by: Mauro Carvalho Chehab Acked-by: Lad, Prabhakar Signed-off-by: Mauro Carvalho Chehab

[media] tm6000: remove needless check

2015-06-05T14:26:37Z

Smatch reports a warning: drivers/media/usb/tm6000/tm6000-video.c:646 tm6000_prepare_isoc() error: we previously assumed 'dev->urb_buffer' could be null (see line 624) This is not really a problem, but it actually shows that the check if urb_buffer is NULL is being done twice: at the if and at tm6000_alloc_urb_buffers(). We don't need to do it twice. So, remove the extra check. The code become cleaner, and, as a collateral effect, smatch becomes happy. Signed-off-by: Mauro Carvalho Chehab

[media] tm6000: embed video_device

2015-04-03T02:49:49Z

Embed the video_device struct to simplify the error handling and in order to (eventually) get rid of video_device_alloc/release. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] media: drivers shouldn't touch debug field in video_device

2014-12-23T12:29:04Z

The debug field in struct video_device is for internal use only and drivers should mix that with their own debug module options. It is handled by the V4L2 core and users can set it using /sys/class/video4linux//debug. It has been deprecated for some time now, so it is time to remove it completely from the drivers. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: rename dev->scanmask to dev->scancode_mask

2014-07-25T22:10:43Z

We already have dev->scancode_filter and dev->scancode_wakeup_filter so rename dev->scanmask to dev->scancode_mask for consistency. Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: remove protocol arrays

2014-07-25T22:10:43Z

The basic API of rc-core used to be: dev = rc_allocate_device(); dev->x = a; dev->y = b; dev->z = c; rc_register_device(); which is a pretty common pattern in the kernel, after the introduction of protocol arrays the API looks something like: dev = rc_allocate_device(); dev->x = a; rc_set_allowed_protocols(dev, RC_BIT_X); dev->z = c; rc_register_device(); There's no real need for the protocols to be an array, so change it back to be consistent (and in preparation for the following patches). [m.chehab@samsung.com: added missing changes at some files] Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: document the protocol type

2014-07-24T00:50:48Z

Right now the protocol information is not preserved, rc-core gets handed a scancode but has no idea which protocol it corresponds to. This patch (which required reading through the source/keymap for all drivers, not fun) makes the protocol information explicit which is important documentation and makes it easier to e.g. support multiple protocols with one decoder (think rc5 and rc-streamzap). The information isn't used yet so there should be no functional changes. [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing] Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab

[media] v4l: Support extending the v4l2_pix_format structure

2014-07-17T15:44:47Z

The v4l2_pix_format structure has no reserved field. It is embedded in the v4l2_framebuffer structure which has no reserved fields either, and in the v4l2_format structure which has reserved fields that were not previously required to be zeroed out by applications. To allow extending v4l2_pix_format, inline it in the v4l2_framebuffer structure, and use the priv field as a magic value to indicate that the application has set all v4l2_pix_format extended fields and zeroed all reserved fields following the v4l2_pix_format field in the v4l2_format structure. The availability of this API extension is reported to userspace through the new V4L2_CAP_EXT_PIX_FORMAT capability flag. Just checking that the priv field is still set to the magic value at [GS]_FMT return wouldn't be enough, as older kernels don't zero the priv field on return. To simplify the internal API towards drivers zero the extended fields and set the priv field to the magic value for applications not aware of the extensions. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

[media] media: remove the setting of the flag V4L2_FL_USE_FH_PRIO

2014-07-04T19:14:59Z

Since all the drivers that use `struct v4l2_fh' use the core priority checking, the setting of the flag in the drivers can be removed. Signed-off-by: Ramakrishnan Muthukrishnan Reviewed-by: Hans Verkuil Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] v4l: subdev: Move [gs]_std operation to video ops

2014-05-24T20:11:26Z

The g_std and s_std operations are video-related, move them to the video ops where they belong. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Acked-by: Lad, Prabhakar Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab