Commit fb025873 authored by Nicolas Pitre's avatar Nicolas Pitre Committed by Thomas Gleixner

[MTD] Don't let gcc inline functions marked __xipram

If they get inlined into non __xipram functions we're screwed.
Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
parent d5745041
......@@ -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__
......@@ -22,19 +22,19 @@
#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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment