| Message ID | 1318453063-17349-1-git-send-email-galak@kernel.crashing.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Kumar Gala |
| Headers | show |
On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala <galak@kernel.crashing.org> wrote: > From: Kai Jiang <Kai.Jiang@freescale.com> > > To support >32-bit physical addresses for UIO_MEM_PHYS type we need to > extend the width of 'addr' in struct uio_mem. Numerous platforms like > embedded PPC, ARM, and X86 have support for systems with larger physical > address than logical. > > Since 'addr' may contain a physical, logical, or virtual address the > easiest solution is to just change the type to 'unsigned long long' > regardless of which type is utilized. You forgot to update this description. > struct uio_mem { > const char *name; > - unsigned long addr; > + phys_addr_t addr; Please add a comment here saying: 1) That 'addr' can be a virtual or physical address 2) That the kernel guarantees that sizeof(phys_addr_t) >= sizeof(void *), so it's safe to use phys_addr_t for a virtual pointer.
On Oct 13, 2011, at 9:37 AM, Tabi Timur-B04825 wrote: > On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala <galak@kernel.crashing.org> wrote: >> From: Kai Jiang <Kai.Jiang@freescale.com> >> >> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to >> extend the width of 'addr' in struct uio_mem. Numerous platforms like >> embedded PPC, ARM, and X86 have support for systems with larger physical >> address than logical. >> >> Since 'addr' may contain a physical, logical, or virtual address the >> easiest solution is to just change the type to 'unsigned long long' >> regardless of which type is utilized. > > You forgot to update this description. will fix and update commit message > >> struct uio_mem { >> const char *name; >> - unsigned long addr; >> + phys_addr_t addr; > > Please add a comment here saying: > > 1) That 'addr' can be a virtual or physical address The code and everything else makes that clear > 2) That the kernel guarantees that sizeof(phys_addr_t) >= sizeof(void > *), so it's safe to use phys_addr_t for a virtual pointer. The commit message will cover that so I don't plan on add it. - k
Kumar Gala wrote: >>> >> + phys_addr_t addr; >> > >> > Please add a comment here saying: >> > >> > 1) That 'addr' can be a virtual or physical address > The code and everything else makes that clear I'm sorry, but I have to strongly disagree here. It is *NOT* clear that a variable of type 'phys_addr_t' can hold something that is not a physical address.
> Kumar Gala wrote: > >>> >> + phys_addr_t addr; > >> > > >> > Please add a comment here saying: > >> > > >> > 1) That 'addr' can be a virtual or physical address > > The code and everything else makes that clear > > I'm sorry, but I have to strongly disagree here. It is *NOT* > clear that a variable of type 'phys_addr_t' can hold something > that is not a physical address. Since there is a discriminating field, could a union be used? At a guess the type of the address is constrained between produces and consumer?? David
On Oct 13, 2011, at 10:37 AM, David Laight wrote: > >> Kumar Gala wrote: >>>>>>> + phys_addr_t addr; >>>>> >>>>> Please add a comment here saying: >>>>> >>>>> 1) That 'addr' can be a virtual or physical address >>> The code and everything else makes that clear >> >> I'm sorry, but I have to strongly disagree here. It is *NOT* >> clear that a variable of type 'phys_addr_t' can hold something >> that is not a physical address. > > Since there is a discriminating field, could a union be used? > At a guess the type of the address is constrained between > produces and consumer?? Uugh. I'll add a comment to uio_mem. - k
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 7c4b514d..54883de 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -529,7 +529,7 @@ memory (e.g. allocated with <function>kmalloc()</function>). There's also </para></listitem> <listitem><para> -<varname>unsigned long addr</varname>: Required if the mapping is used. +<varname>phys_addr_t addr</varname>: Required if the mapping is used. Fill in the address of your memory block. This address is the one that appears in sysfs. </para></listitem> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index 88f4444..43b7096 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf) static ssize_t map_addr_show(struct uio_mem *mem, char *buf) { - return sprintf(buf, "0x%lx\n", mem->addr); + return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr); } static ssize_t map_size_show(struct uio_mem *mem, char *buf) @@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf) static ssize_t map_offset_show(struct uio_mem *mem, char *buf) { - return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK); + return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr & ~PAGE_MASK); } struct map_sysfs_entry { @@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf) if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL) page = virt_to_page(idev->info->mem[mi].addr + offset); else - page = vmalloc_to_page((void *)idev->info->mem[mi].addr - + offset); + page = vmalloc_to_page((void *)(unsigned long) + idev->info->mem[mi].addr + offset); get_page(page); vmf->page = page; return 0; diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h index 4c618cd..d9ce796 100644 --- a/include/linux/uio_driver.h +++ b/include/linux/uio_driver.h @@ -32,7 +32,7 @@ struct uio_map; */ struct uio_mem { const char *name; - unsigned long addr; + phys_addr_t addr; unsigned long size; int memtype; void __iomem *internal_addr;