Hi York, On 16 July 2015 at 11:00, York Sun <york...@freescale.com> wrote: > > > On 07/16/2015 09:40 AM, Simon Glass wrote: >> Hi, >> >> On 16 July 2015 at 01:01, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: >>> Hello York, >>> >>> On Wed, 15 Jul 2015 13:26:46 -0700, York Sun <york...@freescale.com> >>> wrote: >>>> fdt_addr_t and fdt_size_t can be either 64-bit or 32-bit, depending >>>> on the architecture. Change the type to phys_addr_t and phys_size_t. >>> >>> If the only reason for changing the type is to avoid warnings in >>> debug() then I don't think this is the right approach (see my message >>> re PRIu64). >>> >>> If, on the other hand, there is reason to believe the fdt_addr_t and >>> fdt_size_t are wrongly defined and should be typedef'd or ~define's as >>> phys_*_t, then the rationale for this should be exposed. >>> >>> Amicalement, >>> -- >>> Albert. >> >> For LBA we do this in ide.h: >> >> #ifdef CONFIG_SYS_64BIT_LBA >> typedef uint64_t lbaint_t; >> #define LBAF "%llx" >> #define LBAFU "%llu" >> #else >> typedef ulong lbaint_t; >> #define LBAF "%lx" >> #define LBAFU "%lu" >> #endif >> >> How about something similar for this case? It would be nice to avoid >> promoting everything to 64-bit given that very few platforms are >> actually 64-bit. >> > > Simon, > > Do you think fdt_addr_t should be phys_addr_t? According to the comments you > put > in file, "A typedef for a physical address". If yes, I can change the commit > message.
Sounds good to me. > > On the other hand, if we want to keep the current typedef, we can use Albert's > PRIu64 technique, we then don't have to define the format string. The only reason for a difference typedef is the big endian nature of FDT data. So I think your patch is fine on that front. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
