[GIT PULL for v4.4] vb2 dma-contig and dma-sg cache sync fix

2015-10-08 Thread Sakari Ailus 
Hi Mauro,

Here are the two vb2 fixes from Tiffany Lin. I've split them into two and
added cc stable since these should be applied to kernels since v3.8 and
v3.19 respectively.

Please pull.

The following changes since commit f4f24d1fd0803e8b5de5da373276f5046bef7463:

  [media] drxd: use kzalloc in drxd_attach() (2015-10-03 11:44:32 -0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git tags/vb2-nents-media-master

for you to fetch changes up to 7883759183985e8a94e237ed6f49ae3581a8e499:

  media: vb2 dma-sg: Fully cache synchronise buffers in prepare and finish 
(2015-10-07 14:14:26 +0300)


Tiffany Lin (2):
  media: vb2 dma-contig: Fully cache synchronise buffers in prepare and 
finish
  media: vb2 dma-sg: Fully cache synchronise buffers in prepare and finish

 drivers/media/v4l2-core/videobuf2-dma-contig.c | 5 +++--
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)


-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] si2157: Bounds check firmware

2015-10-08 Thread Olli Salonen 
Reviewed-by: Olli Salonen 
Tested-by: Olli Salonen 


On 6 October 2015 at 01:33, Laura Abbott  wrote:
>
> When reading the firmware and sending commands, the length
> must be bounds checked to avoid overrunning the size of the command
> buffer and smashing the stack if the firmware is not in the
> expected format. Add the proper check.
>
> Cc: sta...@kernel.org
> Signed-off-by: Laura Abbott 
> ---
> v2: Set the return code properly
> ---
>  drivers/media/tuners/si2157.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
> index 5073821..0e1ca2b 100644
> --- a/drivers/media/tuners/si2157.c
> +++ b/drivers/media/tuners/si2157.c
> @@ -166,6 +166,11 @@ static int si2157_init(struct dvb_frontend *fe)
>
> for (remaining = fw->size; remaining > 0; remaining -= 17) {
> len = fw->data[fw->size - remaining];
> +   if (len > SI2157_ARGLEN) {
> +   dev_err(>dev, "Bad firmware length\n");
> +   ret = -EINVAL;
> +   goto err_release_firmware;
> +   }
> memcpy(cmd.args, >data[(fw->size - remaining) + 1], len);
> cmd.wlen = len;
> cmd.rlen = 1;
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AverMedia HD Duet (White Box) A188WB drivers

2015-10-08 Thread Manu Abraham 
Hi,

I just got back at work again. Will set things up this weekend/next week.

On Thu, Oct 8, 2015 at 3:38 AM, David Nelson  wrote:
> It's been a while since I originally asked you about this has there
> been any progress?
>
> On Fri, Jun 12, 2015 at 11:21 PM, Manu Abraham  wrote:
>> Hi David,
>>
>> The saa7160 chipset is supported by the saa716x driver.
>> I wrote a driver for it, which is over here.
>> http://git.linuxtv.org/cgit.cgi/manu/saa716x_new.git
>>
>> I do have the A188 card and documentation also with me,
>> thanks to Avermedia.
>>
>> The card is not yet supported in the above tree, so cloning
>> that tree will not help much in your case. Though I have
>> some code related to that, it is only on my local testbox
>>
>> I've been with an accident and my other hand is in a restrictive
>> state with minimal movements. It will be a few weeks, before
>> I can do something in this area. It's not much help to you at
>> this point right now, but just fyi
>>
>> Manu
>>
>>
>>
>> On Sat, Jun 13, 2015 at 8:46 AM, David Nelson  wrote:
>>> I have the AverMedia HD Duet (White Box) A188WB. Which has been
>>> working great for several years in Windows 7 Media Center. I just
>>> tried installing Mythbuntu but it does not appear to be recognized. I
>>> am a bit of a newbie but I managed to find some info about it.
>>>
>>> Does anyone know of a driver for it? lspci says it uses the Philips
>>> SAA7160 which does appear to be in a few other supported devices.
>>>
>>> Details follow
>>>
>>> I get the following from lspci -vvnnk
>>>
>>> 03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160
>>> [1131:7160] (rev 01)
>>> Subsystem: Avermedia Technologies Inc Device [1461:1e55]
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>> Stepping- SERR- FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> SERR- >> Latency: 0, Cache Line Size: 64 bytes
>>> Interrupt: pin A routed to IRQ 10
>>> Region 0: Memory at ef80 (64-bit, non-prefetchable) [size=1M]
>>> Capabilities: 
>>>
>>>
>>> I can see that there is a driver for a few other devices with this
>>> chip at http://www.linuxtv.org/wiki/index.php/NXP_SAA716x  (i.e.
>>> heading "As of (2014-06-07)"
>>>
>>>
>>> --
>>> -David Nelson
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> -David Nelson
> Home: 801-302-1347
> Cell: 801-205-8248
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

2015-10-08 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri Oct  9 04:00:14 CEST 2015
git branch: test
git hash:   efe98010b80ec4516b2779e1b4e4a8ce16bf89fe
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-3.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: ERRORS
linux-2.6.33.7-i686: ERRORS
linux-2.6.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-rc1-i686: OK
linux-2.6.32.27-x86_64: ERRORS
linux-2.6.33.7-x86_64: ERRORS
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: ERRORS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] media: fix waitqueue_active without memory barrier in cpia2 driver

