[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Sat, Jul 28, 2012 at 11:08:31AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
>> > On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
>> > > We support booting a kernel on systems with or without SMP support, even
>> > > with a SMP kernel.  When the kernel is booted on such a system, it is
>> > > undefined whether smp_cross_call() is a valid function pointer.
>> >
>> > So let's define it to point at a dummy function which explodes with a BUG if
>> > the cpumask passed in isn't empty. That allows SMP kernels to do things like
>> > `cross call to all other cores' without having to worry about whether there
>> > are any other cores or not.
>>
>> We should not be even attempting to do any cross calls when there aren't
>> any other CPUs in the system - that's rather the point of leaving it as
>> a NULL pointer so it does explode on such systems.
>>
>> . the scheduler won't call smp_send_reschedule() when there are no other
>>   CPUs in the system.
>> . timer ticks won't be broadcast to other CPUs if there are no other CPUs
>>   in the system.
>> . function calls will not be issued to other CPUs if there are no other
>>   CPUs in the system.
>>
>> There is only one case where this doesn't happen, and that's the shutdown
>> path.
>
> Ok, that's a pretty compelling argument you've got there :)
>
>> For instance, smp_call_function*() all check that the target CPUs are
>> marked online before the arch code is requested to issue an IPI to the
>> target CPU.
>
> Yes, thanks for making the case for the original patch. Consistency is the
> most important thing with these APIs, so I'll go full circle and offer my
> ack for the original patch:
>
> Acked-by: Will Deacon <will.deacon at arm.com>
>
> The next question is: who's putting this into the patch system?
>
> Will

Hi,

I just put the patch with Will's Acked-by on the patch system. It  was
accepted as patch 7480/1 [1].

The patch is on top of today's linux-next (next-20120727).

Thanks a lot and best regards,
Javier

[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1