Commit 855647c4 authored by Andrew Morton's avatar Andrew Morton Committed by Linus Torvalds

[PATCH] efivars: remove from arch/ia64

From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>

I broke up the efivars driver update patch I had sent out quite a while ago
into several smaller patches.  This includes several fixes and suggestions
that were pointed out.  The patches are broken down as follows:

1 - remove all traces of efivars from arch/ia64/
2 - add new sysfs based efivars driver into
    drivers/firmware with accompanying Kconfig/Makefile
    changes to make it fully functional for ia64 again.
3 - cleans up x86 references to the /proc version of
    the efivars driver.
parent b13496e8
...@@ -294,16 +294,6 @@ config IA64_PALINFO ...@@ -294,16 +294,6 @@ config IA64_PALINFO
To use this option, you have to ensure that the "/proc file system To use this option, you have to ensure that the "/proc file system
support" (CONFIG_PROC_FS) is enabled, too. support" (CONFIG_PROC_FS) is enabled, too.
config EFI_VARS
tristate "/proc/efi/vars support"
help
If you say Y here, you are able to get EFI (Extensible Firmware
Interface) variable information in /proc/efi/vars. You may read,
write, create, and destroy EFI variables through this interface.
To use this option, you have to check that the "/proc file system
support" (CONFIG_PROC_FS) is enabled, too.
source "fs/Kconfig.binfmt" source "fs/Kconfig.binfmt"
endmenu endmenu
......
...@@ -8,7 +8,6 @@ obj-y := acpi.o entry.o efi.o efi_stub.o gate-data.o fsys.o ia64_ksyms.o irq.o i ...@@ -8,7 +8,6 @@ obj-y := acpi.o entry.o efi.o efi_stub.o gate-data.o fsys.o ia64_ksyms.o irq.o i
irq_lsapic.o ivt.o machvec.o pal.o patch.o process.o perfmon.o ptrace.o sal.o \ irq_lsapic.o ivt.o machvec.o pal.o patch.o process.o perfmon.o ptrace.o sal.o \
salinfo.o semaphore.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o unwind.o mca.o mca_asm.o salinfo.o semaphore.o setup.o signal.o sys_ia64.o time.o traps.o unaligned.o unwind.o mca.o mca_asm.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_IA64_BRL_EMU) += brl_emu.o obj-$(CONFIG_IA64_BRL_EMU) += brl_emu.o
obj-$(CONFIG_IA64_GENERIC) += acpi-ext.o obj-$(CONFIG_IA64_GENERIC) += acpi-ext.o
obj-$(CONFIG_IA64_HP_ZX1) += acpi-ext.o obj-$(CONFIG_IA64_HP_ZX1) += acpi-ext.o
......
...@@ -24,7 +24,6 @@ ...@@ -24,7 +24,6 @@
#include <linux/init.h> #include <linux/init.h>
#include <linux/types.h> #include <linux/types.h>
#include <linux/time.h> #include <linux/time.h>
#include <linux/proc_fs.h>
#include <linux/efi.h> #include <linux/efi.h>
#include <asm/io.h> #include <asm/io.h>
...@@ -40,19 +39,6 @@ extern efi_status_t efi_call_phys (void *, ...); ...@@ -40,19 +39,6 @@ extern efi_status_t efi_call_phys (void *, ...);
struct efi efi; struct efi efi;
EXPORT_SYMBOL(efi); EXPORT_SYMBOL(efi);
static efi_runtime_services_t *runtime; static efi_runtime_services_t *runtime;
/*
* efi_dir is allocated here, but the directory isn't created
* here, as proc_mkdir() doesn't work this early in the bootup
* process. Therefore, each module, like efivars, must test for
* if (!efi_dir) efi_dir = proc_mkdir("efi", NULL);
* prior to creating their own entries under /proc/efi.
*/
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *efi_dir;
EXPORT_SYMBOL(efi_dir);
#endif
static unsigned long mem_limit = ~0UL; static unsigned long mem_limit = ~0UL;
#define efi_call_virt(f, args...) (*(f))(args) #define efi_call_virt(f, args...) (*(f))(args)
...@@ -747,10 +733,3 @@ valid_phys_addr_range (unsigned long phys_addr, unsigned long *size) ...@@ -747,10 +733,3 @@ valid_phys_addr_range (unsigned long phys_addr, unsigned long *size)
return 0; return 0;
} }
static void __exit
efivars_exit (void)
{
#ifdef CONFIG_PROC_FS
remove_proc_entry(efi_dir->name, NULL);
#endif
}
This diff is collapsed.
...@@ -18,6 +18,7 @@ ...@@ -18,6 +18,7 @@
#include <linux/reboot.h> #include <linux/reboot.h>
#include <linux/slab.h> #include <linux/slab.h>
#include <linux/swap.h> #include <linux/swap.h>
#include <linux/proc_fs.h>
#include <asm/a.out.h> #include <asm/a.out.h>
#include <asm/bitops.h> #include <asm/bitops.h>
......
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