Re: boot/wrap assumes a biarch toolchain?

2007-10-30 Thread Jan Dittmer
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Same error, you write above that a newer compiler version should not need -m32 or --with-cpu=default32 any more? ??? Where did I say that? Your mail from 2007-10-29 4:39 pm (CET) Your compiler still needs -m32 to generate

Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines

2007-10-30 Thread Luis R. Rodriguez
On 10/29/07, Dale Farnsworth [EMAIL PROTECTED] wrote: On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: This commit made an incorrect assumption: -- Author: Lennert Buytenhek [EMAIL PROTECTED] Date: Fri Oct 19 04:10:10 2007 +0200 mv643xx_eth: Move ethernet

Re: compile warning

2007-10-30 Thread Sergej Stepanov
thanks for your reply. WARNING: vmlinux.o(.text+0x10f5c): Section mismatch: reference to .init.text:cpm_muram_init (between 'cpm2_reset' and 'cpm2_smc_clk_setup') It should be fixed, but its highly unlikely you'll see a problem unless you start trying to build core parts of the CPM

Re: [PATCH] ehea: add kexec support

2007-10-30 Thread Christoph Raisch
Michael Ellerman [EMAIL PROTECTED] wrote on 28.10.2007 23:32:17: How do you plan to support kdump? When kexec is fully supported kdump should work out of the box as for any other ethernet card (if you load the right eth driver). There's nothing specific to kdump you have to handle in

Re: [Cbe-oss-dev] [PATCH] Fix build failure in platforms/celleb/setup.c which CONFIG_VIRT_CPU_ACCOUNTING is not defined.

2007-10-30 Thread Arnd Bergmann
On Tuesday 30 October 2007, Tony Breeds wrote: Without this patch I get the following build failure   CC      arch/powerpc/platforms/celleb/setup.o arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr' undeclared here (not in a function) Signed-off-by: Tony Breeds

Execute user program in kernel mode?

2007-10-30 Thread Wang, Baojun
hi, Is it possible to run user program (statically linked) in kernel mode? for example the user program entry is 0x1000, can we call it directly from kernel? I've tried many times, but I got the following Error(Oops): Oops: Exception in kernel mode, sig: 5 [#1] NIP: 1094 LR: 1094

Re: libfdt as its own repo and submodule of dtc?

2007-10-30 Thread Jon Loeliger
So, like, the other day Kumar Gala mumbled: Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for the projects that need to pull it in. Is this something you can take a look at?

[PATCH] using mii-bitbang on different processor ports

2007-10-30 Thread Sergej Stepanov
The patch makes possible to have mdio and mdc pins on different physical ports also for CONFIG_PPC_CPM_NEW_BINDING. To setup it in the device tree: reg = 10d40 14 10d60 14; // mdc-offset: 0x10d40, mdio-offset: 0x10d60 or reg = 10d40 14; // mdc and mdio have the same offset 0x10d40 The approach was

Re: boot/wrap assumes a biarch toolchain?

2007-10-30 Thread Jan Dittmer
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Your mail from 2007-10-29 4:39 pm (CET) Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). See the 'still' ? How would the compiler know whether to generate 64bit or

Re: boot/wrap assumes a biarch toolchain?

2007-10-30 Thread Jan Dittmer
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Your mail from 2007-10-29 4:39 pm (CET) Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). See the 'still' ? How would the compiler know whether to generate 64bit or

RE: RFC: replace device_type with new class property?

2007-10-30 Thread Yoder Stuart-B08248
Explicitly specifying what device class bindings / conventions the node complies with is cute, but not actually all that useful in practice. If it looks like a duck class device node, and it quacks^Whas the properties of a duck class device node, it's duck class compliant. Don't know how

Re: RFC: replace device_type with new class property?

2007-10-30 Thread Scott Wood
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote: mpic: [EMAIL PROTECTED] { clock-frequency = 0; interrupt-controller; #address-cells = 0; #interrupt-cells = 2; reg = 4 4; compatible = fsl,xyz; big-endian; } Note-- I

[PATCH 1/4] PowerPC: 440GRx Rainier bootwrapper.

2007-10-30 Thread Valentine Barshak
Bootwrapper code for PowerPC 440GRx Rainier board. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] --- arch/powerpc/boot/Makefile |3 + arch/powerpc/boot/cuboot-rainier.c | 56 + 2 files changed, 58 insertions(+), 1 deletion(-) diff -pruN

[PATCH 2/4] PowerPC: 440GRx Rainier DTS.

2007-10-30 Thread Valentine Barshak
PowerPC 440GRx Rainier DTS. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] --- arch/powerpc/boot/dts/rainier.dts | 312 ++ 1 files changed, 312 insertions(+) diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts

