Re: [PATCH] Staging: TIDSPBRIDGE: Remove UUID helper

2013-12-08 Thread Pavel Machek
Hi!

> > >> I guess the initial mail somehow didn't make it through your spam filter:
> > >> https://lkml.org/lkml/2013/12/1/70
> > > It did, but I thought that people asked for it to be changed in the
> > > thread afterwards, so I was expecting an updated version from you.
> > >
> > > Care to fix things up and resend it?
> > >
> > > thanks,
> > >
> > > greg k-h
> > 
> > Sure, the change I was asked for is trivial, but I didn't get the reason 
> > why it is needed. Neither there is a reply to my follow-up comment [0]. 
> > Sorry, I am pretty much new on LKML and could miss things that are 
> > supposed to be clear from the start, but my impression is that when 
> > someone says "it is better", he/she should explain why it is better or 
> > at least what is wrong with the patch he/she wants  to be changed.
> > 
> > However, I don't want to enter some arguing loop, so if you think I 
> > should change the code as per Joe's comment, just confirm it and I'll do it.
> 
> Please try.

Not checking sscanf() return is un-nice, so yes, it would be nice to
fix it, even if it will not happen in practice. 0 / -EINVAL is
acceptable return value.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Staging: TIDSPBRIDGE: Use vm_iomap_memory for mmap-ing instead of remap_pfn_range

2013-12-08 Thread Ivajlo Dimitrov


On 08.12.2013 01:49, Steven Luo wrote:

This patch causes problems with DSP codecs on OMAP3 devices running
Android -- specifically, when the decoder is cleaning up after itself,
munmap() of the mapped area fails, leading to a memory leak which
eventually crashes the system.

As far as I can tell, the code with this patch applied reduces to
(ignoring checks and such)

remap_pfn_range(vma, vma->vm_start,
(pdata->phys_mempool_base >> PAGE_SHIFT) + vma->vm_pgoff,
vma->vm_end - vma->vm_start,
vma->vm_page_prot);

whereas the original was


-   status = remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
-vma->vm_end - vma->vm_start,
-vma->vm_page_prot);

We're subtracting (pdata->phys_mempool_base >> PAGE_SHIFT) from
vma->vm_pgoff before calling vm_iomap_memory() to address the issue --
if that's satisfactory to everyone involved, I can submit the following
patch.

-Steven Luo

(please cc, not subscribed)

From: Steven Luo 
Date: Sat, 7 Dec 2013 02:11:20 -0800
Subject: [PATCH] tidspbridge: fix last patch to map same region of physical
  memory as before

Commit 559c71fe5dc3 ("Staging: TIDSPBRIDGE: Use vm_iomap_memory for
mmap-ing instead of remap_pfn_range") had the effect of inadvertently
shifting the start of the physical memory area mapped by
pdata->phys_mempool_base.  Correct this by subtracting that shift before
calling vm_iomap_memory() and adding it back afterwards.

Reported-by: Dheeraj CVR 
Signed-off-by: Steven Luo 
---
  drivers/staging/tidspbridge/rmgr/drv_interface.c |   29 +++---
  1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c 
b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index 83cc3a5..d7f7d04 100644
--- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
+++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
@@ -258,6 +258,9 @@ err:
  /* This function maps kernel space memory to user space memory. */
  static int bridge_mmap(struct file *filp, struct vm_area_struct *vma)
  {
+   unsigned long base_pgoff;
+   int status;
+
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;

@@ -269,9 +272,29 @@ static int bridge_mmap(struct file *filp, struct 
vm_area_struct *vma)
vma->vm_start, vma->vm_end, vma->vm_page_prot,
vma->vm_flags);
  
-	return vm_iomap_memory(vma,

-  pdata->phys_mempool_base,
-  pdata->phys_mempool_size);
+   /*
+* vm_iomap_memory() expects vma->vm_pgoff to be expressed as an offset
+* from the start of the physical memory pool, but we're called with
+* a pfn (physical page number) stored there instead.
+*
+* To avoid duplicating lots of tricky overflow checking logic,
+* temporarily convert vma->vm_pgoff to the offset vm_iomap_memory()
+* expects, but restore the original value once the mapping has been
+* created.
+*/
+   base_pgoff = pdata->phys_mempool_base >> PAGE_SHIFT;
+   if (vma->vm_pgoff < base_pgoff)
+   return -EINVAL;
+   vma->vm_pgoff -= base_pgoff;
+
+   status = vm_iomap_memory(vma,
+pdata->phys_mempool_base,
+pdata->phys_mempool_size);
+
+   /* Restore the original value of vma->vm_pgoff */
+   vma->vm_pgoff += base_pgoff;
+
+   return status;
  }
  
  static const struct file_operations bridge_fops = {

Tested on Nokia N900 with Maemo 5 and Harmattan codec nodes
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/7 v2] staging: et131x: reduce split lines in et131x_config_rx_dma_regs

2013-12-08 Thread Mark Einon
On Sat, Dec 07, 2013 at 05:22:57PM +0800, ZHAO Gang wrote:
> Signed-off-by: ZHAO Gang 

Thanks.

Acked-by: Mark Einon 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 3/7 RESEND] staging: et131x: reduce split lines in et131x_rx_dma_memory_free

2013-12-08 Thread Mark Einon
On Sat, Dec 07, 2013 at 09:37:25AM +0800, ZHAO Gang wrote:
> Signed-off-by: ZHAO Gang 

Thanks. This also has RESEND in the subject, instead of v2. But only
update this if someone else complains. If not:

Acked-by: Mark Einon 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/7 v2] staging: et131x: reduce split lines in et131x_config_rx_dma_regs

2013-12-08 Thread Mark Einon
On Sat, Dec 07, 2013 at 05:22:57PM +0800, ZHAO Gang wrote:
> Signed-off-by: ZHAO Gang 

Thanks for updating the patch.

Acked-by: Mark Einon 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel