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