[PATCH 4/6] ARM: reset: add reset functionality for jumping to a physical address
From: Frank Hofmann <hidden>
Date: 2011-06-09 10:00:56
On Wed, 8 Jun 2011, Dave Martin wrote:
On Wed, Jun 08, 2011 at 05:10:05PM +0100, Frank Hofmann wrote:
[ ... ]
quoted
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