On Wed, Oct 17, 2012 at 03:12:17PM -0600, Stephen Warren wrote:

That implies we really do need to keep the two pieces of code completely
in sync, so a shared header is the right way to go. It also implies that
having duplicate mappings of the same physical address doesn't cause any
immediate obvious catastrophic problems.

Ways we might avoid files in arch/arm/include/debug having to use
relative include paths to pick up that header are:

Why not take the opposite approach.  Treat the platform as setting up the
addresses for the UART.  Then arrange for the debug macros to match that.
Or we define a common virtual address for debug UARTs (which platforms
would not be able to use).

b) Rework debug-macro.S so that it isn't an include file, but rather a
regular top-level file.

No, that won't work.  It's used in two places - the kernel and the
decompressor.  Hence why it is an include file (it's not an include
file just for the fun of it.)