[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1244189111-19639-58-git-send-email-vapier@gentoo.org>
Date: Fri, 5 Jun 2009 04:05:06 -0400
From: Mike Frysinger <vapier@...too.org>
To: linux-kernel@...r.kernel.org
Cc: uclinux-dist-devel@...ckfin.uclinux.org
Subject: [PATCH 57/62] Blackfin: push access_ok() L1 attribute down
There is no need for the L1 attribute to be on the prototype of the
access_ok() function as all consumers of the function do not care where it
lives -- they'll always use pcrel calls to get to it. This prevents
pointless recompiles of most of the system when this config option changes.
Signed-off-by: Mike Frysinger <vapier@...too.org>
---
arch/blackfin/include/asm/uaccess.h | 4 ----
arch/blackfin/kernel/process.c | 3 +++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/blackfin/include/asm/uaccess.h b/arch/blackfin/include/asm/uaccess.h
index 01f42b0..8894e9f 100644
--- a/arch/blackfin/include/asm/uaccess.h
+++ b/arch/blackfin/include/asm/uaccess.h
@@ -59,12 +59,8 @@ static inline int is_in_rom(unsigned long addr)
#ifndef CONFIG_ACCESS_CHECK
static inline int _access_ok(unsigned long addr, unsigned long size) { return 1; }
#else
-#ifdef CONFIG_ACCESS_OK_L1
-extern int _access_ok(unsigned long addr, unsigned long size)__attribute__((l1_text));
-#else
extern int _access_ok(unsigned long addr, unsigned long size);
#endif
-#endif
/*
* The exception table consists of pairs of addresses: the first is the
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index e040e03..30d0843 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -322,6 +322,9 @@ void finish_atomic_sections (struct pt_regs *regs)
}
#if defined(CONFIG_ACCESS_CHECK)
+#ifdef CONFIG_ACCESS_OK_L1
+__attribute__((l1_text))
+#endif
/* Return 1 if access to memory range is OK, 0 otherwise */
int _access_ok(unsigned long addr, unsigned long size)
{
--
1.6.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists