summaryrefslogtreecommitdiffstats
path: root/include/asm-mips/pgtable.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds2006-06-021-1/+9
|\ | | | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC64]: Fix D-cache corruption in mremap [SPARC64]: Make smp_processor_id() functional before start_kernel()
| * [SPARC64]: Fix D-cache corruption in mremapDavid S. Miller2006-06-011-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | [MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical addressSergei Shtylyov2006-06-011-39/+49
|/ | | | | | | | | | | | | | | | | | 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>
* [PATCH] fix remaining missing includesTim Schmielau2005-11-071-0/+3
| | | | | | | | | | 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>
* [PATCH] vm: remove unused/broken page_pte[_prot] macrosTejun Heo2005-10-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | This patch removes page_pte_prot and page_pte macros from all architectures. Some architectures define both, some only page_pte (broken) and others none. These macros are not used anywhere. page_pte_prot(page, prot) is identical to mk_pte(page, prot) and page_pte(page) is identical to page_pte_prot(page, __pgprot(0)). * The following architectures define both page_pte_prot and page_pte arm, arm26, ia64, sh64, sparc, sparc64 * The following architectures define only page_pte (broken) frv, i386, m32r, mips, sh, x86-64 * All other architectures define neither Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Fix the fixup_bigphys_addr compile problem.Pete Popov2005-10-291-1/+1
| | | | Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* Rename CONFIG_CPU_MIPS{32,64} to CONFIG_CPU_MIPS{32|64}_R1.Ralf Baechle2005-10-291-3/+3
| | | | Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* Use fixed up pfn.Thiemo Seufer2005-10-291-1/+1
| | | | | Signed-off-by: Thiemo Seufer <ths@networkno.de> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* Update MIPS to use the 4-level pagetable code thereby getting rid ofRalf Baechle2005-10-291-4/+9
| | | | | | the compacrapability headers. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* [PATCH] mm: move_pte to remap ZERO_PAGENick Piggin2005-09-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] feature removal of io_remap_page_range()Randy Dunlap2005-09-131-12/+0
| | | | | | | | | As written in Documentation/feature-removal-schedule.txt, remove the io_remap_page_range() kernel API. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] mips: clean up 32/64-bit configurationRalf Baechle2005-09-051-2/+2
| | | | | | | | 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>
* [PATCH] mips: add MIPS-specific support for flatmem/discontigmemYoichi Yuasa2005-06-251-1/+1
| | | | | | | | | 2.6.12-git6 doesn't boot on some MIPS machines. They need the support of flat memory and discontig memory. Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+404
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!
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 15:15:15 +0000