Re: [PATCH] using mii-bitbang on different processor ports

2007-10-30 Thread Sergej Stepanov
Hello Scott. Thank you for reply. Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood: On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote: You could just use of_iomap() for the second one, since we don't need the physical address for bus-id. Nice tip. Than it would be

[PATCH 3/4] PowerPC: 440GRx Rainier board support.

2007-10-30 Thread Valentine Barshak
PowerPC 440GRx Rainier board support. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] --- arch/powerpc/platforms/44x/Kconfig | 16 - arch/powerpc/platforms/44x/Makefile |3 + arch/powerpc/platforms/44x/rainier.c | 61 +++ 3 files changed, 78

[PATCH 4/4] PowerPC: 440GRx Rainier default config

2007-10-30 Thread Valentine Barshak
PowerPC 440GRx Rainier default config. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] --- arch/powerpc/configs/rainier_defconfig | 868 + 1 files changed, 868 insertions(+) diff -pruN linux-2.6.orig/arch/powerpc/configs/rainier_defconfig

Re: [PATCH] using mii-bitbang on different processor ports

2007-10-30 Thread Scott Wood
Sergej Stepanov wrote: Hello Scott. Thank you for reply. Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood: On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote: You could just use of_iomap() for the second one, since we don't need the physical address for bus-id.

[PATCH 0/4] PowerPC: 440GRx Rainier board support.

2007-10-30 Thread Valentine Barshak
The following patches add PowerPC 440GRx Rainier board support. The board is almost identical to Sequoia, but doesn't have USB and FPU is not supported. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org

Re: [PATCH 0/3] Add device-tree aware NDFC driver

2007-10-30 Thread Jörn Engel
On Tue, 30 October 2007 17:13:08 +0300, Valentine Barshak wrote: I'm not saying my approach is the best, but I was hoping for a discussion. That is good. So please take a moment to listen. I've reworked the patches according to the comments to the previous version and used my arguments to

Gianfar skb panic when bonding a VLAN interface

2007-10-30 Thread Demke Torsten-atd012
Hi, I tried to ping over a bonded VLAN tagged interface. (e.g - ifenslave bond0 eth3.24) This fails with following output: [EMAIL PROTECTED]:/root ping 192.168.24.101 PING 192.168.24.skb_under_panic: text:c01bbdf8 len:50 put:8 head:dd27a3a0 data:dd27a39a tail:dd27a3cc end:dd27a3e0 dev:eth3

Continued serial headaches

2007-10-30 Thread Alan Bennett
Well, now that I've got IRQs requestable, I'm back to battling SCC1 / SCC4 initialization, I've verified the iop structures, and things look set-up correctly. /* SCC1 */ {2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, {2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY}, {3, 29, CPM_PIN_OUTPUT |

Re: Continued serial headaches

2007-10-30 Thread Scott Wood
Alan Bennett wrote: Am I missing something in the PRAM areas? SMC1 (ttyCPM0...) e0008000 : 00c000e0 30300020 eefe3e7a e0008010 : 00c07331 11b6b05f 3044 07f4d082 e0008020 : 00e3 746562ec d98ceffd 0dec67e3 e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001 e0008040 :

[PATCH v2] using mii-bitbang on different processor ports

2007-10-30 Thread Sergej Stepanov
The patch makes possible to have mdio and mdc pins on different physical ports also for CONFIG_PPC_CPM_NEW_BINDING. To setup it in the device tree: reg = 10d40 14 10d60 14; // mdc: 0x10d40, mdio: 0x10d60 or reg = 10d40 14; // mdc and mdio have the same offset 10d40 The approach was taken from

[RFC] hotplug memory remove - walk_memory_resource for ppc64

2007-10-30 Thread Badari Pulavarty
Hi KAME, As I mentioned while ago, ppc64 does not export information about system RAM in /proc/iomem. Looking at the code and usage scenerios I am not sure what its really serving. Could you explain what its purpose how the range can be invalid ? At least on ppc64, all the memory ranges we get

RE: RFC: replace device_type with new class property?

2007-10-30 Thread Yoder Stuart-B08248
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, October 30, 2007 11:34 AM To: Yoder Stuart-B08248 Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org Subject: Re: RFC: replace device_type with new class property? On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder

Re: Gianfar skb panic when bonding a VLAN interface

2007-10-30 Thread Jay Vosburgh
Demke Torsten-atd012 [EMAIL PROTECTED] wrote: I tried to ping over a bonded VLAN tagged interface. (e.g - ifenslave bond0 eth3.24) [...] It seems that the skb headroom is to small. How can I solve this? I could insert skb_realloc_headroom() call, but where it's the best place then? What about

