From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerry Van Baren <gerald.vanbaren@ge.com>
Date: Wed, 12 Mar 2008 15:23:05 -0400
Subject: [U-Boot-Users] [RFC/PATCH] fix initdram / use of phys_addr_t
In-Reply-To: <96DCB2C0-3028-4A5B-A6F4-5CC3767A5040@kernel.crashing.org>
References: <20080312184021.4562624234@gemini.denx.de>
	<96DCB2C0-3028-4A5B-A6F4-5CC3767A5040@kernel.crashing.org>
Message-ID: <47D82D99.3050703@ge.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Kumar Gala wrote:
> On Mar 12, 2008, at 1:40 PM, Wolfgang Denk wrote:
> 
>> Dear Kumar,
>>
>> in message <Pine.LNX. 
>> 4.64.0803121037440.13065 at blarg.am.freescale.net> you wrote:
>>> The idea is that initdram() should really have returned a 'unsigned  
>>> long'.
>>> However if we are going to change everyone that has initdram I  
>>> figure we
>>> should make it return a phys_addr_t.
>> Um, no, I don't think so.
> 
> would phys_size_t be better?
> 
>>> +phys_addr_t initdram(int board_type)
>>> {
>>> -	long dram_size = 0;
>>> +	phys_addr_t dram_size = 0;
>> No - initdram() does not return an address, it returns a size.
> 
> Sure, I understand it returns a size.  I was just using phys_addr_t to  
> represent the type for both addresses and sizes.
> 
> - k

Shouldn't we just use size_t to return the size of what is effectively 
an array of /n/ bytes of RAM?  (Does size_t's baggage WRT different C 
standards and different C compilers cause more grief than it solves?)

gvb