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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
