linux.git/drivers/media/common, branch v6.1.2

media: videobuf2-core: take mmap_lock in vb2_get_unmapped_area()

2022-12-07T19:25:40+00:00

While vb2_mmap took the mmap_lock mutex, vb2_get_unmapped_area didn't.
Add this.

Also take this opportunity to move the 'q->memory != VB2_MEMORY_MMAP'
check and vb2_fileio_is_active() check into __find_plane_by_offset() so
both vb2_mmap and vb2_get_unmapped_area do the same checks.

Since q->memory is checked while mmap_lock is held, also take that lock
in reqbufs and create_bufs when it is set, and set it back to
MEMORY_UNKNOWN on error.

Fixes: f035eb4e976e ("[media] videobuf2: fix lockdep warning")
Signed-off-by: Hans Verkuil 
Acked-by: Tomasz Figa 
Reviewed-by: Ricardo Ribalda 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Linus Torvalds

v4l2: don't fall back to follow_pfn() if pin_user_pages_fast() fails

2022-12-02T21:33:57+00:00

The V4L2_MEMORY_USERPTR interface is long deprecated and shouldn't be
used (and is discouraged for any modern v4l drivers).  And Seth Jenkins
points out that the fallback to VM_PFNMAP/VM_IO is fundamentally racy
and dangerous.

Note that it's not even a case that should trigger, since any normal
user pointer logic ends up just using the pin_user_pages_fast() call
that does the proper page reference counting.  That's not the problem
case, only if you try to use special device mappings do you have any
issues.

Normally I'd just remove this during the merge window, but since Seth
pointed out the problem cases, we really want to know as soon as
possible if there are actually any users of this odd special case of a
legacy interface.  Neither Hans nor Mauro seem to think that such
mis-uses of the old legacy interface should exist.  As Mauro says:

 "See, V4L2 has actually 4 streaming APIs:
        - Kernel-allocated mmap (usually referred simply as just mmap);
        - USERPTR mmap;
        - read();
        - dmabuf;

  The USERPTR is one of the oldest way to use it, coming from V4L
  version 1 times, and by far the least used one"

And Hans chimed in on the USERPTR interface:

 "To be honest, I wouldn't mind if it goes away completely, but that's a
  bit of a pipe dream right now"

but while removing this legacy interface entirely may be a pipe dream we
can at least try to remove the unlikely (and actively broken) case of
using special device mappings for USERPTR accesses.

This replaces it with a WARN_ONCE() that we can remove once we've
hopefully confirmed that no actual users exist.

NOTE! Longer term, this means that a 'struct frame_vector' only ever
contains proper page pointers, and all the games we have with converting
them to pages can go away (grep for 'frame_vector_to_pages()' and the
uses of 'vec->is_pfns').  But this is just the first step, to verify
that this code really is all dead, and do so as quickly as possible.

Reported-by: Seth Jenkins 
Acked-by: Hans Verkuil 
Acked-by: Mauro Carvalho Chehab 
Cc: David Hildenbrand 
Cc: Jan Kara 
Signed-off-by: Linus Torvalds

treewide: use get_random_{u8,u16}() when possible, part 1

2022-10-11T23:42:58+00:00

Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value. This was done
mechanically with this coccinelle script:

@@
expression E;
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
typedef u16;
typedef __be16;
typedef __le16;
typedef u8;
@@
(
- (get_random_u32() & 0xffff)
+ get_random_u16()
|
- (get_random_u32() & 0xff)
+ get_random_u8()
|
- (get_random_u32() % 65536)
+ get_random_u16()
|
- (get_random_u32() % 256)
+ get_random_u8()
|
- (get_random_u32() >> 16)
+ get_random_u16()
|
- (get_random_u32() >> 24)
+ get_random_u8()
|
- (u16)get_random_u32()
+ get_random_u16()
|
- (u8)get_random_u32()
+ get_random_u8()
|
- (__be16)get_random_u32()
+ (__be16)get_random_u16()
|
- (__le16)get_random_u32()
+ (__le16)get_random_u16()
|
- prandom_u32_max(65536)
+ get_random_u16()
|
- prandom_u32_max(256)
+ get_random_u8()
|
- E->inet_id = get_random_u32()
+ E->inet_id = get_random_u16()
)

@@
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
typedef u16;
identifier v;
@@
- u16 v = get_random_u32();
+ u16 v = get_random_u16();

