Searched hist:"62 fa6e69a436f662090f3996538adb9e568817f6" (Results 1 – 5 of 5) sorted by relevance
| /openbmc/linux/arch/x86/platform/efi/ |
| H A D | efi_stub_64.S | diff 62fa6e69a436f662090f3996538adb9e568817f6 Thu Mar 27 17:10:39 CDT 2014 Matt Fleming <matt.fleming@intel.com> x86/efi: Delete most of the efi_call* macros
We really only need one phys and one virt function call, and then only
one assembly function to make firmware calls.
Since we are not using the C type system anyway, we're not really losing
much by deleting the macros apart from no longer having a check that
we are passing the correct number of parameters. The lack of duplicated
code seems like a worthwhile trade-off.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| H A D | efi.c | diff 62fa6e69a436f662090f3996538adb9e568817f6 Thu Mar 27 17:10:39 CDT 2014 Matt Fleming <matt.fleming@intel.com> x86/efi: Delete most of the efi_call* macros
We really only need one phys and one virt function call, and then only
one assembly function to make firmware calls.
Since we are not using the C type system anyway, we're not really losing
much by deleting the macros apart from no longer having a check that
we are passing the correct number of parameters. The lack of duplicated
code seems like a worthwhile trade-off.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| /openbmc/linux/arch/x86/platform/uv/ |
| H A D | bios_uv.c | diff 62fa6e69a436f662090f3996538adb9e568817f6 Thu Mar 27 17:10:39 CDT 2014 Matt Fleming <matt.fleming@intel.com> x86/efi: Delete most of the efi_call* macros
We really only need one phys and one virt function call, and then only
one assembly function to make firmware calls.
Since we are not using the C type system anyway, we're not really losing
much by deleting the macros apart from no longer having a check that
we are passing the correct number of parameters. The lack of duplicated
code seems like a worthwhile trade-off.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| /openbmc/linux/arch/x86/include/asm/ |
| H A D | efi.h | diff 62fa6e69a436f662090f3996538adb9e568817f6 Thu Mar 27 17:10:39 CDT 2014 Matt Fleming <matt.fleming@intel.com> x86/efi: Delete most of the efi_call* macros
We really only need one phys and one virt function call, and then only
one assembly function to make firmware calls.
Since we are not using the C type system anyway, we're not really losing
much by deleting the macros apart from no longer having a check that
we are passing the correct number of parameters. The lack of duplicated
code seems like a worthwhile trade-off.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| /openbmc/linux/arch/x86/boot/compressed/ |
| H A D | head_64.S | diff 62fa6e69a436f662090f3996538adb9e568817f6 Thu Mar 27 17:10:39 CDT 2014 Matt Fleming <matt.fleming@intel.com> x86/efi: Delete most of the efi_call* macros
We really only need one phys and one virt function call, and then only
one assembly function to make firmware calls.
Since we are not using the C type system anyway, we're not really losing
much by deleting the macros apart from no longer having a check that
we are passing the correct number of parameters. The lack of duplicated
code seems like a worthwhile trade-off.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|