kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-26 18:16:26 +00:00
Code Issues Releases Packages Activity
linux/include/asm-mips/pgtable.h

417 lines
11 KiB
Raw Normal View History

Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[PATCH] mips: clean up 32/64-bit configuration Start cleaning 32-bit vs. 64-bit configuration. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-03 15:56:16 -07:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[PATCH] mips: clean up 32/64-bit configuration Start cleaning 32-bit vs. 64-bit configuration. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-03 15:56:16 -07:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Fix the fixup_bigphys_addr compile problem. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-07-14 00:17:05 +00:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[PATCH] fix remaining missing includes Fix more include file problems that surfaced since I submitted the previous fix-missing-includes.patch. This should now allow not to include sched.h from module.h, which is done by a followup patch. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 00:59:43 -08:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] page.h: remove __pa() usages. __pa() was used by virt_to_page() and virt_addr_valid(). These latter are used when kernel is initialised so __pa() is not appropriate, we use virt_to_phys() instead. Futhermore __pa() is going to take care of CKSEG0/XKPHYS address mix for 64 bit kernels. This makes __pa() more complex than virt_to_phys() and this extra work is not needed by virt_to_page() and virt_addr_valid(). Eventually it consolidates virt_to_phys() prototype by making its argument 'const'. this avoids some warnings that was due to some virt_to_page() usages which pass const pointer. Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-10-19 13:19:59 +02:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[SPARC64]: Fix D-cache corruption in mremap If we move a mapping from one virtual address to another, and this changes the virtual color of the mapping to those pages, we can see corrupt data due to D-cache aliasing. Check for and deal with this by overriding the move_pte() macro. Set things up so that other platforms can cleanly override the move_pte() macro too. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-01 17:47:25 -07:00
[PATCH] mm: move_pte to remap ZERO_PAGE Move the ZERO_PAGE remapping complexity to the move_pte macro in asm-generic, have it conditionally depend on __HAVE_ARCH_MULTIPLE_ZERO_PAGE, which gets defined for MIPS. For architectures without __HAVE_ARCH_MULTIPLE_ZERO_PAGE, move_pte becomes a noop. From: Hugh Dickins <hugh@veritas.com> Fix nasty little bug we've missed in Nick's mremap move ZERO_PAGE patch. The "pte" at that point may be a swap entry or a pte_file entry: we must check pte_present before perhaps corrupting such an entry. Patch below against 2.6.14-rc2-mm1, but the same bug is in 2.6.14-rc2's mm/mremap.c, and more dangerous there since it's affecting all arches: I think the safest course is to send Nick's patch and Yoichi's build fix and this fix (build tested) on to Linus - so only MIPS can be affected. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-27 21:45:18 -07:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[PATCH] Standardize pxx_page macros One of the changes necessary for shared page tables is to standardize the pxx_page macros. pte_page and pmd_page have always returned the struct page associated with their entry, while pte_page_kernel and pmd_page_kernel have returned the kernel virtual address. pud_page and pgd_page, on the other hand, return the kernel virtual address. Shared page tables needs pud_page and pgd_page to return the actual page structures. There are very few actual users of these functions, so it is simple to standardize their usage. Since this is basic cleanup, I am submitting these changes as a standalone patch. Per Hugh Dickins' comments about it, I am also changing the pxx_page_kernel macros to pxx_page_vaddr to clarify their meaning. Signed-off-by: Dave McCracken <dmccr@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-25 23:31:48 -07:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Rename CONFIG_CPU_MIPS{32,64} to CONFIG_CPU_MIPS{32|64}_R1. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-07-06 12:08:11 +00:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Update MIPS to use the 4-level pagetable code thereby getting rid of the compacrapability headers. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-02-10 12:19:59 +00:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Update MIPS to use the 4-level pagetable code thereby getting rid of the compacrapability headers. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-02-10 12:19:59 +00:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Rename CONFIG_CPU_MIPS{32,64} to CONFIG_CPU_MIPS{32|64}_R1. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-07-06 12:08:11 +00:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address In case of CONFIG_64BIT_PHYS_ADDR, set_pte() and pte_clear() functions only set _PAGE_GLOBAL bit in the pte_low field of the buddy PTEs, forgetting to propagate ito to pte_high. Thus, the both pages might not really be made global for the CPU (since it AND's the G-bit of the odd / even PTEs together to decide whether they're global or not). Thus, if only a single page is allocated via vmalloc() or ioremap(), it's not really global for CPU (and it must be, since this is kernel mapping), and thus its ASID is compared against the current process' one -- so, we'll get into trouble sooner or later... Also, pte_none() will fail on global pages because _PAGE_GLOBAL bit is set in both pte_low and pte_high, and pte_val() will return u64 value consisting of those fields concateneted. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-16 23:27:21 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Rename CONFIG_CPU_MIPS{32,64} to CONFIG_CPU_MIPS{32|64}_R1. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-07-06 12:08:11 +00:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
[MIPS] Fix mprotect() syscall for MIPS32 w/36-bit physical address support Fix mprotect() syscall for MIPS32 CPUs with 36-bit physical address support: pte_modify() macro didn't clear the hardware page protection bits before modifying... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-05-03 22:56:43 +04:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00
Use fixed up pfn. Signed-off-by: Thiemo Seufer <ths@networkno.de> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-04-11 12:24:16 +00:00
Linux-2.6.12-rc2 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!
2005-04-16 15:20:36 -07:00