How about the attached patch instead? I'd rather not make vmap() generally
available in NOMMU mode since it can't be implemented in NOMMU mode. Yes,
vmap() can take a copy of the pages it is given, but you can't guarantee
that's the right thing to do. It's like a shared-writable mmap.
Instead, why not just override vmap() in firmware_class.c for the one instance
where we know we're happy with this behaviour?
David
---
From: David Howells <dhowe...@redhat.com>
Subject: [PATCH] NOMMU: Work around the lack of vmap()/vunmap() in
firmware_loading_store()
Work around the lack of vmap()/vunmap() in firmware_loading_store() when
operating in NOMMU mode. vmap() cannot be implemented as there's no virtual
mapping available.
Instead, in NOMMU mode, coalesce the data into one big buffer and store as the
address vmap() would've returned.
Signed-off-by: David Howells <dhowe...@redhat.com>
---
drivers/base/firmware_class.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 18518ba..e33c2cb 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -59,6 +59,33 @@ static struct builtin_fw *__start_builtin_fw;
static struct builtin_fw *__end_builtin_fw;
#endif
+/*
+ * NOMMU mode can't provide vmap() as there's no MMU to do the virtual mapping.
+ * Coalesce the data into a big buffer instead.
+ */
+#ifndef CONFIG_MMU
+static void *__pretend_vmap(struct page **pages, unsigned int count,
+ unsigned long flags, pgprot_t prot)
+{
+ unsigned int i;
+ void *new_map, *page_data;
+
+ new_map = kmalloc(count << PAGE_SHIFT, GFP_KERNEL);
+ if (!new_map)
+ return NULL;
+
+ for (i = 0; i < count; ++i) {
+ page_data = kmap(pages[i]);
+ memcpy(new_map + (i << PAGE_SHIFT), page_data, PAGE_SIZE);
+ kunmap(page_data);
+ }
+
+ return new_map;
+}
+
+#define vmap(pg, c, f, pr) __pretend_vmap(pg, c, f, pr)
+#endif /* !CONFIG_MMU */
+
static void
fw_load_abort(struct firmware_priv *fw_priv)
{
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
