On Thu, Apr 21, 2016 at 08:51:04AM -0400, Rob Groner wrote:
On Thu, 2016-04-21 at 11:51 +0900, Greg KH wrote:
On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote:
Sorry if this isn't related, it seemed like it was...
I recently discovered one of our drivers isn't written correctly for 64-bit. It uses a uint32_t to hold an address. Whoops.
In previous drivers when I've needed to hold an address, I've used an "unsigned long", as (so far as I could tell) that would give me the correct number of bytes whether on 32 or 64-bit systems.
Now that I have to fix this driver, I'd rather do whatever the "standard" method is for storing an address value.
Looking at code in the kernel and linux/types.h, I see "phys_addr_t and dma_addr_t. Is that what I want to use? What if it's a virtual address? void *?
You want to use '__u64' and cast properly within the kernel to a pointer.
hope this helps,
greg k-h
Thank you Greg.
I was thinking there was a type that would hold a memory address (like an allocated DMA buffer address, or a PCI address) that would be the correct size on a 32-bit or 64-bit system without me having to specify a size. If I use __u64 to hold a memory address, won't that be the wrong size on a 32-bit system?
As Josh says, this is fine, you just "burn" 4 bytes, but you need to do that anyway for alignment and you save for not having a 'compat ioctl' callback to do the pointer fixup that would be required if you were to use a 32bit value for a pointer. And also, as Josh says, consider mixed user/kernel sizes, that gets messy very quickly, so just always make pointers 64bits and all works just fine. hope this helps, greg k-h