Re: RFC: replace device_type with new class property?

2007-10-30 Thread Grant Likely
On 10/30/07, Yoder Stuart-B08248 [EMAIL PROTECTED] wrote: Another good reason for device_type-- it helps distinguish between two similar classes of devices. Both open-pic and isa-pic look very similar but have different encodings of their interrupt cells. Without a device_type it may be

[patch 05/28] Add cmpxchg64 and cmpxchg64_local to powerpc

2007-10-30 Thread Mathieu Desnoyers
Make sure that at least cmpxchg64_local is available on all architectures to use for unsigned long long values. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] Acked-by: Paul Mackerras [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org --- include/asm-powerpc/system.h |6 ++ 1 file

Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.

2007-10-30 Thread Arnd Bergmann
On Tuesday 30 October 2007, Valentine Barshak wrote: +static struct of_device_id rainier_of_bus[] = { +   { .compatible = ibm,plb4, }, +   { .compatible = ibm,opb, }, +   { .compatible = ibm,ebc, }, +   {}, +}; + +static int __init rainier_device_probe(void) +{ +   if

Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.

2007-10-30 Thread Josh Boyer
On Tue, 30 Oct 2007 19:45:11 +0300 Valentine Barshak [EMAIL PROTECTED] wrote: The following patches add PowerPC 440GRx Rainier board support. The board is almost identical to Sequoia, but doesn't have USB and FPU is not supported. So why do we need anything other than the DTS and the

Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache

2007-10-30 Thread Benjamin Herrenschmidt
Fortunately, we don't support SMP on these or this solution wouldn't work. We should mark 44x BROKEN on SMP in Kconfig. Can we enable SMP on 44x at all currently ? No arch/ppc fix? I know we all want it to die as soon as possible, but still... :) Yeah, I didn't do it yet, which is

Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache

2007-10-30 Thread Josh Boyer
On Wed, 31 Oct 2007 07:16:31 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Fortunately, we don't support SMP on these or this solution wouldn't work. We should mark 44x BROKEN on SMP in Kconfig. Can we enable SMP on 44x at all currently ? Not without editing the

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

2007-10-30 Thread Wolfgang Denk
Hello Stefan, In message [EMAIL PROTECTED] you wrote: I already have it running on my system using a quick hack (see patch below) in include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean implementation, that has chances for upstream merge (in arch/powerpc later), I

PPC405GP Walnut irq patch

2007-10-30 Thread Steven A. Falco
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of the ethernet interrupts in the walnut.dts file doesn't match the documentation. I discovered this when porting the BSP to a custom board - the ethernet would not work. The attached patch corrects that. This is the first

Re: PPC405GP Walnut irq patch

2007-10-30 Thread Steven A. Falco
I realized that I should have done this from the root level. So here is the corrected patch. Signed-off-by: Steve Falco sfalco at harris.com Steven A. Falco wrote: Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of the ethernet interrupts in the walnut.dts file doesn't

[PATCH] [powerpc v2] update xmon slb code

2007-10-30 Thread Will Schmidt
[powerpc] update xmon slb code This adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the output for any slb entries that contain only zeros. sample output from

Re: [PATCH] ehea: add kexec support

2007-10-30 Thread Michael Ellerman
On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote: Michael Ellerman [EMAIL PROTECTED] wrote on 28.10.2007 23:32:17: How do you plan to support kdump? When kexec is fully supported kdump should work out of the box as for any other ethernet card (if you load the right eth

Re: RFC: replace device_type with new class property?

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote: Explicitly specifying what device class bindings / conventions the node complies with is cute, but not actually all that useful in practice. If it looks like a duck class device node, and it quacks^Whas the properties

Re: RFC: replace device_type with new class property?

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, October 30, 2007 11:34 AM To: Yoder Stuart-B08248 Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org Subject: Re: RFC: replace device_type

Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote: PowerPC 440GRx Rainier DTS. [snip] + SDRAM0: sdram { + device_type = memory-controller; How many times do we need to say it... Don't make up random device_type values. This does not belong

Re: RFC: replace device_type with new class property?

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote: [snip] Yeah.. what he said. The *only* substantive change with the class proposal is the fact that multiple classes can be specified. That's nice, but I don't think it's worth the trouble of attempting to define a

Re: libfdt as its own repo and submodule of dtc?

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote: Jon Loeliger wrote: So, like, the other day Kumar Gala mumbled: Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for

Re: [PATCH] [powerpc v2] update xmon slb code

2007-10-30 Thread Olof Johansson
On Tue, Oct 30, 2007 at 04:50:39PM -0500, Will Schmidt wrote: [powerpc] update xmon slb code This adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the

Re: [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values

2007-10-30 Thread Benjamin Herrenschmidt
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote: [Powerpc] fix switch_slb handling of 1T ESID values Now that we have 1TB segment size support, we need to be using the GET_ESID_1T macro when comparing ESID values for pc,stack, and unmapped_base within switch_slb().A new helper

Re: [PATCH] [powerpc v2] update xmon slb code

2007-10-30 Thread Benjamin Herrenschmidt
On Tue, 2007-10-30 at 16:50 -0500, Will Schmidt wrote: [powerpc] update xmon slb code This adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the output for

Re: [PATCH] [powerpc v2] update xmon slb code

2007-10-30 Thread Paul Mackerras
Will Schmidt writes: This adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the output for any slb entries that contain only zeros. sample output from power6

Re: PPC405GP Walnut irq patch

2007-10-30 Thread Josh Boyer
On Tue, 30 Oct 2007 17:41:27 -0400 Steven A. Falco [EMAIL PROTECTED] wrote: From: Steven A. Falco [EMAIL PROTECTED] To: linuxppc-dev@ozlabs.org Subject: Re: PPC405GP Walnut irq patch Date: Tue, 30 Oct 2007 17:41:27 -0400 Sender: [EMAIL PROTECTED] User-Agent: Thunderbird 2.0.0.5

Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.

2007-10-30 Thread Josh Boyer
On Tue, 30 Oct 2007 20:56:51 -0500 Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote: On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote: PowerPC 440GRx Rainier DTS. [snip] + SDRAM0: sdram { +

Re: libfdt as its own repo and submodule of dtc?

2007-10-30 Thread Jerry Van Baren
Jon Loeliger wrote: So, like, the other day Kumar Gala mumbled: Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for the projects that need to pull it in. Is this something you can

Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote: On Tue, 30 Oct 2007 20:56:51 -0500 Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote: On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote: PowerPC 440GRx

[0/2] Embed a copy of dtc in the kernel source

2007-10-30 Thread David Gibson
These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc. This respin embeds a newer revision of dtc, and incorporates Sam Ravnborg's preferred approach to Makefile integration.

Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.

2007-10-30 Thread Stephen Rothwell
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak [EMAIL PROTECTED] wrote: +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c2007-10-30 18:00:15.0 +0300 +#include linux/init.h +#include asm/machdep.h +#include asm/prom.h +#include asm/udbg.h +#include asm/time.h +#include

Re: [0/2] Embed a copy of dtc in the kernel source

2007-10-30 Thread Kumar Gala
On Oct 30, 2007, at 10:24 PM, David Gibson wrote: These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc. This respin embeds a newer revision of dtc, and incorporates Sam

Re: [0/2] Embed a copy of dtc in the kernel source

2007-10-30 Thread David Gibson
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote: On Oct 30, 2007, at 10:24 PM, David Gibson wrote: These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc.

Re: ring on PowerPC

2007-10-30 Thread Grant Likely
On 10/30/07, Bai Shuwei [EMAIL PROTECTED] wrote: Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to know wether there is a simple mechanism on the PowerPC

ring on PowerPC

2007-10-30 Thread Bai Shuwei
Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to know wether there is a simple mechanism on the PowerPC architecture? thx all! best regards! Buroc -- Add:

Re: ring on PowerPC

2007-10-30 Thread Benjamin Herrenschmidt
On Tue, 2007-10-30 at 23:18 -0600, Grant Likely wrote: On 10/30/07, Bai Shuwei [EMAIL PROTECTED] wrote: Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to

Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64

2007-10-30 Thread KAMEZAWA Hiroyuki
On Wed, 31 Oct 2007 14:28:46 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote: ioresource was good structure for remembering which memory is conventional memory and i386/x86_64/ia64 registered conventional memory as System RAM, when I posted patch. (just say System Ram is not for memory

[PATCH 2/2] [POWERPC] Fix region size check in mpc5200 FEC driver

2007-10-30 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED] Driver shouldn't complain if the register range is larger than what it expects. This works around failures with some device trees. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- drivers/net/fec_mpc52xx.c |4 ++-- 1 files changed, 2 insertions(+), 2

[PATCH 1/2] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver

2007-10-30 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED] When not building an arch/powerpc kernel, the mpc5200 FEC driver depends on some symbols which are not defined (BESTCOMM BESTCOMM_FEC). This patch flips around the dependancy logic so that it cannot be selected unless BESTCOMM_FEC is selected first. Kconfig

[PATCH] [POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M

2007-10-30 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED] mmu_mapin_ram() loops over total_lowmem to setup page tables. However, if total_lowmem is less that 16M, the subtraction rolls over and results in a number just under 4G (because total_lowmem is an unsigned value). This patch rejigs the loop from countup to