Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
kernel-fxtec-pro1x/arch/arm/mm/proc-syms.c

54 lines
1.2 KiB
C
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 16:20:36 -06:00
/*
* linux/arch/arm/mm/proc-syms.c
*
* Copyright (C) 2000-2002 Russell King
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/module.h>
#include <linux/mm.h>
#include <asm/cacheflush.h>
#include <asm/proc-fns.h>
#include <asm/tlbflush.h>
[ARM] 3737/1: Export ARM copy/clear_user_page symbols Patch from George G. Davis As reported by various folks on the ARM Linux kernel mailing list, the video-buf.ko driver has undefined references on all ARM machines which use it as observed during `make modules`: Warning: "v4wb_clear_user_page" [drivers/media/video/video-buf.ko] undefined! Similar warnings exist for all ARM machines which use this driver. So this change adds the missing EXPORT_SYMBOLs to allow using this driver as a module. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-07-29 01:29:27 -06:00
#include <asm/page.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 16:20:36 -06:00
#ifndef MULTI_CPU
EXPORT_SYMBOL(cpu_dcache_clean_area);
ARM: modules: don't export cpu_set_pte_ext when !MMU cpu_set_pte_ext is only guaranteed to be defined when CONFIG_MMU, so don't export it to modules otherwise. Signed-off-by: Will Deacon <will.deacon@arm.com>
2013-01-22 04:00:54 -07:00
#ifdef CONFIG_MMU
[ARM] Unuse another Linux PTE bit L_PTE_ASID is not really required to be stored in every PTE, since we can identify it via the address passed to set_pte_at(). So, create set_pte_ext() which takes the address of the PTE to set, the Linux PTE value, and the additional CPU PTE bits which aren't encoded in the Linux PTE value. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-12-13 07:34:43 -07:00
EXPORT_SYMBOL(cpu_set_pte_ext);
ARM: modules: don't export cpu_set_pte_ext when !MMU cpu_set_pte_ext is only guaranteed to be defined when CONFIG_MMU, so don't export it to modules otherwise. Signed-off-by: Will Deacon <will.deacon@arm.com>
2013-01-22 04:00:54 -07:00
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 16:20:36 -06:00
#else
EXPORT_SYMBOL(processor);
#endif
#ifndef MULTI_CACHE
EXPORT_SYMBOL(__cpuc_flush_kern_all);
EXPORT_SYMBOL(__cpuc_flush_user_all);
EXPORT_SYMBOL(__cpuc_flush_user_range);
EXPORT_SYMBOL(__cpuc_coherent_kern_range);
ARM: add size argument to __cpuc_flush_dcache_page ... and rename the function since it no longer operates on just pages. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-11-26 05:56:21 -07:00
EXPORT_SYMBOL(__cpuc_flush_dcache_area);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 16:20:36 -06:00
#else
EXPORT_SYMBOL(cpu_cache);
#endif
[ARM] 4502/1: nommu: Do not export the copy/clear user page functions The __cpu_{clear|copy}_user_page functions are not defined for the MMU-less case and therefore should not be exported. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-07-20 04:42:46 -06:00
#ifdef CONFIG_MMU
[ARM] 3737/1: Export ARM copy/clear_user_page symbols Patch from George G. Davis As reported by various folks on the ARM Linux kernel mailing list, the video-buf.ko driver has undefined references on all ARM machines which use it as observed during `make modules`: Warning: "v4wb_clear_user_page" [drivers/media/video/video-buf.ko] undefined! Similar warnings exist for all ARM machines which use this driver. So this change adds the missing EXPORT_SYMBOLs to allow using this driver as a module. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-07-29 01:29:27 -06:00
#ifndef MULTI_USER
[ARM] clearpage: provide our own clear_user_highpage() For similar reasons as copy_user_page(), we want to avoid the additional kmap_atomic if it's unnecessary. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-10-31 10:32:19 -06:00
EXPORT_SYMBOL(__cpu_clear_user_highpage);
[ARM] copypage: provide our own copy_user_highpage() We used to override the copy_user_page() function. However, this is not only inefficient, it also causes additional complexity for highmem support, since we convert from a struct page to a kernel direct mapped address and back to a struct page again. Moreover, with highmem support, we end up pointlessly setting up kmap entries for pages which we're going to remap. So, push the kmapping down into the copypage implementation files where it's required. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-10-31 09:08:35 -06:00
EXPORT_SYMBOL(__cpu_copy_user_highpage);
[ARM] 3737/1: Export ARM copy/clear_user_page symbols Patch from George G. Davis As reported by various folks on the ARM Linux kernel mailing list, the video-buf.ko driver has undefined references on all ARM machines which use it as observed during `make modules`: Warning: "v4wb_clear_user_page" [drivers/media/video/video-buf.ko] undefined! Similar warnings exist for all ARM machines which use this driver. So this change adds the missing EXPORT_SYMBOLs to allow using this driver as a module. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-07-29 01:29:27 -06:00
#else
EXPORT_SYMBOL(cpu_user);
#endif
[ARM] 4502/1: nommu: Do not export the copy/clear user page functions The __cpu_{clear|copy}_user_page functions are not defined for the MMU-less case and therefore should not be exported. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-07-20 04:42:46 -06:00
#endif
[ARM] 3737/1: Export ARM copy/clear_user_page symbols Patch from George G. Davis As reported by various folks on the ARM Linux kernel mailing list, the video-buf.ko driver has undefined references on all ARM machines which use it as observed during `make modules`: Warning: "v4wb_clear_user_page" [drivers/media/video/video-buf.ko] undefined! Similar warnings exist for all ARM machines which use this driver. So this change adds the missing EXPORT_SYMBOLs to allow using this driver as a module. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-07-29 01:29:27 -06:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 16:20:36 -06:00
/*
* No module should need to touch the TLB (and currently
* no modules do. We export this for "loadkernel" support
* (booting a new kernel from within a running kernel.)
*/
#ifdef MULTI_TLB
EXPORT_SYMBOL(cpu_tlb);
#endif
Reference in a new issue Copy permalink