18 Jun, 2009

1 commit

  • It is generally agreed that it would be beneficial for u64 to be an
    unsigned long long on all architectures. ia64 (in common with several
    other 64-bit architectures) currently uses unsigned long. Migrating
    piecemeal is too painful; this giant patch fixes all compilation warnings
    and errors that come as a result of switching to use int-ll64.h.

    Note that userspace will still see __u64 defined as unsigned long. This
    is important as it affects C++ name mangling.

    [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
    u64 for start/end rather than unsigned long]

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Tony Luck

    Matthew Wilcox
     

16 Oct, 2008

1 commit


25 May, 2008

1 commit


20 Apr, 2008

1 commit

  • Make x86 EFI code works when EFI_PAGE_SHIFT != PAGE_SHIFT. The
    memrage_efi_to_native() provided in this patch can be used on other
    EFI platform such as IA64 too.

    This patch has been tested on Intel x86_64 platform with EFI 64/32
    firmware.

    Signed-off-by: Huang Ying
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Huang, Ying
     

22 Oct, 2007

1 commit

  • Add the BSS to the resource tree just as kernel text and kernel data are in
    the resource tree. The main reason behind this is to avoid crashkernel
    reservation in that area.

    While it's not strictly necessary to have the BSS in the resource tree (the
    actual collision detection is done in the reserve_bootmem() function before),
    the usage of the BSS resource should be presented to the user in /proc/iomem
    just as Kernel data and Kernel code.

    Note: The patch currently is only implemented for x86 and ia64 (because
    efi_initialize_iomem_resources() has the same signature on i386 and ia64).

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Bernhard Walle
    Cc: "Eric W. Biederman"
    Cc: Vivek Goyal
    Cc:
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bernhard Walle
     

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