Re: single, comprehensive kernel data types document?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Rob



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux