On 10/27/2015 04:46 PM, Rob Herring wrote: > On Fri, Oct 23, 2015 at 8:15 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: >> Hi Masahiro, >> >> On 10/23/2015 07:47 AM, Masahiro Yamada wrote: >>> fdt_translate_address() returns OF_BAD_ADDR on error. It is defined as >>> a u64 value, so the variable "addr" should be defined as u64 as well. >> >> Good catch. >> >> I would prefer if fdt_translate_address() returned resource_size_t (which >> is the proper type for handling addresses as integers) and that type >> was propagated through early_init_dt_scan_chosen_serial => of_setup_earlycon. > > That can be problematic in the DT code. The size of resource_size_t > can vary on 32-bit as it is based on phys_addr_t which in turn is > based on CONFIG_LPAE setting. However, the address sizes in DT are > fixed and may be 64-bit. So we stick with u64 in the DT code. I think I see your point about fdt_translate_address(); you want it to mirror of_translate_address(), yes? If so, then I have no objection to this patch and will mark it reviewed. But the u64 value from fdt_translate_address() should be preserved at least to the ioremap()/set_fixmap() in earlycon_map() . I could roll that change into my earlycon series that moves fdt_translate_address() into of_setup_earlycon(), thus preserving the u64 value until it's assigned to a phys_addr_t. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
