[PATCH] boot: fdt: Turn all addresses and sizes into u64

[Marek Vasut]

On 4/14/24 11:28 PM, Laurent Pinchart wrote:
> On Sun, Apr 14, 2024 at 11:25:06PM +0200, Marek Vasut wrote:
>> On 4/14/24 9:29 PM, Laurent Pinchart wrote:
>>> Hi Marek,
>>>
>>> Thank you for the patch.
>>>
>>> On Sun, Apr 14, 2024 at 08:37:20PM +0200, Marek Vasut wrote:
>>>> In case of systems where DRAM bank ends at the edge of 32bit boundary,
>>>> start + size calculations would overflow. This happens on STM32MP15xx
>>>> with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a
>>>> usual 32bit system DRAM size overflow, fix it by doing all DRAM size
>>>> and offset calculations using u64 types.
>>>
>>> I'm not sure I like this much, as it removes a useful indication
>>> regarding what the variables store.
>>
>> That's what the variable name is for, not variable type.
>>
>>> Wouldn't it be better if the code's
>>> logic could be modified to avoid those overflows ?
>>
>> I'd prefer to keep the code simple and blanket avoid the overflows for a
>> very long time, rather than play whack-a-mole with various odd corner
>> cases here.
> 
> Up to you.
> 
>> Note that this is a fix for a previous series which changed from
>> u64/ulong to phys_addr/size_t , which clearly was incorrect .
>>
>>>> This also covers a case where
>>>> a 32bit PAE system might be able to address up to 36bits of DRAM.
>>>
>>> Shouldn't phys_addr_t be a 64-bit type on PAE systems ?
>>
>> That depends on CONFIG_PHYS_64BIT , on am57xx this is not set for
>> example, so there phys_addr_t is 32bit .
> 
> The system won't be able to address more than 32 bits of memory in that
> case, would it ?

It might do so through some memory window, like PCIe, but I never used 
the am57xx so I cannot tell what it really does.