- 20 9月, 2005 1 次提交
-
-
由 Ben Dooks 提交于
Patch from Ben Dooks The `make buildcheck` is erroneously reporting that the .proc.info list is referencing items in the .init section as it is not itself postfixed with .init Signed-off-by: NBen Dooks <ben-linux@fluff.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 10 9月, 2005 1 次提交
-
-
由 Sam Ravnborg 提交于
Delete obsoleted stuff from arch Makefile and rename constants.h to asm-offsets.h Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 15 8月, 2005 1 次提交
-
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 10 8月, 2005 2 次提交
-
-
由 Russell King 提交于
Unfortunately, we can't use the "user" bit in the page tables to control whether a page table entry is "global" or "asid" specific, since the vector page is mapped as "user" accessible but is not process specific. Therefore, give direct control of the ARMv6 "nG" (not global) bit to the mm layers. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 7月, 2005 1 次提交
-
-
由 Catalin Marinas 提交于
Patch from Catalin Marinas The VFP instructions trigger undefined exceptions because the access to CP11 is disabled (only CP10 is currently enabled by the kernel). The patch fixes this problem. Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 25 6月, 2005 1 次提交
-
-
由 Catalin Marinas 提交于
Patch from Catalin Marinas cpu_v6_set_pte() sets the kernel access rights to r/o for user pages (L_PTE_USER) when neither L_PTE_WRITE nor L_PTE_DIRTY are set. This causes a kernel data abort when writing the TLS value in the 0xffff0000 page. This patch enables the kernel r/w access. Signed-off-by: Catalin Marinas Signed-off-by: NRussell King <rmk+kernel@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!
-