Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 23 3月, 2011 36 次提交
  3. 22 3月, 2011 4 次提交
    • A
      [media] drivers/media/video/tlg2300/pd-video.c: Remove second mutex_unlock in pd_vidioc_s_fmt · a07500ef
      由 Alexander Strakh 提交于 
      Error path in file drivers/media/video/tlg2300/pd-video.c:
1. First mutex_unlock on &pd->lock in line 767 (in function that
   called from line 805)
2. Second in line  806

 805        pd_vidioc_s_fmt(pd, &f->fmt.pix);
 806        mutex_unlock(&pd->lock);

Found by Linux Device Drivers Verification Project
Signed-off-by: NAlexander Strakh <strakh@ispras.ru>
Acked-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a07500ef
    • T
      [media] radio-wl1273: remove unused wl1273_device->work · 868e90d5
      由 Tejun Heo 提交于 
      wl1273_device->work is unused.  Remove it along with the spurious
flush_scheduled_work() call in wl1273_fm_module_exit().
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Matti Aaltonen <matti.j.aaltonen@nokia.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      868e90d5
    • J
      [media] Zarlink zl10036 DVB-S: Fix mem leak in zl10036_attach · 7e270941
      由 Jesper Juhl 提交于 
      On Thu, 17 Feb 2011, Matthias Schwarzott wrote:

> On Sunday 06 February 2011, Jesper Juhl wrote:
> > If the memory allocation to 'state' succeeds but we jump to the 'error'
> > label before 'state' is assigned to fe->tuner_priv, then the call to
> > 'zl10036_release(fe)' at the 'error:' label will not free 'state', but
> > only what was previously assigned to 'tuner_priv', thus leaking the memory
> > allocated to 'state'.
> > There are may ways to fix this, including assigning the allocated memory
> > directly to 'fe->tuner_priv', but I did not go for that since the
> > additional pointer derefs are more expensive than the local variable, so I
> > just added a 'kfree(state)' call. I guess the call to 'zl10036_release'
> > might not even be needed in this case, but I wasn't sure, so I left it in.
> >
> Yeah, that call to zl10036_release can be completely eleminated.
> Another thing is: jumping to the error label only makes sense when memory was
> already allocated. So the jump in line 471 can be replaced by "return NULL",
> as the other error handling before allocation:
>         if (NULL == config) {
>                 printk(KERN_ERR "%s: no config specified", __func__);
>                 goto error;
>         }
>
> I suggest to improve the patch to clean the code up when changing that.
>
> But I am fine with commiting this patch also if you do not want to change it.
>

Thank you for your feedback. It makes a lot of sense.
Changing it is not a problem :)
How about the updated patch below?

If the memory allocation to 'state' succeeds but we jump to the 'error'
label before 'state' is assigned to fe->tuner_priv, then the call to
'zl10036_release(fe)' at the 'error:' label will not free 'state', but
only what was previously assigned to 'tuner_priv', thus leaking the memory
allocated to 'state'.
This patch fixes the leak and also does not jump to 'error:' before mem
has been allocated but instead just returns. Also some small style
cleanups.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      7e270941
    • J
      [media] V4L: videobuf, don't use dma addr as physical · 35d9f510
      由 Jiri Slaby 提交于 
      mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU, as
a hardware IOMMU can (and most likely) will return a bus address where
physical != bus address.

So ensure we are remapping (remap_pfn_range) the right page in
__videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
mem->dma_handle.

While at it, use PFN_DOWN instead of explicit shift.

[mchehab@redhat.com: Fix compilation breakage due to the lack of a comma]
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      35d9f510