[U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB

[Marek Vasut]

On 06/19/2018 07:52 AM, Chee, Tien Fong wrote:
> On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote:
>> On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.chee at intel.com
>> wrote:
>>
>>>
>>> From: Tien Fong Chee <tien.fong.chee at intel.com>
>>>
>>> In ARM 64-bits, memory size can be supported is more than 4GB,
>>> hence increasing save array is needed to cope with testing larger
>>> memory.
>>>
>>> Signed-off-by: Tien Fong Chee <tien.fong.chee at intel.com>
>>> ---
>>>  common/memsize.c |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/common/memsize.c b/common/memsize.c
>>> index 5670e95..b091203 100644
>>> --- a/common/memsize.c
>>> +++ b/common/memsize.c
>>> @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>>  long get_ram_size(long *base, long maxsize)
>>>  {
>>>  	volatile long *addr;
>>> -	long           save[31];
>>> +	long           save[BITS_PER_LONG];
>>>  	long           save_base;
>>>  	long           cnt;
>>>  	long           val;
>> Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here?  Or
>> are you saying there's also a case where this is wrong on 32bit
>> today?
> As long as the array is large enough to cope with shifting
> implementation, then it should be fine. For 32-bit, only 31 units in
> array required for storing 31 shifting values, and this apply for 64-
> bit also as long as the implementation of first shifting value is not
> change(cnt = (maxsize / sizeof(long)) >> 1).
> IMO, for simplifying and safety purpose(may be one day implementation
> change to "cnt = (maxsize / sizeof(long))", above B_P_L is still
> workable.

That's BS reasoning and just sloppy programming. I agree with Tom.

-- 
Best regards,
Marek Vasut