- 29 Oct, 2005 9 commits
-
-
scwhab@suse.de authored
Provide a "compatible" entry in /sys/bus/macio/devices/*/ This can be used to load drivers via the modules.alias file. Signed-off-by: Olaf Hering <olh@suse.de> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Olaf Hering authored
This implements a nvram acccess method, similar to arch/ppc64/kernel/pSeries_nvram.c tested on CHRP B50. Signed-off-by: Olaf Hering <olh@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Roland Dreier authored
Change the phys_mem_access_prot() function to take a pfn instead of an address. This allows mmap64() to work on /dev/mem for addresses above 4G on 32-bit architectures. We start with a pfn in mmap_mem(), so there's no need to convert to an address; in fact, it's actively bad, since the conversion can overflow when the address is above 4G. Similarly fix the ppc32 page_is_ram() function to avoid a conversion to an address by directly comparing to max_pfn. Working with max_pfn instead of high_memory fixes page_is_ram() to give the right answer for highmem pages. Signed-off-by: Roland Dreier <rolandd@cisco.com> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Olaf Hering authored
Mention a few more commands in xmon. System.map processing was replaced with kallsyms. Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Marcelo Tosatti authored
#ifdef out an ALTIVEC specific tweak in __switch_to() Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Matt Porter authored
Cleanup PPC440 eval boards (bamboo, ebony, luan and ocotea) to better support U-Boot as bootloader. Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Marcelo Tosatti authored
Here is an uptodated version of the MPC8xx PCMCIA driver for v2.6, addressing comments by Jeff and Dominik: - use IO accessors instead of direct device memory referencing - avoid usage of non-standard "uint/uchar" data types - kill struct typedef's Will submit it for inclusion once v2.6.14 is out. Testing on 8xx platforms is more than welcome! Works like a charm on our custom hardware (CONFIG_PRxK). Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Marcelo Tosatti authored
Convert core 8xx drivers to use in_xxxbe/in_xxx macros instead of direct memory references. Other than making IO accesses explicit (which is a plus for readability), a common set of macros provides a unified place for the volatile flag to constraint compiler code reordering. There are several unlucky places at the moment which lack the volatile flag. Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Lee Nicks authored
Depending on how GCC is built, GCC 4 may generate altivec instructions without user explicitly requesting vector operations in the code. Although this is a performance booster for user applications, it is a problem for kernel. This patch explicitly instruct GCC to NOT generate altivec instructions while building the kernel. Here are some test cases I ran. (1) build gcc 4.0.1 with '--with-cpu=7450 --enable-altivec --enable-cxx-flags=-mcpu=7450', and use this gcc to build kernel WITHOUT this kernel patch. Kernel fail to boot up on a 7450 board because of altivec instructions in kernel. (2) build gcc 4.0.1 with "--with-cpu=7450 --enable-altivec --enable-cxx-flags=-mcpu=7450", and use this gcc to build kernel WITH this kernel patch. Kernel boot up on a 7450 board without any problem. (3) build gcc 4.0.1 with "--with-cpu=750 --enable-cxx-flags=-mcpu=750", and use this gcc to build kernel with or without this kernel patch. Kernel boot up on a 7450 board without any problem. This patch should also work with GCC 3 or even earlier GCC 2.95.3. Signed-off-by: Lee Nicks <allinux@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
- 28 Oct, 2005 21 commits
-
-
Paul Mackerras authored
The merged version follows the ppc64 version pretty closely mostly, and in fact ARCH=ppc64 now uses the arch/powerpc/xmon version. The main difference for ppc64 is that the 'p' command to call show_state (which was always pretty dodgy) has been replaced by the ppc32 'p' command, which calls a given procedure (so in fact the old 'p' command behaviour can be achieved with 'p $show_state'). Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
The sc instruction emulation can't be done the same way on 32-bit as 64-bit yet, but this should work OK. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
... for consistency with 64-bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
David Gibson authored
This patch moves the XICS interrupt controller code into the platforms/pseries directory, since it only appears on pSeries machines. If it ever appears on some other machine we can move it to sysdev, although xics.c itself will need a bunch of changes in that case to remove pSeries specific assumptions. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
-
Paul Mackerras authored
-
Stephen Rothwell authored
and remove the same bits from ppc64/lib/string.S. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to usercopy.c from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to strcase.c from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to sstep.c from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to mempcy.S from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is effectively the same as locks.c from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to copyuser.S from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to copypage.S from ppc64/lib. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
since it is identical to e2a.c from ppc64/lib Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
as it is identical to checksum.S from ppc64. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
This allows us to also use entry_64.S from the merged tree and reverts the setup_64.c part of fda262b8. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
-
Paul Mackerras authored
We still had an old copy of i8259.h lying around; this gets rid of it and corrects the callers of i8259_init and i8259_irq. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
David Gibson authored
Since I sent the patch to purge bootinfo.h from ARCH=powerpc and ARCH=ppc64, setup-common.c has come into existence, and another #include of bootinfo.h slipped in. This patch removes it. It also removes include/asm-ppc64/bootinfo.h, which somehow survived the previous patch which was supposed to remove it. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Kumar Gala authored
For the current time idle_6xx only applies to 6xx ppc32 CPUs Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Linus Torvalds authored
"Better late than never"
-
- 27 Oct, 2005 10 commits
-
-
Linus Torvalds authored
-
Dave Jones authored
Don't try to access not-present CPUs. Conservative governor will always oops on SMP without this fix. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=4781Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
Commit id 6142891a Andi Kleen reports that it seems to break things for some people, and since it's purely a small optimization, revert it for now. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
... which is needed now that ARCH=ppc64 is using the merged setup_64.c. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Herbert Xu authored
This bug is responsible for causing the infamous "Treason uncloaked" messages that's been popping up everywhere since the printk was added. It has usually been blamed on foreign operating systems. However, some of those reports implicate Linux as both systems are running Linux or the TCP connection is going across the loopback interface. In fact, there really is a bug in the Linux TCP header prediction code that's been there since at least 2.1.8. This bug was tracked down with help from Dale Blount. The effect of this bug ranges from harmless "Treason uncloaked" messages to hung/aborted TCP connections. The details of the bug and fix is as follows. When snd_wnd is updated, we only update pred_flags if tcp_fast_path_check succeeds. When it fails (for example, when our rcvbuf is used up), we will leave pred_flags with an out-of-date snd_wnd value. When the out-of-date pred_flags happens to match the next incoming packet we will again hit the fast path and use the current snd_wnd which will be wrong. In the case of the treason messages, it just happens that the snd_wnd cached in pred_flags is zero while tp->snd_wnd is non-zero. Therefore when a zero-window packet comes in we incorrectly conclude that the window is non-zero. In fact if the peer continues to send us zero-window pure ACKs we will continue making the same mistake. It's only when the peer transmits a zero-window packet with data attached that we get a chance to snap out of it. This is what triggers the treason message at the next retransmit timeout. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
-
Roland McGrath authored
This just makes sure that a thread's expiry times can't get reset after it clears them in do_exit. This is what allowed us to re-introduce the stricter BUG_ON() check in a362f463. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
This reverts commit 3de463c7. Roland has another patch that allows us to leave the BUG_ON() in place by just making sure that the condition it tests for really is always true. That goes in next. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
My G5 was being reported as an OldWorld in /proc/cpuinfo, which is obviously not right... :) Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
On 32-bit platforms, these convert from kernel virtual addresses to real (physical addresses), like tophys/tovirt but they use the same register for the source and destination. On 64-bit platforms, they do nothing because the hardware ignores the top two bits of the address in real mode. These new macros are used in fpu.S now. Signed-off-by: Paul Mackerras <paulus@samba.org>
-