2015-10-08 Thread Kosuke Tatsukawa 
cpia2_usb_disconnect() seems to be missing a memory barrier which might
cause the waker to not notice the waiter and miss sending a wake_up as
in the following figure.

cpia2_usb_disconnectsync

mutex_unlock(>v4l2_lock);
if (waitqueue_active(>wq_stream))
/* The CPU might reorder the test for
   the waitqueue up here, before
   prior writes complete */
/* wait_event_interruptible */
 /* __wait_event_interruptible */
  /* ___wait_event */
  long __int = prepare_to_wait_event(
, &__wait, state);
  if (!cam->streaming ||
frame->status == FRAME_READY)
cam->curbuff->status = FRAME_READY;
cam->curbuff->length = 0;
  schedule()


The attached patch removes the call to waitqueue_active() leaving just
wake_up() behind.  This fixes the problem because the call to
spin_lock_irqsave() in wake_up() will be an ACQUIRE operation.

I found this issue when I was looking through the linux source code
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c  (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).

Signed-off-by: Kosuke Tatsukawa 
---
 drivers/media/usb/cpia2/cpia2_usb.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/cpia2/cpia2_usb.c 
b/drivers/media/usb/cpia2/cpia2_usb.c
index 351a78a..c1aa1ab 100644
--- a/drivers/media/usb/cpia2/cpia2_usb.c
+++ b/drivers/media/usb/cpia2/cpia2_usb.c
@@ -890,8 +890,7 @@ static void cpia2_usb_disconnect(struct usb_interface *intf)
DBG("Wakeup waiting processes\n");
cam->curbuff->status = FRAME_READY;
cam->curbuff->length = 0;
-   if (waitqueue_active(>wq_stream))
-   wake_up_interruptible(>wq_stream);
+   wake_up_interruptible(>wq_stream);
}
 
DBG("Releasing interface\n");
-- 
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

VB2 will returning -ERESTARTSYS to userland

2015-10-08 Thread Chetan Nanda 
Hi,

I am working on V4L2 base videodecoder,
I have two threads say A and B. Thread A is for configuration and
Thread B for queuing/de-queuing buffers.

In one usecase,
- Thread B is blocked on VIDIOC_DQBUF,
- and at same time Thread A do the flush and do, STREAMOFF, QBUF, STREAMON.

Once thread A do this, Thread B waked up (as a result of STREAMOFF)
and return -ERESTARTSYS (from wait_interrupt_interruptible) from
DQBUF.

ERESTARTSYS is for kernel internal and should not be passed to
userside, and even ERESTARTSYS is not available at user side.

Shouldn't VB2 catch ERESTARTSYS and return -RESTART or some other error?

Thanks,
Chetan Nanda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html