aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ppc/kernel
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] ppc user annotations: debug_setconetext(2)Al Viro2005-04-251-1/+1
| | | | | | | 3rd argument of sys_debug_setcontext() is also a userland pointer. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc sparse annotations: emulate_string_inst()Al Viro2005-04-251-1/+1
| | | | | | | | | replaced declaration of EA from u32 to unsigned long - this beast is used only to cast it to (userland) pointer and proper integer type for that is unsigned long. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc iomem annotations: ->io_base_virtAl Viro2005-04-251-1/+1
| | | | | | | | | | | | | | | * ->io_base_virt in struct pci_controller is iomem pointer. Marked as such. Most of the places that used it are already annotated to expect iomem. * places that did gratitious (and wrong) casts a-la isa_io_base = (unsigned long)ioremap(...); hose->io_base_virt = (void *)isa_io_base; turned into hose->io_base_virt = ioremap(...); isa_io_base = (unsigned long)hose->io_base_virt; * pci_bus_io_base() annotated as returning iomem pointer. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc user annotations: sigcontextAl Viro2005-04-251-1/+1
| | | | | | | sigcontext.regs is a userland pointer Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: fix compilation error in arch/ppc/kernel/time.cBenoit Boissinot2005-04-161-2/+0
| | | | | | | | | | | | | | | make defconfig give the following error on ppc (gcc-4): arch/ppc/kernel/time.c:92: error: static declaration of ‘time_offset’ follows non-static declaration include/linux/timex.h:236: error: previous declaration of ‘time_offset’ was here The following patch solves it (time_offset is declared in timer.c). Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: Fix a problem with NTP on !(chrp||gemini)Giovambattista Pulcini2005-04-161-1/+0
| | | | | | | | | | | | | | | | The following problem was found by Giovambattista Pulcini <gpulcini@swintel.it>, who also provided a partial patch, and this has been verified by our time guru Gabriel Paubert <paubert@iram.es>. The problem is that in do_settimeofday() we always set time_state to TIME_ERROR and except on two platforms, never re-set it. This meant that ntp_gettime() and ntp_adjtime() always returned TIME_ERROR, incorrectly. Based on Gabriel's analysis, time_state is used for leap-second processing, and ppc shouldn't be mucking with it. Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: Support 36-bit physical addressing on e500Kumar Gala2005-04-161-40/+73
| | | | | | | | | | | | | | | | | | | | | | | | To add support for 36-bit physical addressing on e500 the following changes have been made. The changes are generalized to support any physical address size larger than 32-bits: * Allow FSL Book-E parts to use a 64-bit PTE, it is 44-bits of pfn, 20-bits of flags. * Introduced new CPU feature (CPU_FTR_BIG_PHYS) to allow runtime handling of updating hardware register (SPRN_MAS7) which holds the upper 32-bits of physical address that will be written into the TLB. This is useful since not all e500 cores support 36-bit physical addressing. * Currently have a pass through implementation of fixup_bigphys_addr * Moved _PAGE_DIRTY in the 64-bit PTE case to free room for three additional storage attributes that may exist in future FSL Book-E cores and updated fault handler to copy these bits into the hardware TLBs. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: fix single-stepping of emulated instructionsPaul Mackerras2005-04-161-0/+1
| | | | | | | | | | | | On ppc, we emulate instructions that cause alignment exceptions. If we are single-stepping an instruction and it causes an alignment exception, we will currently do the next instruction as well before taking the single-step exception. This patch fixes that, so we take the single-step exception after emulating the instruction. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: oops on kernel altivec assist exceptionsPaul Mackerras2005-04-161-0/+7
| | | | | | | | | | | | | | | If we should happen to get an altivec assist exception while executing in the kernel, we will currently try to handle it and fail, and end up oopsing with (apparently) a segfault. (An altivec assist exception occurs for floating-point altivec instructions with denormalized inputs or outputs if the altivec unit is in java mode.) This patch checks explicitly if we are in user mode and prints a useful message if not. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: fix bogosity in process-freezing codePaul Mackerras2005-04-161-3/+1
| | | | | | | | | | | The code that went into arch/ppc/kernel/signal.c recently to handle process freezing seems to contain a dubious assumption: that a process that calls do_signal when PF_FREEZE is set will have entered the kernel because of a system call. This patch removes that assumption. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2Linus Torvalds2005-04-1645-0/+22654
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!