[MTD] Don't let gcc inline functions marked __xipram
authorNicolas Pitre <nico@cam.org>
Mon, 17 Oct 2005 21:03:19 +0000 (22:03 +0100)
committerThomas Gleixner <tglx@mtd.linutronix.de>
Sun, 6 Nov 2005 22:12:57 +0000 (23:12 +0100)
If they get inlined into non __xipram functions we're screwed.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
include/linux/mtd/xip.h

index 7b7deef6b180a920fd491f1d1d1660cf2b848745..863fa5a1d24ea6a8aacd646f993c1f8fe765cc82 100644 (file)
@@ -12,7 +12,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  *
- * $Id: xip.h,v 1.2 2004/12/01 15:49:10 nico Exp $
+ * $Id: xip.h,v 1.4 2005/10/17 21:03:16 nico Exp $
  */
 
 #ifndef __LINUX_MTD_XIP_H__
 
 #ifdef CONFIG_MTD_XIP
 
-/*
- * Function that are modifying the flash state away from array mode must
- * obviously not be running from flash.  The __xipram is therefore marking
- * those functions so they get relocated to ram.
- */
-#define __xipram __attribute__ ((__section__ (".data")))
-
 /*
  * We really don't want gcc to guess anything.
  * We absolutely _need_ proper inlining.
  */
 #include <linux/compiler.h>
 
+/*
+ * Function that are modifying the flash state away from array mode must
+ * obviously not be running from flash.  The __xipram is therefore marking
+ * those functions so they get relocated to ram.
+ */
+#define __xipram noinline __attribute__ ((__section__ (".data")))
+
 /*
  * Each architecture has to provide the following macros.  They must access
  * the hardware directly and not rely on any other (XIP) functions since they