@@
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
typedef u8;
identifier v;
@@
- u8 v = get_random_u32();
+ u8 v = get_random_u8();

@@
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
typedef u16;
u16 v;
@@
-  v = get_random_u32();
+  v = get_random_u16();

@@
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
typedef u8;
u8 v;
@@
-  v = get_random_u32();
+  v = get_random_u8();

// Find a potential literal
@literal_mask@
expression LITERAL;
type T;
identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32";
position p;
@@

        ((T)get_random_u32()@p & (LITERAL))

// Examine limits
@script:python add_one@
literal << literal_mask.LITERAL;
RESULT;
@@

value = None
if literal.startswith('0x'):
        value = int(literal, 16)
elif literal[0] in '123456789':
        value = int(literal, 10)
if value is None:
        print("I don't know how to handle %s" % (literal))
        cocci.include_match(False)
elif value < 256:
        coccinelle.RESULT = cocci.make_ident("get_random_u8")
elif value < 65536:
        coccinelle.RESULT = cocci.make_ident("get_random_u16")
else:
        print("Skipping large mask of %s" % (literal))
        cocci.include_match(False)

// Replace the literal mask with the calculated result.
@plus_one@
expression literal_mask.LITERAL;
position literal_mask.p;
identifier add_one.RESULT;
identifier FUNC;
@@

-       (FUNC()@p & (LITERAL))
+       (RESULT() & LITERAL)

Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Kees Cook 
Reviewed-by: Yury Norov 
Acked-by: Jakub Kicinski 
Acked-by: Toke Høiland-Jørgensen  # for sch_cake
Signed-off-by: Jason A. Donenfeld

media: videobuf2: Remove vb2_find_timestamp()

2022-08-30T12:44:45+00:00

Now that we've transitioned all users to vb2_find_buffer API,
remove the unused vb2_find_timestamp().

Signed-off-by: Ezequiel Garcia 
Acked-by: Tomasz Figa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: saa7146: deprecate hexium_gemini/orion, mxb and ttpci

2022-08-29T14:46:38+00:00

Deprecate the hexium_gemini, hexium_orion, mxb and ttpci saa7146-based
drivers: these drivers do not use the vb2 framework for video streaming,
instead it uses the old videobuf framework.

We want to get rid of these old drivers, so deprecated these for future
removal.

[hverkuil: update MAINTAINERS file]

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: vb2: videobuf -> videobuf2

2022-08-29T13:38:09+00:00

It is confusing to use the term 'videobuf' or 'video-buf' since that
usually refers to the old videobuf version 1 framework. Rename to
'videobuf2' or vb2.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videobuf2: Introduce vb2_find_buffer()

2022-07-17T10:10:11+00:00

All users of vb2_find_timestamp() combine it with vb2_get_buffer()
to retrieve a videobuf2 buffer, given a u64 timestamp.

Introduce an API for this use-case. Users will be converted to the new
API as follow-up commits.

Signed-off-by: Ezequiel Garcia 
Acked-by: Tomasz Figa 
Reviewed-by: Philipp Zabel 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: v4l2-tpg: Add support for the new YUVA and YUVX formats

2022-07-15T14:01:28+00:00

Extend the TPG to support generating the newly added YUVA and YUVX pixel
formats.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jacopo Mondi 
Reviewed-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: v4l2-tpg: add HDMI Video Guard Band test pattern

2022-06-20T09:30:30+00:00

This inserts 4 pixels of the RGB color 0xab55ab at the left hand side of
the image. This is only done for 3 or 4 byte RGB pixel formats. The HDMI
TMDS encoding of this pixel value equals the Video Guard Band value as
defined by HDMI (see section 5.2.2.1 in the HDMI 1.3 Specification) that
preceeds the first actual pixel of a video line. If an HDMI receiver
doesn't handle this correctly, then it might keep skipping these Video
Guard Band patterns and end up with a shorter video line. So this is a
nice pattern to test with.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videobuf2-dma-sg.c: kvmalloc_array -> kvcalloc

2022-05-13T09:02:22+00:00

Fixes smatch warning:

drivers/media/common/videobuf2/videobuf2-dma-sg.c:129 vb2_dma_sg_alloc() warn: Please consider using kvcalloc instead

Signed-off-by: Hans Verkuil 
Acked-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab