From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: linux-ia64@vger.kernel.org, ak@suse.de,
openipmi-developer@lists.sourceforge.net, akpm@osdl.org,
"Tolentino, Matthew E" <matthew.e.tolentino@intel.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: [PATCH 1/5] EFI, /dev/mem: simplify efi_mem_attribute_range()
Date: Thu, 19 Jan 2006 13:12:18 -0700 [thread overview]
Message-ID: <200601191312.19027.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <200601191310.57303.bjorn.helgaas@hp.com>
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 <bjorn.helgaas@hp.com>
Index: work-mm3/arch/ia64/kernel/efi.c
===================================================================
--- work-mm3.orig/arch/ia64/kernel/efi.c 2006-01-18 13:25:29.000000000 -0700
+++ work-mm3/arch/ia64/kernel/efi.c 2006-01-18 13:27:18.000000000 -0700
@@ -685,27 +685,34 @@
/*
* Determines whether the memory at phys_addr supports the desired
* attribute (WB, UC, etc). If this returns 1, the caller can safely
- * access *size bytes at phys_addr with the specified attribute.
+ * access size bytes at phys_addr with the specified attribute.
*/
-static int
-efi_mem_attribute_range (unsigned long phys_addr, unsigned long *size, u64 attr)
+int
+efi_mem_attribute_range (unsigned long phys_addr, unsigned long size, u64 attr)
{
+ unsigned long end = phys_addr + size;
efi_memory_desc_t *md = efi_memory_descriptor(phys_addr);
- unsigned long md_end;
- if (!md || (md->attribute & attr) != attr)
+ /*
+ * Some firmware doesn't report MMIO regions in the EFI memory
+ * map. The Intel BigSur (a.k.a. HP i2000) has this problem.
+ * On those platforms, we have to assume UC is valid everywhere.
+ */
+ if (!md || (md->attribute & attr) != attr) {
+ if (attr == EFI_MEMORY_UC && !efi_memmap_has_mmio())
+ return 1;
return 0;
+ }
do {
- md_end = efi_md_end(md);
- if (phys_addr + *size <= md_end)
+ unsigned long md_end = efi_md_end(md);
+
+ if (end <= md_end)
return 1;
md = efi_memory_descriptor(md_end);
- if (!md || (md->attribute & attr) != attr) {
- *size = md_end - phys_addr;
- return 1;
- }
+ if (!md || (md->attribute & attr) != attr)
+ return 0;
} while (md);
return 0;
}
@@ -716,7 +723,7 @@
* control access size.
*/
int
-valid_phys_addr_range (unsigned long phys_addr, unsigned long *size)
+valid_phys_addr_range (unsigned long phys_addr, unsigned long size)
{
return efi_mem_attribute_range(phys_addr, size, EFI_MEMORY_WB);
}
@@ -731,7 +738,7 @@
* because that doesn't appear in the boot-time EFI memory map.
*/
int
-valid_mmap_phys_addr_range (unsigned long phys_addr, unsigned long *size)
+valid_mmap_phys_addr_range (unsigned long phys_addr, unsigned long size)
{
if (efi_mem_attribute_range(phys_addr, size, EFI_MEMORY_WB))
return 1;
@@ -739,14 +746,6 @@
if (efi_mem_attribute_range(phys_addr, size, EFI_MEMORY_UC))
return 1;
- /*
- * Some firmware doesn't report MMIO regions in the EFI memory map.
- * The Intel BigSur (a.k.a. HP i2000) has this problem. In this
- * case, we can't use the EFI memory map to validate mmap requests.
- */
- if (!efi_memmap_has_mmio())
- return 1;
-
return 0;
}
Index: work-mm3/drivers/char/mem.c
===================================================================
--- work-mm3.orig/drivers/char/mem.c 2006-01-18 13:25:27.000000000 -0700
+++ work-mm3/drivers/char/mem.c 2006-01-18 13:27:18.000000000 -0700
@@ -88,21 +88,15 @@
}
#ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE
-static inline int valid_phys_addr_range(unsigned long addr, size_t *count)
+static inline int valid_phys_addr_range(unsigned long addr, size_t count)
{
- unsigned long end_mem;
-
- end_mem = __pa(high_memory);
- if (addr >= end_mem)
+ if (addr + count > __pa(high_memory))
return 0;
- if (*count > end_mem - addr)
- *count = end_mem - addr;
-
return 1;
}
-static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t *size)
+static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t size)
{
return 1;
}
@@ -119,7 +113,7 @@
ssize_t read, sz;
char *ptr;
- if (!valid_phys_addr_range(p, &count))
+ if (!valid_phys_addr_range(p, count))
return -EFAULT;
read = 0;
#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
@@ -177,7 +171,7 @@
unsigned long copied;
void *ptr;
- if (!valid_phys_addr_range(p, &count))
+ if (!valid_phys_addr_range(p, count))
return -EFAULT;
written = 0;
@@ -251,7 +245,7 @@
{
size_t size = vma->vm_end - vma->vm_start;
- if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, &size))
+ if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, size))
return -EINVAL;
vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff,
Index: work-mm3/include/asm-ia64/io.h
===================================================================
--- work-mm3.orig/include/asm-ia64/io.h 2006-01-18 13:25:27.000000000 -0700
+++ work-mm3/include/asm-ia64/io.h 2006-01-18 13:27:18.000000000 -0700
@@ -88,8 +88,8 @@
}
#define ARCH_HAS_VALID_PHYS_ADDR_RANGE
-extern int valid_phys_addr_range (unsigned long addr, size_t *count); /* efi.c */
-extern int valid_mmap_phys_addr_range (unsigned long addr, size_t *count);
+extern int valid_phys_addr_range (unsigned long addr, size_t count); /* efi.c */
+extern int valid_mmap_phys_addr_range (unsigned long addr, size_t count);
/*
* The following two macros are deprecated and scheduled for removal.
Index: work-mm3/include/linux/efi.h
===================================================================
--- work-mm3.orig/include/linux/efi.h 2006-01-18 13:25:27.000000000 -0700
+++ work-mm3/include/linux/efi.h 2006-01-18 13:27:18.000000000 -0700
@@ -292,6 +292,8 @@
extern u64 efi_get_iobase (void);
extern u32 efi_mem_type (unsigned long phys_addr);
extern u64 efi_mem_attributes (unsigned long phys_addr);
+extern int efi_mem_attribute_range (unsigned long phys_addr, unsigned long size,
+ u64 attr);
extern int __init efi_uart_console_only (void);
extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource);
next prev parent reply other threads:[~2006-01-19 20:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-04 22:16 [PATCH 2.6.15 1/2] ia64: use i386 dmi_scan.c Matt Domsch
2006-01-04 22:36 ` Alex Williamson
2006-01-04 23:29 ` Matt Domsch
2006-01-05 16:41 ` Bjorn Helgaas
2006-01-05 17:37 ` Matt Domsch
2006-01-05 17:54 ` Bjorn Helgaas
2006-01-06 0:02 ` Bjorn Helgaas
2006-01-06 17:15 ` Matt Domsch
2006-01-04 22:55 ` Alan Cox
2006-01-06 17:21 ` [PATCH 2.6.15] " Matt Domsch
2006-01-06 22:39 ` Matt Domsch
2006-01-14 0:24 ` Bjorn Helgaas
2006-01-14 0:45 ` Alan Cox
2006-01-14 1:19 ` Andi Kleen
2006-01-14 5:05 ` Bjorn Helgaas
2006-01-18 0:17 ` Bjorn Helgaas
2006-01-18 2:32 ` Andi Kleen
2006-01-18 15:53 ` Bjorn Helgaas
2006-01-18 17:29 ` Bjorn Helgaas
2006-01-18 18:11 ` [Openipmi-developer] " Matt Domsch
2006-01-19 20:10 ` [PATCH 0/5] ia64 ioremap, DMI, EFI system table Bjorn Helgaas
2006-01-19 20:12 ` Bjorn Helgaas [this message]
2006-01-19 20:12 ` [PATCH 2/5] ia64: ioremap: check EFI for valid memory attributes Bjorn Helgaas
2006-01-19 20:13 ` [PATCH 3/5] DMI: only ioremap stuff we actually need Bjorn Helgaas
2006-01-19 20:13 ` [PATCH 4/5] EFI: keep physical table addresses in efi structure Bjorn Helgaas
2006-01-19 20:14 ` [PATCH 5/5] ACPI: clean up memory attribute checking for map/read/write Bjorn Helgaas
2006-01-30 17:11 ` [Openipmi-developer] [PATCH 0/5] ia64 ioremap, DMI, EFI system table Matt Domsch
2006-03-17 23:54 ` [PATCH 2.6.15] ia64: use i386 dmi_scan.c Andrew Morton
2006-03-18 14:56 ` Matt Domsch
2006-03-18 15:43 ` Matt Domsch
2006-03-18 19:51 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200601191312.19027.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=Matt_Domsch@dell.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.e.tolentino@intel.com \
--cc=openipmi-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).