09 May, 2007

1 commit

  • We used to warn unless the EFI system table major revision was exactly 1.
    But EFI 2.00 firmware is starting to appear, and the 2.00 changes don't
    affect anything in Linux.

    Signed-off-by: Bjorn Helgaas
    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

02 Feb, 2007

1 commit


07 Dec, 2006

2 commits


09 May, 2006

1 commit

  • This closes a couple holes in our attribute aliasing avoidance scheme:

    - The current kernel fails mmaps of some /dev/mem MMIO regions because
    they don't appear in the EFI memory map. This keeps X from working
    on the Intel Tiger box.

    - The current kernel allows UC mmap of the 0-1MB region of
    /sys/.../legacy_mem even when the chipset doesn't support UC
    access. This causes an MCA when starting X on HP rx7620 and rx8620
    boxes in the default configuration.

    There's more detail in the Documentation/ia64/aliasing.txt file this
    adds, but the general idea is that if a region might be covered by
    a granule-sized kernel identity mapping, any access via /dev/mem or
    mmap must use the same attribute as the identity mapping.

    Otherwise, we fall back to using an attribute that is supported
    according to the EFI memory map, or to using UC if the EFI memory
    map doesn't mention the region.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Tony Luck

    Bjorn Helgaas
     

27 Mar, 2006

2 commits

  • Almost all users of the table addresses from the EFI system table want
    physical addresses. So rather than doing the pa->va->pa conversion, just keep
    physical addresses in struct efi.

    This fixes a DMI bug: the efi structure contained the physical SMBIOS address
    on x86 but the virtual address on ia64, so dmi_scan_machine() used ioremap()
    on a virtual address on ia64.

    This is essentially the same as an earlier patch by Matt Tolentino:
    http://marc.theaimsgroup.com/?l=linux-kernel&m=112130292316281&w=2
    except that this changes all table addresses, not just ACPI addresses.

    Matt's original patch was backed out because it caused MCAs on HP sx1000
    systems. That problem is resolved by the ioremap() attribute checking added
    for ia64.

    Signed-off-by: Bjorn Helgaas
    Cc: Matt Domsch
    Cc: "Tolentino, Matthew E"
    Cc: "Brown, Len"
    Cc: Andi Kleen
    Acked-by: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     
  • Pass the size, not a pointer to the size, to efi_mem_attribute_range().

    This function validates memory regions for the /dev/mem read/write/mmap paths.
    The pointer allows arches to reduce the size of the range, but I think that's
    unnecessary complexity. Simplifying it will let me use
    efi_mem_attribute_range() to improve the ia64 ioremap() implementation.

    Signed-off-by: Bjorn Helgaas
    Cc: Matt Domsch
    Cc: "Tolentino, Matthew E"
    Cc: "Brown, Len"
    Cc: Andi Kleen
    Acked-by: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

05 Sep, 2005

1 commit

  • The memory descriptors that comprise the EFI memory map are not fixed in
    stone such that the size could change in the future. This uses the memory
    descriptor size obtained from EFI to iterate over the memory map entries
    during boot. This enables the removal of an x86 specific pad (and ifdef)
    in the EFI header. I also couldn't stomach the broken up nature of the
    function to put EFI runtime calls into virtual mode any longer so I fixed
    that up a bit as well.

    For reference, this patch only impacts x86.

    Signed-off-by: Matt Tolentino
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Tolentino
     

17 Jun, 2005

1 commit

  • warning when building with gcc -W :

    include/linux/efi.h: In function `efi_range_is_wc':
    include/linux/efi.h:320: warning: comparison between signed and unsigned

    It looks to me like a significantly large 'len' passed in could cause the
    loop to never end. Isn't it safer to make 'i' an unsigned long as well?
    Like this little patch below (which of course also kills the warning) :

    Signed-off-by: Jesper Juhl
    Signed-off-by: Tony Luck

    Jesper Juhl
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds