1. 28 4月, 2016 3 次提交
  2. 24 2月, 2016 1 次提交
  3. 22 2月, 2016 1 次提交
  4. 11 2月, 2016 2 次提交
  5. 03 2月, 2016 4 次提交
  6. 28 10月, 2015 1 次提交
    • A
      efi: Use correct type for struct efi_memory_map::phys_map · 44511fb9
      Ard Biesheuvel 提交于
      We have been getting away with using a void* for the physical
      address of the UEFI memory map, since, even on 32-bit platforms
      with 64-bit physical addresses, no truncation takes place if the
      memory map has been allocated by the firmware (which only uses
      1:1 virtually addressable memory), which is usually the case.
      
      However, commit:
      
        0f96a99d ("efi: Add "efi_fake_mem" boot option")
      
      adds code that clones and modifies the UEFI memory map, and the
      clone may live above 4 GB on 32-bit platforms.
      
      This means our use of void* for struct efi_memory_map::phys_map has
      graduated from 'incorrect but working' to 'incorrect and
      broken', and we need to fix it.
      
      So redefine struct efi_memory_map::phys_map as phys_addr_t, and
      get rid of a bunch of casts that are now unneeded.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: izumi.taku@jp.fujitsu.com
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: linux-efi@vger.kernel.org
      Cc: matt.fleming@intel.com
      Link: http://lkml.kernel.org/r/1445593697-1342-1-git-send-email-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      44511fb9
  7. 12 10月, 2015 4 次提交
  8. 08 8月, 2015 1 次提交
  9. 25 6月, 2015 1 次提交
  10. 08 6月, 2015 1 次提交
    • P
      efi: Work around ia64 build problem with ESRT driver · 3846c158
      Peter Jones 提交于
      So, I'm told this problem exists in the world:
      
       > Subject: Build error in -next due to 'efi: Add esrt support'
       >
       > Building ia64:defconfig ... failed
       > --------------
       > Error log:
       >
       > drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
       >
      
      I'm not really sure how it's okay that we have things in asm-generic on
      some platforms but not others - is having it the same everywhere not the
      whole point of asm-generic?
      
      That said, ia64 doesn't have early_ioremap.h .  So instead, since it's
      difficult to imagine new IA64 machines with UEFI 2.5, just don't build
      this code there.
      
      To me this looks like a workaround - doing something like:
      
      generic-y += early_ioremap.h
      
      in arch/ia64/include/asm/Kbuild would appear to be more correct, but
      ia64 has its own early_memremap() decl in arch/ia64/include/asm/io.h ,
      and it's a macro.  So adding the above /and/ requiring that asm/io.h be
      included /after/ asm/early_ioremap.h in all cases would fix it, but
      that's pretty ugly as well.  Since I'm not going to spend the rest of my
      life rectifying ia64 headers vs "generic" headers that aren't generic,
      it's much simpler to just not build there.
      
      Note that I've only actually tried to build this patch on x86_64, but
      esrt.o still gets built there, and that would seem to demonstrate that
      the conditional building is working correctly at all the places the code
      built before.  I no longer have any ia64 machines handy to test that the
      exclusion actually works there.
      Signed-off-by: NPeter Jones <pjones@redhat.com>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      (Compile-)Tested-by: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      3846c158
  11. 28 5月, 2015 1 次提交
    • D
      e820, efi: add ACPI 6.0 persistent memory types · ad5fb870
      Dan Williams 提交于
      ACPI 6.0 formalizes e820-type-7 and efi-type-14 as persistent memory.
      Mark it "reserved" and allow it to be claimed by a persistent memory
      device driver.
      
      This definition is in addition to the Linux kernel's existing type-12
      definition that was recently added in support of shipping platforms with
      NVDIMM support that predate ACPI 6.0 (which now classifies type-12 as
      OEM reserved).
      
      Note, /proc/iomem can be consulted for differentiating legacy
      "Persistent Memory (legacy)" E820_PRAM vs standard "Persistent Memory"
      E820_PMEM.
      
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ad5fb870
  12. 01 5月, 2015 1 次提交
  13. 01 4月, 2015 1 次提交
  14. 12 1月, 2015 1 次提交
  15. 08 1月, 2015 1 次提交
  16. 05 11月, 2014 1 次提交
  17. 04 10月, 2014 5 次提交
    • M
      efi: Provide a non-blocking SetVariable() operation · 6d80dba1
      Matt Fleming 提交于
      There are some circumstances that call for trying to write an EFI
      variable in a non-blocking way. One such scenario is when writing pstore
      data in efi_pstore_write() via the pstore_dump() kdump callback.
      
      Now that we have an EFI runtime spinlock we need a way of aborting if
      there is contention instead of spinning, since when writing pstore data
      from the kdump callback, the runtime lock may already be held by the CPU
      that's running the callback if we crashed in the middle of an EFI
      variable operation.
      
      The situation is sufficiently special that a new EFI variable operation
      is warranted.
      
      Introduce ->set_variable_nonblocking() for this use case. It is an
      optional EFI backend operation, and need only be implemented by those
      backends that usually acquire locks to serialize access to EFI
      variables, as is the case for virt_efi_set_variable() where we now grab
      the EFI runtime spinlock.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      6d80dba1
    • L
      efi: Introduce efi_md_typeattr_format() · 98d2a6ca
      Laszlo Ersek 提交于
      At the moment, there are three architectures debug-printing the EFI memory
      map at initialization: x86, ia64, and arm64. They all use different format
      strings, plus the EFI memory type and the EFI memory attributes are
      similarly hard to decode for a human reader.
      
      Introduce a helper __init function that formats the memory type and the
      memory attributes in a unified way, to a user-provided character buffer.
      
      The array "memory_type_name" is copied from the arm64 code, temporarily
      duplicating it. The (otherwise optional) braces around each string literal
      in the initializer list are dropped in order to match the kernel coding
      style more closely. The element size is tightened from 32 to 20 bytes
      (maximum actual string length + 1) so that we can derive the field width
      from the element size.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [ Dropped useless 'register' keyword, which compiler will ignore ]
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      98d2a6ca
    • L
      efi: Add macro for EFI_MEMORY_UCE memory attribute · 9c97e0bd
      Laszlo Ersek 提交于
      Add the following macro from the UEFI spec, for completeness:
      
        EFI_MEMORY_UCE  Memory cacheability attribute: The memory region
                        supports being configured as not cacheable, exported,
                        and supports the "fetch and add" semaphore mechanism.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      9c97e0bd
    • D
      efi: Move noefi early param code out of x86 arch code · b2e0a54a
      Dave Young 提交于
      noefi param can be used for arches other than X86 later, thus move it
      out of x86 platform code.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b2e0a54a
    • M
      efi: Add efi= parameter parsing to the EFI boot stub · 5a17dae4
      Matt Fleming 提交于
      We need a way to customize the behaviour of the EFI boot stub, in
      particular, we need a way to disable the "chunking" workaround, used
      when reading files from the EFI System Partition.
      
      One of my machines doesn't cope well when reading files in 1MB chunks to
      a buffer above the 4GB mark - it appears that the "chunking" bug
      workaround triggers another firmware bug. This was only discovered with
      commit 4bf7111f ("x86/efi: Support initrd loaded above 4G"), and
      that commit is perfectly valid. The symptom I observed was a corrupt
      initrd rather than any kind of crash.
      
      efi= is now used to specify EFI parameters in two very different
      execution environments, the EFI boot stub and during kernel boot.
      
      There is also a slight performance optimization by enabling efi=nochunk,
      but that's offset by the fact that you're more likely to run into
      firmware issues, at least on x86. This is the rationale behind leaving
      the workaround enabled by default.
      
      Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're
      using the current value of 1MB.
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Roy Franz <roy.franz@linaro.org>
      Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5a17dae4
  18. 09 8月, 2014 1 次提交
    • V
      kexec: support kexec/kdump on EFI systems · 6a2c20e7
      Vivek Goyal 提交于
      This patch does two things.  It passes EFI run time mappings to second
      kernel in bootparams efi_info.  Second kernel parse this info and create
      new mappings in second kernel.  That means mappings in first and second
      kernel will be same.  This paves the way to enable EFI in kexec kernel.
      
      This patch also prepares and passes EFI setup data through bootparams.
      This contains bunch of information about various tables and their
      addresses.
      
      These information gathering and passing has been written along the lines
      of what current kexec-tools is doing to make kexec work with UEFI.
      
      [akpm@linux-foundation.org: s/get_efi/efi_get/g, per Matt]
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Matt Fleming <matt@console-pimps.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a2c20e7
  19. 19 7月, 2014 6 次提交
  20. 08 7月, 2014 2 次提交
    • A
      efi: efistub: Refactor stub components · bd669475
      Ard Biesheuvel 提交于
      In order to move from the #include "../../../xxxxx.c" anti-pattern used
      by both the x86 and arm64 versions of the stub to a static library
      linked into either the kernel proper (arm64) or a separate boot
      executable (x86), there is some prepatory work required.
      
      This patch does the following:
      - move forward declarations of functions shared between the arch
        specific and the generic parts of the stub to include/linux/efi.h
      - move forward declarations of functions shared between various .c files
        of the generic stub code to a new local header file called "efistub.h"
      - add #includes to all .c files which were formerly relying on the
        #includor to include the correct header files
      - remove all static modifiers from functions which will need to be
        externally visible once we move to a static library
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      bd669475
    • A
      efi/x86: Move UEFI Runtime Services wrappers to generic code · 022ee6c5
      Ard Biesheuvel 提交于
      In order for other archs (such as arm64) to be able to reuse the virtual
      mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      022ee6c5
  21. 01 5月, 2014 1 次提交