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

[Laurent Pinchart]

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 ?

-- 
Regards,

Laurent Pinchart