diff mbox

[RFC,1/4] ARM: Allow assembler.h to be used with inline asm

Message ID 1381328993-12724-2-git-send-email-Dave.Martin@arm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dave Martin Oct. 9, 2013, 2:29 p.m. UTC
There are a few things in assembler.h that would be useful with
inline asm, but currently assembler.h refuses to be included into C
files.

In particular, the optional feature macros (PLD() and friends) can
be used sensibly with inline asm, with a string argument.

This patch enables the relevant parts of aassembler.h to be
included in C files and used in inline asm.

Since assembler.h by definition can't be included in any C file up
to now, this should not introduce any namespace clashes.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm/include/asm/assembler.h |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Comments

Russell King - ARM Linux Oct. 9, 2013, 2:42 p.m. UTC | #1
On Wed, Oct 09, 2013 at 03:29:50PM +0100, Dave Martin wrote:
> There are a few things in assembler.h that would be useful with
> inline asm, but currently assembler.h refuses to be included into C
> files.
> 
> In particular, the optional feature macros (PLD() and friends) can
> be used sensibly with inline asm, with a string argument.
> 
> This patch enables the relevant parts of aassembler.h to be
> included in C files and used in inline asm.
> 
> Since assembler.h by definition can't be included in any C file up
> to now, this should not introduce any namespace clashes.

I think it would be better to move the two macros (PLD and CALGN) out of
this file, rather than covering almost the entire file with this #ifdef.
Dave Martin Oct. 9, 2013, 3 p.m. UTC | #2
On Wed, Oct 09, 2013 at 03:42:11PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 09, 2013 at 03:29:50PM +0100, Dave Martin wrote:
> > There are a few things in assembler.h that would be useful with
> > inline asm, but currently assembler.h refuses to be included into C
> > files.
> > 
> > In particular, the optional feature macros (PLD() and friends) can
> > be used sensibly with inline asm, with a string argument.
> > 
> > This patch enables the relevant parts of aassembler.h to be
> > included in C files and used in inline asm.
> > 
> > Since assembler.h by definition can't be included in any C file up
> > to now, this should not introduce any namespace clashes.
> 
> I think it would be better to move the two macros (PLD and CALGN) out of
> this file, rather than covering almost the entire file with this #ifdef.

Certainly we could do that.  When I started this hack, I though that a
larger proportion of the file would be relevant...

Any thoughts on a sensible name?  asm/asm-common.h, maybe?

Cheers
---Dave
Nicolas Pitre Oct. 9, 2013, 3:32 p.m. UTC | #3
On Wed, 9 Oct 2013, Dave Martin wrote:

> On Wed, Oct 09, 2013 at 03:42:11PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Oct 09, 2013 at 03:29:50PM +0100, Dave Martin wrote:
> > > There are a few things in assembler.h that would be useful with
> > > inline asm, but currently assembler.h refuses to be included into C
> > > files.
> > > 
> > > In particular, the optional feature macros (PLD() and friends) can
> > > be used sensibly with inline asm, with a string argument.
> > > 
> > > This patch enables the relevant parts of aassembler.h to be
> > > included in C files and used in inline asm.
> > > 
> > > Since assembler.h by definition can't be included in any C file up
> > > to now, this should not introduce any namespace clashes.
> > 
> > I think it would be better to move the two macros (PLD and CALGN) out of
> > this file, rather than covering almost the entire file with this #ifdef.
> 
> Certainly we could do that.  When I started this hack, I though that a
> larger proportion of the file would be relevant...
> 
> Any thoughts on a sensible name?  asm/asm-common.h, maybe?

Since there is no need for CALGN() or PLD() in C code yet, maybe it is 
best to leave them where they are for the time being.

And then adding __asm_swab32() to opcodes.h feels quite natural with the 
purpose of that file's content.  Then including that fine to solve the 
CCI code endianness should be fine.

If anything, maybe it is the name opcodes.h which is misrepresenting the 
scope of its content.


Nicolas
diff mbox

Patch

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index fcc1b5b..a71d117 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -16,14 +16,12 @@ 
 #ifndef __ASM_ASSEMBLER_H__
 #define __ASM_ASSEMBLER_H__
 
-#ifndef __ASSEMBLY__
-#error "Only include this from assembly code"
-#endif
-
 #include <asm/ptrace.h>
 #include <asm/domain.h>
 #include <asm/opcodes-virt.h>
 
+#ifdef __ASSEMBLY__
+
 #define IOMEM(x)	(x)
 
 /*
@@ -53,6 +51,8 @@ 
 #define put_byte_3      lsl #0
 #endif
 
+#endif /* __ASSEMBLY__ */
+
 /*
  * Data preload for architectures that support it
  */
@@ -77,6 +77,8 @@ 
 #define CALGN(code...)
 #endif
 
+#ifdef __ASSEMBLY__
+
 /*
  * Enable and disable interrupts
  */
@@ -376,4 +378,6 @@  THUMB(	orr	\reg , \reg , #PSR_T_BIT	)
 #endif
 	.endm
 
+#endif /* __ASSEMBLY__ */
+
 #endif /* __ASM_ASSEMBLER_H__ */