Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

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

Browse source 
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>
This commit is contained in:
Nicolas Pitre 2005-10-17 22:03:19 +01:00 committed by Thomas Gleixner
parent d574504114
commit fb0258730a
1 changed files with 8 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
include/linux/mtd/xip.h
View 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__
@ -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