From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 28 Jul 2009 16:47:40 -0500
Subject: [U-Boot] [PATCH 1/2] Removed CONFIG_NUM_CPUS for 85xx and 86xx
 Freescale processors.
In-Reply-To: <1BD5CFC378ED0946B688E0C9BA2EF09512A4D7@zin33exm24.fsl.freescale.net>
References: <1BD5CFC378ED0946B688E0C9BA2EF09512A4D7@zin33exm24.fsl.freescale.net>
Message-ID: <4A6F71FC.3020209@freescale.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

Aggrwal Poonam-B10812 wrote:
>  
> 
>> -----Original Message-----
>> From: Wood Scott-B07421 
>> Sent: Wednesday, July 29, 2009 2:39 AM
>> To: Aggrwal Poonam-B10812
>> Cc: u-boot at lists.denx.de
>> Subject: Re: [U-Boot] [PATCH 1/2] Removed CONFIG_NUM_CPUS for 
>> 85xx and 86xx Freescale processors.
>>
>> On Tue, Jul 21, 2009 at 04:17:43PM +0530, Poonam Aggrwal wrote:
>>> +int cpu_numcores() {
>>> +	struct cpu_type *cpu;
>>> +	cpu = gd->cpu;
>>> +	return cpu->num_cores;
>>> +}
>> Shouldn't this check CONFIG_MP and return 1 if not set?  
>> Otherwise you get a weird mix of MP and UP.
>>
>> The checks to warn the user of a UP u-boot on an MP chip 
>> would have to reference cpu->num_cores directly, or we could 
>> add a hard_cpu_numcores(), or similar.
> This function's intent is to just return the number of cores that the
> system has.
> This is more of kind of probong the actual hardware.
> The CONFIG_MP flag will take care of all the multicore stuff in u-boot.
>> -Scott

But you have places that call cpu_numcores() and do per-core stuff that 
don't check CONFIG_MP, as far as I can tell.

-Scott