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

[Frank Hofmann]

On Wed, 8 Jun 2011, Dave Martin wrote:

> On Wed, Jun 08, 2011 at 05:10:05PM +0100, Frank Hofmann wrote:
[ ... ]
>> 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.
>
> The preprocessor won't expand a macro name unless it appears as a separate
> token, surely?
>
> So if I have
>
> #define cpu_reset processor.reset
>
> then
>
> 	cpu_reset(graphics_cpu_reset)
>
> expands to
>
> 	processor.reset(graphics_cpu_reset)
>
> Which is the intention (even if it's a stupid example)

Ah, I was concerned that it'd change

 	graphics_cpu_reset ===> graphics_processor.reset

but you're correct that kind of substitution is not happening.

Anyway as Will mentioned, the !MULTI_CPU case has the #define the 
following way in any case:

#define	____glue(name,fn)	name##fn
#define	__glue(name,fn)		____glue(name,fn)
#define	cpu_reset		__glue(CPU_NAME,_reset)

I.e. in the !MULTI_CPU case cpu_reset is defined without the macro 
argument, while the MULTI_CPU define _has_ the macro argument.

Would it be ok to remove the (args) part from the MULTI_CPU #define then ?

Thanks,
FrankH.

>
> Cheers
> ---Dave
>
>