Thread (20 messages) flat view 20 messages, 3 authors, 2011-06-09
STALE5578d

[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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help