[PATCH 4/6] ARM: reset: add reset functionality for jumping to a physical address

[Frank Hofmann]

On Wed, 8 Jun 2011, Will Deacon wrote:

> On Wed, Jun 08, 2011 at 04:55:11PM +0100, Frank Hofmann wrote:
>>
>>
>> On Tue, 7 Jun 2011, Frank Hofmann wrote:
>>
>>>
>>>
>>> On Tue, 7 Jun 2011, Dave Martin wrote:
>> [ ... ]
>>>> How about:
>>>>
>>>> 	typeof(cpu_reset) *phys_reset =
>>>> 		(typeof(cpu_reset) *)virt_to_phys(cpu_reset);
>>>
>>> Function pointers ;-)
>>> Thanks.
>>
>> Hmmm ...
>>
>> Just found a problem with this.
>>
>> If you have a MULTI_CPU config, this doesn't compile. For two reasons:
>>
>> 1. you cannot use cpu_reset as argument to virt_to_phys because you can't
>>     take the address
>>     That bit can be fixed by changing the MULTI_CPU #define in
>>     <asm/proc-fns.h> not to include the macro argument.
>>     (There is no code in the arm tree using cpu_reset_whatever names which
>>     would break from that change ... still, not that nice)
>>
>> 2. even when you do that, you loose the "typeof()" information and the
>>     above still doesn't compile.
>>
>> Only a manual type override,
>>
>>  	void (*phys_reset)(unsigned long) = (void (*)(unsigned long))cpu_reset;
>>
>> is accepted then.
>
> Damn, yes, I assumed the MULTI_CPU case would just pointer at the structure field,
> but it takes the argument as parameter for the invocation. Oh well, I'll hardcode
> the type after all then!

It's not just that - the worse bit is that as long as the #define looks 
like:

#define	cpu_reset(addr)		processor.reset(addr)

compile is being refused; one has to ditch the argument part of the macro 
to be able to take the address.

I'm unsure how desirable that change is; it's got the unwanted consequence 
that people who decide to use function names like "graphics_cpu_reset" or 
"cpu_reset_specialregisters" would fall flat on their face.

As said, not that anyone does so right now; just not nice to introduce 
such behaviour.

FrankH.

>
> I'll send a v2 once I've finished cleaning up the code as I've tried to make it
> more useful following on from your earlier feedback.
>
> Cheers,
>
> Will
>