[U-Boot] [RFC] lib/fdtdec: Fix compiling warning for debug

Simon Glass sjg at chromium.org
Thu Jul 16 19:10:11 CEST 2015


Hi York,

On 16 July 2015 at 11:00, York Sun <yorksun at 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.boot at aribaud.net> wrote:
>>> Hello York,
>>>
>>> On Wed, 15 Jul 2015 13:26:46 -0700, York Sun <yorksun at 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


More information about the U-Boot mailing list