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.
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 .
