kernel.git/arch/ia64/kernel/efi.c, branch linux-2.6.19.y

[IA64] sparse cleanups

2006-08-02T23:03:44Z

Fix some sparse warnings on ia64. Large constants that should be long instead of int. Use NULL instead of 0. Add some missing __iomem casts. Replace a non-C99 structure assignment. Signed-off-by: Keith Owens Signed-off-by: Tony Luck

[PATCH] make valid_mmap_phys_addr_range() take a pfn

2006-07-10T20:24:25Z

Newer ARMs have a 40 bit physical address space, but mapping physical memory above 4G needs a special page table format which we (currently?) do not use for userspace mappings, so what happens instead is that mapping an address >= 4G will happily discard the upper bits and wrap. There is a valid_mmap_phys_addr_range() arch hook where we could check for >= 4G addresses and deny the mapping, but this hook takes an unsigned long address: static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t size); And drivers/char/mem.c:mmap_mem() calls it like this: static int mmap_mem(struct file * file, struct vm_area_struct * vma) { size_t size = vma->vm_end - vma->vm_start; if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, size)) So that's not much help either. This patch makes the hook take a pfn instead of a phys address. Signed-off-by: Lennert Buytenhek Cc: Bjorn Helgaas Cc: "Luck, Tony" Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Remove obsolete #include

2006-06-30T17:25:36Z

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk

[IA64] rework memory attribute aliasing

2006-05-08T23:32:05Z

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

[PATCH] EFI: keep physical table addresses in efi structure

2006-03-26T16:56:54Z

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

[PATCH] EFI, /dev/mem: simplify efi_mem_attribute_range()

2006-03-26T16:56:54Z

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

[IA64] Fix wrong use of memparse in efi.c

2006-02-07T22:13:09Z

The check of (end != cp) after memparse in efi.c looks wrong to me. The result is that we can't use mem= and max_addr= kernel parameter at the same time. The following patch removed the check just like other arches do. Signed-off-by: Zou Nan hai Signed-off-by: Tony Luck

[IA64] Fix a possible buffer overflow in efi.c

2006-02-07T18:59:37Z

Make sure to save space for the trailing '\0'. Signed-off-by: Zou Nan hai Signed-off-by: Tony Luck

[PATCH] /dev/mem: validate mmap requests

2006-01-09T04:14:02Z

Add a hook so architectures can validate /dev/mem mmap requests. This is analogous to validation we already perform in the read/write paths. The identity mapping scheme used on ia64 requires that each 16MB or 64MB granule be accessed with exactly one attribute (write-back or uncacheable). This avoids "attribute aliasing", which can cause a machine check. Sample problem scenario: - Machine supports VGA, so it has uncacheable (UC) MMIO at 640K-768K - efi_memmap_init() discards any write-back (WB) memory in the first granule - Application (e.g., "hwinfo") mmaps /dev/mem, offset 0 - hwinfo receives UC mapping (the default, since memmap says "no WB here") - Machine check abort (on chipsets that don't support UC access to WB memory, e.g., sx1000) In the scenario above, the only choices are - Use WB for hwinfo mmap. Can't do this because it causes attribute aliasing with the UC mapping for the VGA MMIO space. - Use UC for hwinfo mmap. Can't do this because the chipset may not support UC for that region. - Disallow the hwinfo mmap with -EINVAL. That's what this patch does. Signed-off-by: Bjorn Helgaas Cc: Hugh Dickins Cc: "Luck, Tony" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[IA64] Replace kcalloc(1, with kzalloc.

2005-11-10T19:28:20Z

Conversion from kcalloc(1, to kzalloc. Signed-off-by: Panagiotis Issaris Signed-off-by: Tony Luck