- 22 11月, 2010 1 次提交
-
-
由 Anand Gadiyar 提交于
Commit 7c63984b (ARM: do not define VMALLOC_END relative to PAGE_OFFSET) changed VMALLOC_END to be an explicit value. Before this, it was relative to PAGE_OFFSET and therefore converted to unsigned long as PAGE_OFFSET is an unsigned long. This introduced the following build warning. Fix this by changing the explicit defines of VMALLOC_END to be unsigned long. CC arch/arm/mm/init.o arch/arm/mm/init.c: In function 'mem_init': arch/arm/mm/init.c:606: warning: format '%08lx' expects type 'long unsigned int', but argument 12 has type 'unsigned int' Signed-off-by: NAnand Gadiyar <gadiyar@ti.com> Acked-by: NUwe Kleine-K <u.kleine-koenig@pengutronix.dee> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 10月, 2010 1 次提交
-
-
由 Nicolas Pitre 提交于
VMALLOC_END is supposed to be an absolute value, while PAGE_OFFSET may vary depending on the selected user:kernel memory split mode through CONFIG_VMSPLIT_*. In fact, the goal of moving PAGE_OFFSET down is to accommodate more directly addressed RAM by the kernel below the vmalloc area, and having VMALLOC_END move along PAGE_OFFSET is rather against the very reason why PAGE_OFFSET can be moved in the first place. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
-
- 07 8月, 2008 1 次提交
-
-
由 Russell King 提交于
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 5月, 2005 1 次提交
-
-
由 Russell King 提交于
VMALLOC_START and VMALLOC_OFFSET are common between all ARM machine classes. Move them into include/asm-arm/pgtable.h, but allow a machine class to override them if required. Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-