- 18 Oct, 2005 2 commits
-
-
Paul Mackerras authored
This makes ppc use the syscalls.c from arch/powerpc/kernel, exports copy_and_flush from head_32.S for use by prom_init.c (ARCH=powerpc), and consolidates the sys_fadvise64_64 implementations for 32-bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
- 17 Oct, 2005 11 commits
-
-
David Gibson authored
With ARCH=powerpc, a spurious ifdef in prom_init prevented the seconday hold loop being correctly copied down on Maple. With this patch, Maple boots with ARCH=powerpc Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
David Gibson authored
The merge-tree version of LOADBASE actually loads the whole given address from the toc for ppc64. The matching OFF macro adjust for this, using an offset of 0 for ppc64, but we weren't using that in power4_idle. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Kumar Gala authored
The _GLOBAL() macro is for text symbols only. Changed to using .globl for .data symbols. Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
... since all platforms will have a device tree. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
This introduces flush_{fp,altivec,spe}_to_thread and fixes a branch-too-far error in linking. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
We were initializing the btext stuff from prom_init(), thus breaking the rule that all communication between prom_init() and the rest of the kernel has to be via the flattened device tree. This removes the btext initialization calls from prom_init() and initializes it instead after the device tree is unflattened. It would be nice to do it earlier, but that needs some more infrastructure to find the properties we need in the flattened device tree. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Stephen Rothwell authored
instead of L1_CACHE_LINE_SIZE and LG_L1_CACHE_LINE_SIZE Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
I forgot a semicolon. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
- 14 Oct, 2005 5 commits
-
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
This allows us to simplify a couple of things. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
The only real user of this file outside platforms/iseries was drivers/net/iseries_veth.c but all it wanted was ISERIES_HV_ADDR() so we move that to abs_addr.h (and lowercase it). Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
- 13 Oct, 2005 5 commits
-
-
Stephen Rothwell authored
It will now give ppc64 on 64bit platforms and ppc on 32bit platforms. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
and use start_thread for both 32 and 64 bit bineries. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
- 12 Oct, 2005 9 commits
-
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
and use it in misc_32.S Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Also simplify arch/ppc64/kernel/Makefile Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Paul Mackerras authored
This removes three headers from include/asm-ppc64 that are now in include/asm-powerpc and are sufficiently similar that they can be used with ARCH=ppc64. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
Recent commits upstream have changed files which are currently duplicated in arch/powerpc and include/asm-powerpc. This updates them with the corresponding changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
We weren't computing the size of the hash table correctly on iSeries because the relevant code in prom.c was #ifdef CONFIG_PPC_PSERIES. This moves the code to hash_utils_64.c, makes it unconditional, and cleans it up a bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
-
Stephen Rothwell authored
On ARCH=ppc64 we were getting htab_hash_mask recalculated to the correct value for our particular machine by accident. In the merge tree, that code was commented out, so htab_hash_mask was being corrupted. We now set ppc64_pft_size instead which gets htab_has_mask calculated correctly for us later. We should put an ibm,pft-size property in the device tree at some point. Also set -mno-minimal-toc in some makefiles. Allow iSeries to configure PROC_DEVICETREE. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
- 11 Oct, 2005 8 commits
-
-
Linus Torvalds authored
-
David S. Miller authored
We were not doing alignment properly when remapping the kernel image. What we want is a 4MB aligned physical address to map at KERNBASE. Mistakedly we were 4MB aligning the virtual address where the kernel initially sits, that's wrong. Instead, we should PAGE align the virtual address, then 4MB align the physical address result the prom gives to us. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hugh Dickins authored
Refuse to install a page into a mapping if the mapping count is already ridiculously large. You probably cannot trigger this on 32-bit architectures, but on a 64-bit setup we should protect against it. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Peter Bergner authored
Newer gcc's are generating this relocation, so the module loader needs to handle it. Signed-off-by: Peter Bergner <bergner@vnet.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Michael Krufky authored
* bttv-cards.c: - Enable S-Video input on DViCO FusionHDTV5 Lite Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Hirokazu Takata authored
This patch prevents illegal traps from causing m32r kernel's infinite loop execution. Signed-off-by: Naoto Sugai <sugai@isl.melco.co.jp> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
akpm@osdl.org authored
Nir Tzachar <tzachar@cs.bgu.ac.il> points out that if an ELF file specifies a zero-length bss at a whacky address, we cannot load that binary because padzero() tries to zero out the end of the page at the whacky address, and that may not be writeable. See also http://bugzilla.kernel.org/show_bug.cgi?id=5411 So teach load_elf_binary() to skip the bss settng altogether if the elf file has a zero-length bss segment. Cc: Roland McGrath <roland@redhat.com> Cc: Daniel Jacobowitz <dan@debian.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paolo Galtieri authored
I've noticed that the calculations for seg_size and nr_segs in __dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong. The incorrect calculations can result in either an oops or a panic when running fsck depending on the size of the partition. The problem with the seg_size calculation is that it can result in a negative number if size is offset > size. The problem with the nr_segs caculation is returns the wrong number of segments, e.g. it returns 1 when size is 200 and offset is 4095, when it should return 2 or more. Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-