On Wed, Apr 30, 2014 at 6:07 PM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Apr 30, 2014 at 02:33:21PM -0600, Bjorn Helgaas wrote: >> dma_declare_coherent_memory() takes two addresses for a region of memory: a >> "bus_addr" and a "device_addr". I think the intent is that "bus_addr" is >> the physical address a *CPU* would use to access the region, and >> "device_addr" is the bus address the *device* would use to address the >> region. >> >> Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t. > > Isn't this going to cause problems with the callers of this function? > You aren't changing them... Sorry, I should have mentioned that in the changelog. This could cause a problem if it changed "bus_addr" to a smaller type, e.g., in a config where dma_addr_t was 64 bits but phys_addr_t was only 32. In that config (if it exists), this change would truncate the address if a caller supplied a 64-bit dma_addr_t. But most of the callers in the tree already supply a phys_addr_t (or the equivalent resource_size_t), and the rest supply 32-bit int values, so I don't think there's a problem here. This change could theoretically *fix* a problem in a config with 32-bit dma_addr_t and 64-bit phys_addr_t. In that case we could previously have truncated a phys_addr_t, and this change would fix it. But I don't know of any issues like this. Here are the 16 callers in the tree: 4 in arch/arm/mach-imx/mach-imx27_visstrim_m10.c (phys_addr_t) 3 in arch/arm/mach-imx/mach-mx31_3ds.c (phys_addr_t) 1 in arch/arm/mach-imx/mach-pcm037.c (phys_addr_t) 1 in arch/arm/plat-samsung/s5p-dev-mfc.c (phys_addr_t) 1 in arch/sh/drivers/pci/fixups-dreamcast.c (#define constant) 2 in drivers/media/platform/s5p-mfc/s5p_mfc.c (unsigned int from OF property) 1 in drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c (struct resource.start) 1 in drivers/scsi/NCR_Q720.c (__u32 memory address computed from I/O port values) 1 in drivers/usb/host/ohci-sm501.c (struct resource.start) 1 in drivers/usb/host/ohci-tmio.c (struct resource.start) Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
