* Re: [PATCH] powerpc/86xx: Correct reading of information presented in cpuinfo
From: Kumar Gala @ 2009-08-07 2:44 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090630143226.10778.29002.stgit@ES-J7S4D2J.amer.consind.ge.com>
On Jun 30, 2009, at 9:32 AM, Martyn Welch wrote:
> /proc/cpuinfo should be showing the boards revision and the revision
> of the FPGA fitted. The functions currently used to access this
> information as incorrect.
>
> Additionally the VME geographical address of the PPC9A and it's
> status as system contoller are available in the board registers.
> Show these in cpuinfo.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/platforms/86xx/gef_ppc9a.c | 37 ++++++++++++++++++++++
> +++------
> 1 files changed, 30 insertions(+), 7 deletions(-)
applied to next.
(Fixed the comment formatting to wrap properly)
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards
From: Kumar Gala @ 2009-08-07 2:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090709183644.GA1614@oksana.dev.rtsoft.ru>
On Jul 9, 2009, at 1:36 PM, Anton Vorontsov wrote:
> This patch simply adds four eeprom nodes to MPC8548CDS' device tree.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8548cds.dts | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
applied to next.
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/83xx: Add support for MPC8377E-WLAN boards
From: Kumar Gala @ 2009-08-07 2:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090724214217.GA2718@oksana.dev.rtsoft.ru>
On Jul 24, 2009, at 4:42 PM, Anton Vorontsov wrote:
> MPC8377E-WLAN are basically RDB boards except:
>
> - RAM extended to 512 MB;
> - NAND flash removed, NOR flash extended to 64 MB;
> - Vitesse VSC7385 5-port switch removed, RTL8211B PHY added;
> - Power management MCU removed;
> - PCI slot removed, another mini-PCI slot added (IRQ routing changed);
> - USB3300 PHY's ID pin grounded, thus USB port is host-only.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8377_wlan.dts | 464 ++++++++++++++++++++
> +++++++++
> arch/powerpc/platforms/83xx/Kconfig | 4 +-
> arch/powerpc/platforms/83xx/mpc837x_rdb.c | 5 +-
> 3 files changed, 469 insertions(+), 4 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8377_wlan.dts
applied to next.
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards
From: Kumar Gala @ 2009-08-07 2:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090724214230.GB2718@oksana.dev.rtsoft.ru>
On Jul 24, 2009, at 4:42 PM, Anton Vorontsov wrote:
> Actually, the support is already there, but it requires newer U-Boots
> (to fill-in clock-frequency, and setup pin multiplexing).
>
> Though, it appears that on RDB boards USBB pins aren't multiplexed
> between USB and eSDHC (unlike MDS boards, where USB and eSDHC share
> pctl and pwrfault pins).
>
> So, for RDB boards we can safely setup pinmux and manually fill-in
> clock-frequency, thus making eSDHC work even with older u-boots.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
> arch/powerpc/platforms/83xx/mpc837x_rdb.c | 23 ++++++++++++++++++++
> +++
> arch/powerpc/platforms/83xx/mpc83xx.h | 4 ++++
> 5 files changed, 30 insertions(+), 3 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc/86xx: Update GE Fanuc sbc310 DTS
From: Kumar Gala @ 2009-08-07 2:38 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090730080651.27000.18194.stgit@ES-J7S4D2J.amer.consind.ge.com>
On Jul 30, 2009, at 3:13 AM, Martyn Welch wrote:
> Update GE Fanuc DTS to match the alterations suggested during the
> merge of
> the ppc9a DTS in commit 740d36ae6344f38c4da64c2ede765d7d2dd1f132
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> v2: Fixed run on message.
>
> Kumar: I think the problem may be that this patch depends on a
> previous patch:
>
> http://patchwork.ozlabs.org/patch/29335/
>
> Martyn
>
> arch/powerpc/boot/dts/gef_sbc310.dts | 29 ++++++++++++
> +----------------
> 1 files changed, 13 insertions(+), 16 deletions(-)
applied to next
For some reason in my tree the extra line at the end had already been
removed.
- k
^ permalink raw reply
* Re: [PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
From: Kumar Gala @ 2009-08-07 2:31 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev, david
In-Reply-To: <4A76931A.6@denx.de>
On Aug 3, 2009, at 2:34 AM, Heiko Schocher wrote:
> [PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
>
> - add I2C support
> - add FCC1 and FCC2 support
> - fix bogus gpio numbering in plattformcode
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> - against git://git.kernel.org/pub/scm/linux/kernel/git/benh/
> powerpc.git
> next branch
> - checked with checkpatch.pl:
> $ ./scripts/checkpatch.pl 0001-82xx-mgcoge-updates-for-2.6.32.patch
> total: 0 errors, 0 warnings, 147 lines checked
applied to next
- k
^ permalink raw reply
* Re: [PATCH v2 2/2] 82xx, mgcoge: update defconfig for 2.6.32
From: Kumar Gala @ 2009-08-07 2:31 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev, david
In-Reply-To: <4A769326.9090302@denx.de>
On Aug 3, 2009, at 2:35 AM, Heiko Schocher wrote:
> - add I2C support
> - add FCC1 and FCC2 support
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> - against git://git.kernel.org/pub/scm/linux/kernel/git/benh/
> powerpc.git
> next branch
> - checked with checkpatch.pl:
> $ ./scripts/checkpatch.pl 0002-82xx-mgcoge-update-defconfig-
> for-2.6.32.patch
> total: 0 errors, 0 warnings, 381 lines checked
I had problems applying this to my 'next' branch
- k
^ permalink raw reply
* Re: [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
From: Kumar Gala @ 2009-08-07 2:26 UTC (permalink / raw)
To: Julia Lawall; +Cc: linuxppc-dev, kernel-janitors, timur, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0908011052290.23408@ask.diku.dk>
On Aug 1, 2009, at 3:52 AM, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Error handling code following a kzalloc should free the allocated
> data.
>
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> // <smpl>
> @r exists@
> local idexpression x;
> statement S;
> expression E;
> identifier f,f1,l;
> position p1,p2;
> expression *ptr != NULL;
> @@
>
> x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x == NULL) S
> <... when != x
> when != if (...) { <+...x...+> }
> (
> x->f1 = E
> |
> (x->f1 == NULL || ...)
> |
> f(...,x->f1,...)
> )
> ...>
> (
> return \(0\|<+...x...+>\|ptr\);
> |
> return@p2 ...;
> )
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "* file: %s kmalloc %s return %s" %
> (p1[0].file,p1[0].line,p2[0].line)
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
> arch/powerpc/sysdev/qe_lib/qe_ic.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/ipic: unmask all interrupt sources
From: Kumar Gala @ 2009-08-07 2:26 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linuxppc-dev
In-Reply-To: <20090805194112.GA18204@www.tglx.de>
On Aug 5, 2009, at 2:41 PM, Sebastian Andrzej Siewior wrote:
> in case the interrupt controller was used in an earlier life then it
> is
> possible it is that some of its sources were used and are still
> unmask.
> If the (unmasked) device is active and is creating interrupts (or one
> interrupts was pending since the interrupts were disabled) then the
> boot
> process "ends" very soon. Once external interrupts are enabled, we
> land in
> -> do_IRQ
> -> call ppc_md.get_irq()
> -> ipic_read() gets the source number
> -> irq_linear_revmap(source)
> -> revmap[source] == NO_IRQ
> -> irq_find_mapping(source) returns NO_IRQ because no source
> is registered
> -> source is NO_IRQ, ppc_spurious_interrupts gets incremented, no
> further action.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> This solves my kexec problem I had earlier. I could disable the device
> in ->shutdown path but the device in question could been used in the
> boot loader. Usually one gets the "nobody cared" message for unhandled
> interrupts but in this (rare) case nothing happens and box stands
> still.
>
> arch/powerpc/sysdev/ipic.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [patch 2/3] powerpc/fsl-booke: read buffer overflow
From: Kumar Gala @ 2009-08-07 2:27 UTC (permalink / raw)
To: akpm; +Cc: roel.kluin, linuxppc-dev
In-Reply-To: <200908062300.n76N0bnS028871@imap1.linux-foundation.org>
On Aug 6, 2009, at 6:00 PM, akpm@linux-foundation.org wrote:
> From: Roel Kluin <roel.kluin@gmail.com>
>
> cam[tlbcam_index] is checked before tlbcam_index < ARRAY_SIZE(cam)
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/3] arch/powerpc: Add kmalloc NULL tests
From: Kumar Gala @ 2009-08-07 2:26 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0908062203380.19100@ask.diku.dk>
On Aug 6, 2009, at 3:04 PM, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Check that the result of kmalloc/kzalloc is not NULL before
> dereferencing it.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression *x;
> identifier f;
> constant char *C;
> @@
>
> x = \(kmalloc\|kcalloc\|kzalloc\)(...);
> ... when != x == NULL
> when != x != NULL
> when != (x || ...)
> (
> kfree(x)
> |
> f(...,C,...,x,...)
> |
> *f(...,x,...)
> |
> *x->f
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
> arch/powerpc/sysdev/fsl_rio.c | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/10] arch/powerpc: introduce missing kfree
From: Kumar Gala @ 2009-08-07 2:26 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0908021044330.15557@ask.diku.dk>
On Aug 2, 2009, at 3:44 AM, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Error handling code following a kzalloc should free the allocated
> data.
>
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> // <smpl>
> @r exists@
> local idexpression x;
> statement S;
> expression E;
> identifier f,f1,l;
> position p1,p2;
> expression *ptr != NULL;
> @@
>
> x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x == NULL) S
> <... when != x
> when != if (...) { <+...x...+> }
> (
> x->f1 = E
> |
> (x->f1 == NULL || ...)
> |
> f(...,x->f1,...)
> )
> ...>
> (
> return \(0\|<+...x...+>\|ptr\);
> |
> return@p2 ...;
> )
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "* file: %s kmalloc %s return %s" %
> (p1[0].file,p1[0].line,p2[0].line)
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
> arch/powerpc/sysdev/ipic.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* [PATCH] powerpc/85xx: Added 36-bit physical device tree for mpc8572ds board
From: Kumar Gala @ 2009-08-07 2:08 UTC (permalink / raw)
To: linuxppc-dev
Added a device tree that should be similiar to mpc8536ds.dtb except
the physical addresses for all IO are above the 4G boundary.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 467 +++++++++++++++++++++++++++++++
1 files changed, 467 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8536ds_36b.dts
diff --git a/arch/powerpc/boot/dts/mpc8536ds_36b.dts b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
new file mode 100644
index 0000000..113ed8b
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
@@ -0,0 +1,467 @@
+/*
+ * MPC8536 DS Device Tree Source
+ *
+ * Copyright 2008-2009 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "fsl,mpc8536ds";
+ compatible = "fsl,mpc8536ds";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ pci3 = &pci3;
+ };
+
+ cpus {
+ #cpus = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8536@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0 0>; // Filled by U-Boot
+ };
+
+ soc@fffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8536-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,mpc8536-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 0x2>;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,mpc8536-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 0x2>;
+ };
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 0x2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 0x2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ interrupts = <0 0x1>;
+ interrupt-parent = <&mpic>;
+ };
+ };
+
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8536-dma", "fsl,eloplus-dma";
+ reg = <0x21300 4>;
+ ranges = <0 0x21100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,mpc8536-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <20 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,mpc8536-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <21 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,mpc8536-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <22 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,mpc8536-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <23 2>;
+ };
+ };
+
+ usb@22000 {
+ compatible = "fsl,mpc8536-usb2-mph", "fsl-usb2-mph";
+ reg = <0x22000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <28 0x2>;
+ phy_type = "ulpi";
+ };
+
+ usb@23000 {
+ compatible = "fsl,mpc8536-usb2-mph", "fsl-usb2-mph";
+ reg = <0x23000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <46 0x2>;
+ phy_type = "ulpi";
+ };
+
+ enet0: ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x24000 0x1000>;
+ ranges = <0x0 0x24000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <29 2 30 2 34 2>;
+ interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi0>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x520 0x20>;
+
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <10 0x1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <10 0x1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ enet1: ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <1>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x26000 0x1000>;
+ ranges = <0x0 0x26000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <31 2 32 2 33 2>;
+ interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi1>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ usb@2b000 {
+ compatible = "fsl,mpc8536-usb2-dr", "fsl-usb2-dr";
+ reg = <0x2b000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <60 0x2>;
+ dr_mode = "peripheral";
+ phy_type = "ulpi";
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ crypto@30000 {
+ compatible = "fsl,sec3.0", "fsl,sec2.4", "fsl,sec2.2",
+ "fsl,sec2.1", "fsl,sec2.0";
+ reg = <0x30000 0x10000>;
+ interrupts = <45 2 58 2>;
+ interrupt-parent = <&mpic>;
+ fsl,num-channels = <4>;
+ fsl,channel-fifo-len = <24>;
+ fsl,exec-units-mask = <0x9fe>;
+ fsl,descriptor-types-mask = <0x3ab0ebf>;
+ };
+
+ sata@18000 {
+ compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
+ reg = <0x18000 0x1000>;
+ cell-index = <1>;
+ interrupts = <74 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ sata@19000 {
+ compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
+ reg = <0x19000 0x1000>;
+ cell-index = <2>;
+ interrupts = <41 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+
+ mpic: pic@40000 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ };
+
+ msi@41600 {
+ compatible = "fsl,mpc8536-msi", "fsl,mpic-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe0 0
+ 0xe1 0
+ 0xe2 0
+ 0xe3 0
+ 0xe4 0
+ 0xe5 0
+ 0xe6 0
+ 0xe7 0>;
+ interrupt-parent = <&mpic>;
+ };
+ };
+
+ pci0: pci@fffe08000 {
+ compatible = "fsl,mpc8540-pci";
+ device_type = "pci";
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 J17 Slot 1 */
+ 0x8800 0 0 1 &mpic 1 1
+ 0x8800 0 0 2 &mpic 2 1
+ 0x8800 0 0 3 &mpic 3 1
+ 0x8800 0 0 4 &mpic 4 1>;
+
+ interrupt-parent = <&mpic>;
+ interrupts = <24 0x2>;
+ bus-range = <0 0xff>;
+ ranges = <0x02000000 0 0xf0000000 0xc 0x00000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xffc00000 0 0x00010000>;
+ clock-frequency = <66666666>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe08000 0 0x1000>;
+ };
+
+ pci1: pcie@fffe09000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe09000 0 0x1000>;
+ bus-range = <0 0xff>;
+ ranges = <0x02000000 0 0xf8000000 0xc 0x18000000 0 0x08000000
+ 0x01000000 0 0x00000000 0xf 0xffc20000 0 0x00010000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <25 0x2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 4 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0xf8000000
+ 0x02000000 0 0xf8000000
+ 0 0x08000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@fffe0a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ bus-range = <0 0xff>;
+ ranges = <0x02000000 0 0xf8000000 0xc 0x10000000 0 0x08000000
+ 0x01000000 0 0x00000000 0xf 0xffc10000 0 0x00010000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <26 0x2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0xf8000000
+ 0x02000000 0 0xf8000000
+ 0 0x08000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@fffe0b000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe0b000 0 0x1000>;
+ bus-range = <0 0xff>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xffc30000 0 0x00010000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <27 0x2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 8 1
+ 0000 0 0 2 &mpic 9 1
+ 0000 0 0 3 &mpic 10 1
+ 0000 0 0 4 &mpic 11 1
+ >;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00100000>;
+ };
+ };
+};
--
1.6.0.6
^ permalink raw reply related
* [PATCH] powerpc/85xx: Move mpc8536ds.dts to address-cells/size-cells = <2>
From: Kumar Gala @ 2009-08-07 2:08 UTC (permalink / raw)
To: linuxppc-dev
Change the top-level #address-cells and #size-cells to <2> so the
mpc8536ds.dts is easier to deal with both a true 32-bit physical
or 36-bit physical address space.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8536ds.dts | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts b/arch/powerpc/boot/dts/mpc8536ds.dts
index e781ad2..22caf69 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -14,8 +14,8 @@
/ {
model = "fsl,mpc8536ds";
compatible = "fsl,mpc8536ds";
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
aliases {
ethernet0 = &enet0;
@@ -42,7 +42,7 @@
memory {
device_type = "memory";
- reg = <00000000 00000000>; // Filled by U-Boot
+ reg = <0 0 0 0>; // Filled by U-Boot
};
soc@ffe00000 {
@@ -50,7 +50,7 @@
#size-cells = <1>;
device_type = "soc";
compatible = "simple-bus";
- ranges = <0x0 0xffe00000 0x100000>;
+ ranges = <0x0 0 0xffe00000 0x100000>;
bus-frequency = <0>; // Filled out by uboot.
ecm-law@0 {
@@ -347,13 +347,13 @@
interrupt-parent = <&mpic>;
interrupts = <24 0x2>;
bus-range = <0 0xff>;
- ranges = <0x02000000 0 0x80000000 0x80000000 0 0x10000000
- 0x01000000 0 0x00000000 0xffc00000 0 0x00010000>;
+ ranges = <0x02000000 0 0x80000000 0 0x80000000 0 0x10000000
+ 0x01000000 0 0x00000000 0 0xffc00000 0 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xffe08000 0x1000>;
+ reg = <0 0xffe08000 0 0x1000>;
};
pci1: pcie@ffe09000 {
@@ -362,10 +362,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xffe09000 0x1000>;
+ reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 0xff>;
- ranges = <0x02000000 0 0x98000000 0x98000000 0 0x08000000
- 0x01000000 0 0x00000000 0xffc20000 0 0x00010000>;
+ ranges = <0x02000000 0 0x98000000 0 0x98000000 0 0x08000000
+ 0x01000000 0 0x00000000 0 0xffc20000 0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <25 0x2>;
@@ -398,10 +398,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xffe0a000 0x1000>;
+ reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 0xff>;
- ranges = <0x02000000 0 0x90000000 0x90000000 0 0x08000000
- 0x01000000 0 0x00000000 0xffc10000 0 0x00010000>;
+ ranges = <0x02000000 0 0x90000000 0 0x90000000 0 0x08000000
+ 0x01000000 0 0x00000000 0 0xffc10000 0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <26 0x2>;
@@ -434,10 +434,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xffe0b000 0x1000>;
+ reg = <0 0xffe0b000 0 0x1000>;
bus-range = <0 0xff>;
- ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x20000000
- 0x01000000 0 0x00000000 0xffc30000 0 0x00010000>;
+ ranges = <0x02000000 0 0xa0000000 0 0xa0000000 0 0x20000000
+ 0x01000000 0 0x00000000 0 0xffc30000 0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <27 0x2>;
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Shaohua Li @ 2009-08-07 1:02 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: Brown, Len, Peter Zijlstra, linux-kernel@vger.kernel.org,
Pallipadi, Venkatesh, Ingo Molnar, linuxppc-dev@lists.ozlabs.org,
Darrick J. Wong
In-Reply-To: <20090806134844.GA19146@in.ibm.com>
On Thu, Aug 06, 2009 at 09:48:44PM +0800, Gautham R Shenoy wrote:
> Hi Shaohua,
>
> On Thu, Aug 06, 2009 at 09:58:55AM +0800, Shaohua Li wrote:
> > Hi,
> >
> > On Wed, Aug 05, 2009 at 10:25:53PM +0800, Gautham R Shenoy wrote:
> > > In this patch-series, we propose to extend the CPU-Hotplug infrastructure
> > > and allow the system administrator to choose the desired state the CPU should
> > > go to when it is offlined. We think this approach addresses the concerns about
> > > determinism as well as transparency, since CPU-Hotplug already provides
> > > notification mechanism which the userspace can listen to for any change
> > > in the configuration and correspondingly readjust any previously set
> > > cpu-affinities.
> > Peter dislikes any approach (including cpuhotplug) which breaks userspace policy,
> > even userspace can get a notification.
>
> I think Peter's problem was more to do with the kernel offlining the CPUs
> behind the scenes, right ?
>
> We don't do that in this patch series. The option to offline the CPUs is
> very much with the admin. The patch-series only provides the interface
> that helps the admin choose the state the CPU must reside in when it
> goes offline.
but the goal is to use cpu offline to save power, right? So we still have
Peter's problem.
> > > Also, approaches such as [1] can make use of this
> > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > when it is offlined, thereby providing the system administrator a rope to hang
> > > himself with should he feel the need to do so.
> > I didn't see the reason why administrator needs to know which state offline cpu
> > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > C-state is already preferred.
>
> We can still provide a sane default value based on what states are
> available and what the BIOS limits us to. Thus we can still use the
> idle-state-offline patch that Venki posted sometime ago, right ?
My original concern about Venki's patch is the C-state limition, but Venki
thought if CPU has the limition, CPU should disable specific C-state, so this
isn't a problem. I had no objection about the infrastructure itself, but just
wonder why we need it.
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
From: Sean MacLennan @ 2009-08-06 23:30 UTC (permalink / raw)
To: Aggrwal Poonam-B10812; +Cc: linuxppc-dev, Felix Radensky, linuxppc-release
In-Reply-To: <1BD5CFC378ED0946B688E0C9BA2EF0951931A6@zin33exm24.fsl.freescale.net>
On Thu, 6 Aug 2009 17:04:18 +0530
"Aggrwal Poonam-B10812" <Poonam.Aggrwal@freescale.com> wrote:
> Can u point me to some reference of this, shud they be partition@0,
> partition@1, etc...
> I am not able to configure all the partitions successfully.
Not unless all your partitions are 1 byte long ;)
The number is the offset into the device. Here is an example partition
table from the warp:
partition@0 {
label = "kernel";
reg = <0x00000000 0x00200000>;
};
partition@200000 {
label = "root";
reg = <0x00200000 0x03E00000>;
};
partition@40000000 {
label = "persistent";
reg = <0x04000000 0x04000000>;
};
Cheers,
Sean
^ permalink raw reply
* [patch 3/3] powerpc: avoid calculating possibly-invalid address
From: akpm @ 2009-08-06 23:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, roel.kluin, bernd
From: Roel Kluin <roel.kluin@gmail.com>
Check whether index is within bounds prior to calculating a
possibly-invalid address.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Bernd Petrovitsch <bernd@firmix.at>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/char/hvsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN drivers/char/hvsi.c~powerpc-avoid-calculating-possibly-invalid-address drivers/char/hvsi.c
--- a/drivers/char/hvsi.c~powerpc-avoid-calculating-possibly-invalid-address
+++ a/drivers/char/hvsi.c
@@ -1230,11 +1230,12 @@ static struct tty_driver *hvsi_console_d
static int __init hvsi_console_setup(struct console *console, char *options)
{
- struct hvsi_struct *hp = &hvsi_ports[console->index];
+ struct hvsi_struct *hp;
int ret;
if (console->index < 0 || console->index >= hvsi_count)
return -1;
+ hp = &hvsi_ports[console->index];
/* give the FSP a chance to change the baud rate when we re-open */
hvsi_close_protocol(hp);
_
^ permalink raw reply
* [patch 1/3] powerpc: Sky CPU: redundant or incorrect tests on unsigned
From: akpm @ 2009-08-06 23:00 UTC (permalink / raw)
To: benh; +Cc: waite, roel.kluin, gorcunov, linuxppc-dev, galak, akpm
From: Roel Kluin <roel.kluin@gmail.com>
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Brian Waite <waite@skycomputers.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/misc/hdpuftrs/hdpu_cpustate.c | 5 -----
1 file changed, 5 deletions(-)
diff -puN drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned drivers/misc/hdpuftrs/hdpu_cpustate.c
--- a/drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
+++ a/drivers/misc/hdpuftrs/hdpu_cpustate.c
@@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
if (count == 0)
return 0;
@@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct fil
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
-
if (count == 0)
return 0;
_
^ permalink raw reply
* [patch 2/3] powerpc/fsl-booke: read buffer overflow
From: akpm @ 2009-08-06 23:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, roel.kluin
From: Roel Kluin <roel.kluin@gmail.com>
cam[tlbcam_index] is checked before tlbcam_index < ARRAY_SIZE(cam)
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/powerpc/mm/fsl_booke_mmu.c~powerpc-fsl-booke-read-buffer-overflow arch/powerpc/mm/fsl_booke_mmu.c
--- a/arch/powerpc/mm/fsl_booke_mmu.c~powerpc-fsl-booke-read-buffer-overflow
+++ a/arch/powerpc/mm/fsl_booke_mmu.c
@@ -161,7 +161,7 @@ unsigned long __init mmu_mapin_ram(void)
unsigned long virt = PAGE_OFFSET;
phys_addr_t phys = memstart_addr;
- while (cam[tlbcam_index] && tlbcam_index < ARRAY_SIZE(cam)) {
+ while (tlbcam_index < ARRAY_SIZE(cam) && cam[tlbcam_index]) {
settlbcam(tlbcam_index, virt, phys, cam[tlbcam_index], PAGE_KERNEL_X, 0);
virt += cam[tlbcam_index];
phys += cam[tlbcam_index];
_
^ permalink raw reply
* Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
From: Benjamin Herrenschmidt @ 2009-08-06 22:23 UTC (permalink / raw)
To: michael; +Cc: netdev, David Miller, linuxppc-dev
In-Reply-To: <1249395350.8016.5.camel@concordia>
On Wed, 2009-08-05 at 00:15 +1000, Michael Ellerman wrote:
> > c000000000600000 00001010 .long 0x1010
> > 0:mon>
> > c000000000600004 00000008 .long 0x8
> > c000000000600008 00001013 .long 0x1013
> > c00000000060000c 0000000f .long 0xf
> > c000000000600010 7961626f rldimi. r1,r11,44,41
> > c000000000600014 6f740000 xoris r20,r27,0
> > c000000000600018 00101600 .long 0x101600
> > c00000000060001c 00000c00 .long 0xc00
> > c000000000600020 00000400 .long 0x400
> > c000000000600024 00101100 .long 0x101100
> > c000000000600028 000008e9 .long 0x8e9
BTW. Corruption looks like bi_recs... ie, broken yaboot. This was fixed
recently, yaboot would eventually crap over the kernel for certain sizes
of the kernel image.
0x1010 = BI_FIRST
0x1013 = BI_BOOTLOADER_ID followed by 0x7961626f6f74 which is
"yaboot" :-)
0x1016 = BI_MACHTYPE
etc...
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.31-rc5-git2 crash on a idle system.
From: Benjamin Herrenschmidt @ 2009-08-06 21:51 UTC (permalink / raw)
To: Sachin Sant; +Cc: neilb, linuxppc-dev, linux-raid
In-Reply-To: <4A7ADBB1.3050906@in.ibm.com>
On Thu, 2009-08-06 at 19:03 +0530, Sachin Sant wrote:
> I added few printks in the initcall debug code patch. The o/p suggests
> that by the time first initicall debug message is printed the code is
> already corrupted. Further debug suggests, when start_kernel() is
> called the code at address(0xc000000000600000) is already corrupted.
> About 28 bytes of code starting from the above address is
> overwritten.
>
> I will try to add few more debug statements to find the place where
> this corruption might me happening.
Hrm... start_kernel is very very early... strange. Can you double check
that the actual kernel image contains the right stuff ? Also, what
distro are you using to test that and how are you booting that kernel ?
You can always add something to prom_init.c to test (though beware you
aren't relocated yet so you need to offset the addresses).
Cheers,
Ben.
^ permalink raw reply
* [PATCH 1/3] arch/powerpc: Add kmalloc NULL tests
From: Julia Lawall @ 2009-08-06 20:04 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Check that the result of kmalloc/kzalloc is not NULL before dereferencing it.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression *x;
identifier f;
constant char *C;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x->f
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/fsl_rio.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index cbb3bed..598789c 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1057,6 +1057,10 @@ int fsl_rio_setup(struct of_device *dev)
law_start, law_size);
ops = kmalloc(sizeof(struct rio_ops), GFP_KERNEL);
+ if (!ops) {
+ rc = -ENOMEM;
+ goto err_ops;
+ }
ops->lcread = fsl_local_config_read;
ops->lcwrite = fsl_local_config_write;
ops->cread = fsl_rio_config_read;
@@ -1064,6 +1068,10 @@ int fsl_rio_setup(struct of_device *dev)
ops->dsend = fsl_rio_doorbell_send;
port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
+ if (!port) {
+ rc = -ENOMEM;
+ goto err_port;
+ }
port->id = 0;
port->index = 0;
@@ -1071,7 +1079,7 @@ int fsl_rio_setup(struct of_device *dev)
if (!priv) {
printk(KERN_ERR "Can't alloc memory for 'priv'\n");
rc = -ENOMEM;
- goto err;
+ goto err_priv;
}
INIT_LIST_HEAD(&port->dbells);
@@ -1169,13 +1177,15 @@ int fsl_rio_setup(struct of_device *dev)
return 0;
err:
- if (priv)
- iounmap(priv->regs_win);
- kfree(ops);
+ iounmap(priv->regs_win);
+err_priv:
kfree(priv);
+err_port:
kfree(port);
+err_ops:
+ kfree(ops);
return rc;
}
^ permalink raw reply related
* Re: MPC8313 performance evaluation
From: Kumar Gala @ 2009-08-06 19:16 UTC (permalink / raw)
To: Lutz Jaenicke; +Cc: linuxppc-dev
In-Reply-To: <20090806180035.GA19088@lutz.bln.innominate.local>
On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
> Hi!
>
> I am currently evaluating the performance of the MPC8313E for firewall
> (and VPN) purposes.
> The results obtained do not match my expectations so I would be
> interested
> in some discussion.
>
> Test setup:
> -----------
> A linux 2.6.27 based firewall software is used. The software is the
> same among
> To be replaced: IXP42x custom made board (266MHz and 533MHz)
> * MPC8343 custom made board (400MHz)
> * MPC8313E-RDB Rev. C (333/333)
> As a software firewall the throughput is determined by looking into
> the routing information and IP headers, hence the performance is best
> characterized by "frames/s" which is constant over the frame size
> (as long as no limit is hit like the 100Mbit/s limit on the IXP42x).
>
> With the MPC8343@400MHz I get a throughput of approx. 24500 frames/s
> using the predefined firewall rules.
> With the MPC8313 I get a significantly lower value:
> MPC8313@250MHz 12500fps
> MPC8313@333MHz 14500fps
> MPC8313@416MHz 15500fps (333MHz type, overclocked)
> Kernel 2.6.27 with SKB recycling from later versions and the
> e300c2/c3/c4 TLB errata workaround. Some pure computational benchmark
> with small footprint (namely "openssl speed") which should fit into
> the cache size indicates the perfect 3/4/5 ratio used.
>
> Some discussion with the the freescale rep. lead to the CSB frequency
> of the 8313 (166MHz) being significantly lower than that of the 8343.
> Is the CSB the critical point here?
> Note: the IXP42x uses an internal bus speed of 133MHz and operates
> at frame rates similar to the 8343...
>
> Does anybody else have numbers for a firewall scenario using 8313
> and/or other processors of the family?
>
> Best regards,
> Lutz
> PS: Yes, I know that absolute numbers will be hard to compare with
> other scenarios but relative values would be quite interesting as
> well.
What DDR frequencies (and width) are you running the 8343 vs 8313 at.
This can have a significant impact on performance.
- k
^ permalink raw reply
* MPC8313 performance evaluation
From: Lutz Jaenicke @ 2009-08-06 18:00 UTC (permalink / raw)
To: linuxppc-dev
Hi!
I am currently evaluating the performance of the MPC8313E for firewall
(and VPN) purposes.
The results obtained do not match my expectations so I would be interested
in some discussion.
Test setup:
-----------
A linux 2.6.27 based firewall software is used. The software is the
same among
To be replaced: IXP42x custom made board (266MHz and 533MHz)
* MPC8343 custom made board (400MHz)
* MPC8313E-RDB Rev. C (333/333)
As a software firewall the throughput is determined by looking into
the routing information and IP headers, hence the performance is best
characterized by "frames/s" which is constant over the frame size
(as long as no limit is hit like the 100Mbit/s limit on the IXP42x).
With the MPC8343@400MHz I get a throughput of approx. 24500 frames/s
using the predefined firewall rules.
With the MPC8313 I get a significantly lower value:
MPC8313@250MHz 12500fps
MPC8313@333MHz 14500fps
MPC8313@416MHz 15500fps (333MHz type, overclocked)
Kernel 2.6.27 with SKB recycling from later versions and the
e300c2/c3/c4 TLB errata workaround. Some pure computational benchmark
with small footprint (namely "openssl speed") which should fit into
the cache size indicates the perfect 3/4/5 ratio used.
Some discussion with the the freescale rep. lead to the CSB frequency
of the 8313 (166MHz) being significantly lower than that of the 8343.
Is the CSB the critical point here?
Note: the IXP42x uses an internal bus speed of 133MHz and operates
at frame rates similar to the 8343...
Does anybody else have numbers for a firewall scenario using 8313
and/or other processors of the family?
Best regards,
Lutz
PS: Yes, I know that absolute numbers will be hard to compare with
other scenarios but relative values would be quite interesting as
well.
--
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG /protecting industrial networks/
tel: +49.30.921028-200
fax: +49.30.921028-020
Rudower Chaussee 13
D-12489 Berlin, Germany
www.innominate.com
Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Volker Bibelhausen
^ permalink raw reply
* need help getting SPI controller working on 405EX
From: Nathan French @ 2009-08-06 16:08 UTC (permalink / raw)
To: linuxppc-dev
Hi, I am trying to add support for the 405EX's SPI controller on a Kilauea board. I've added the below to the device tree (under plb/opb/):
[nfrench@nfrench-laptop linux-2.6-denx]$ diff -C2 arch/powerpc/boot/dts/kilauea.dts spi.dts
*** arch/powerpc/boot/dts/kilauea.dts 2009-05-05 15:56:16.000000000 -0700
--- spi.dts 2009-08-06 08:42:19.000000000 -0700
***************
*** 207,210 ****
--- 207,221 ----
#size-cells = <0>;
};
+
+ SPI0: spi@ef600600 {
+ cell-index = <0>;
+ compatible = "ibm,spi-405ex", "ibm,spi";
+ reg = <ef600600 6>;
+ interrupts = <8 4>;
+ interrupt-parent = <&UIC0>;
+ mode = "cpu";
+ };
RGMII0: emac-rgmii@ef600b00 {
I've also compiled my kernel with the following enabled:
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_SPIDEV=y
I see this make it into the device tree after boot:
[root@10.2.3.28 /]$ find /proc/device-tree/ | grep spi
/proc/device-tree/plb/opb/spi@ef600600
/proc/device-tree/plb/opb/spi@ef600600/name
/proc/device-tree/plb/opb/spi@ef600600/mode
/proc/device-tree/plb/opb/spi@ef600600/interrupt-parent
/proc/device-tree/plb/opb/spi@ef600600/interrupts
/proc/device-tree/plb/opb/spi@ef600600/reg
/proc/device-tree/plb/opb/spi@ef600600/compatible
/proc/device-tree/plb/opb/spi@ef600600/cell-index
But I don't see any /dev/spidev* devices created or any mention of SPI
at boot time. I'm starting to suspect that I don't have the kernel
configured right, otherwise I would see at least the SPI driver
complaining about something, right?
Thanks,
Nathan French
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox