Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586 +
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 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,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch. Also, are you sure
the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR (RO) Vitesse-7385 Firmware;
+ read-only;
+ };
Partitions should be declared as
partit...@0 {
reg = ...
label = ...
...
}
Felix.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 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,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR (RO) Vitesse-7385
Firmware;
+ read-only;
+ };
Partitions should be declared as
partit...@0 {
reg = ...
label = ...
...
}
Doing it this way is good from readability perspective, but we generally
do not use this convention in our platforms eg 8572DS, etc
Regards
Poonam
Felix.
Re: [PATCH] powerpc/perfctr: Check oprofile_cpu_type for NULL before using it
On Thu, 2009-08-06 at 14:02 +1000, Benjamin Herrenschmidt wrote: If the current CPU doesn't support performance counters, cur_cpu_spec-oprofile_cpu_type can be NULL. The current perfctr modules don't test for that case and would thus crash. It can't actually be NULL on a 64-bit CPU; all 64-bit CPUs in the table have -oprofile_cpu_type set. Of course, adding the check probably makes sense anyway. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 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,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+/* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+label = NOR (RO) Vitesse-7385
Firmware;
+ read-only;
+ };
Partitions should be declared as
partit...@0 {
reg = ...
label = ...
...
}
Doing it this way is good from readability perspective, but
Re: [PATCH] powerpc/perfctr: Check oprofile_cpu_type for NULL before using it
On Thu, 2009-08-06 at 07:41 +0100, David Woodhouse wrote: On Thu, 2009-08-06 at 14:02 +1000, Benjamin Herrenschmidt wrote: If the current CPU doesn't support performance counters, cur_cpu_spec-oprofile_cpu_type can be NULL. The current perfctr modules don't test for that case and would thus crash. It can't actually be NULL on a 64-bit CPU; all 64-bit CPUs in the table have -oprofile_cpu_type set. today :-) Of course, adding the check probably makes sense anyway. Yup, better safe. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs
.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list
s.ozlabs.org] On Behalf Of Felix Radensky
Sent: Thursday, August 06, 2009 12:16 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org;
linuxppc-rele...@webnode01-prod1.am.freescale.net
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 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,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the
size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR
Re: kexec on e300 core / mpc5121
* Kenneth Johansson | 2009-08-06 02:20:50 [+0200]: Is it not possible to disable the mmu on all cpu's that have one ?? No, on e500 for example it is always on. You can use large pages with identity maps to make it seem like it's off, though. why do something like that ? on e500 you simply can't disable the mmu. It is always on even if you come out of reset. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
uio driver cannot be registered to uio subsystem
Hi everbody,
I've got an custom uio interrupt driver. The driver will be registered
as platfrom driver.
static int __init uio_irq3_init(void)
{
return platform_driver_register(uio_irq3_driver);
}
After starting the kernel the driver is registered under
/sys/bus/platform/drivers. (I guess this is supposed to happen)
BUT as I can see the uio_irq3_probe() function isn't called and
therefore the driver will not be registered to the
UIO subsystem! (there are no devices in /sys/class/)
What went wrong? Which process is responsible for calling the probe
function?
I also tried to compile the uio drivers which are provided by the kernel
itself. But after starting the kernel not one of these drivers appears
in /sys/class/ too!
Can anybody please tell what I am doing wrong? Pls see below, too!
Thanks in advance!
Kind regrads
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Here is the code for the driver if needed!
--- snip
#include linux/uio_driver.h
#include linux/platform_device.h
#include linux/module.h
struct uio_pdrv_irq3 {
struct uio_info *uioinfo;
spinlock_t lock;
unsigned long flags;
};
static irqreturn_t interrupt_handler_irq3(int irq, struct uio_info
*dev_info)
{
eturn IRQ_HANDLED;
}
static int uio_irq3_irqcontrol(struct uio_info *dev_info, s32 irq_on)
{
printk(IRQCONTROL);
return 0;
}
static int uio_irq3_probe(struct platform_device *pdev)
{
struct uio_info *uioinfo = pdev-dev.platform_data;
struct uio_pdrv_irq3 *priv;
int ret = -EINVAL;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
dev_err(pdev-dev, unable to kmalloc\n);
goto bad0;
}
priv-uioinfo = uioinfo;
priv-flags = 0;
uioinfo-irq_flags |= IRQF_DISABLED | IRQF_TRIGGER_FALLING;
uioinfo-irq = 19;
uioinfo-handler = interrupt_handler_irq3;
uioinfo-irqcontrol = uio_irq3_irqcontrol;
uioinfo-priv = priv;
uio_register_device(pdev-dev, priv-uioinfo);
return -ENODEV;
platform_set_drvdata(pdev, priv);
return 0;
bad0:
return ret;
}
static int uio_irq3_remove(struct platform_device *pdev)
{
struct uio_pdrv_irq3 *priv = platform_get_drvdata(pdev);
uio_unregister_device(priv-uioinfo);
return 0;
}
static struct platform_driver uio_irq3_driver = {
.probe = uio_irq3_probe,
.remove = uio_irq3_remove,
.driver = {
.name = IRQ3,
.owner = THIS_MODULE,
},
};
static int __init uio_irq3_init(void)
{
return platform_driver_register(uio_irq3_driver);
}
static void __exit uio_irq3_exit(void)
{
platform_device_unregister(uio_irq3_driver);
}
module_init(uio_irq3_init);
module_exit(uio_irq3_exit);
MODULE_LICENSE(tbd);
MODULE_AUTHOR(tbd);
MODULE_DESCRIPTION(IRQ3 Interrupt Handler - CPLD Interrupts);
--- snap
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/perfctr: Check oprofile_cpu_type for NULL before using it
On Thu, 2009-08-06 at 14:02 +1000, Benjamin Herrenschmidt wrote:
If the current CPU doesn't support performance counters,
cur_cpu_spec-oprofile_cpu_type can be NULL. The current
perfctr modules don't test for that case and would thus
crash.
+ if (!cur_cpu_spec-oprofile_cpu_type ||
..
+ if (!cur_cpu_spec-oprofile_cpu_type ||
..
+ if (!cur_cpu_spec-oprofile_cpu_type ||
..
+ if (!cur_cpu_spec-oprofile_cpu_type ||
..
+ if (!cur_cpu_spec-oprofile_cpu_type ||
..
+ if (!cur_cpu_spec-oprofile_cpu_type ||
..
+ if (!cur_cpu_spec-oprofile_cpu_type ||
Typing it seven times didn't make you think how about a helper? :)
Perhaps:
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cput
index 80f315e..956cbc3 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -123,6 +123,11 @@ struct cpu_spec {
extern struct cpu_spec *cur_cpu_spec;
+static inline int oprofile_cpu_type_matches(const char *s)
+{
+ return s (strcmp(cur_cpu_spec-oprofile_cpu_type, s) == 0);
+}
+
extern unsigned int __start___ftr_fixup, __stop___ftr_fixup;
extern struct cpu_spec *identify_cpu(unsigned long offset, unsigned int pvr);
And then callsites become:
static int init_mpc7450_pmu(void)
{
if (!oprofile_cpu_type_matches(ppc/7450))
return -ENODEV;
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs
.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list
s.ozlabs.org] On Behalf Of Felix Radensky
Sent: Thursday, August 06, 2009 12:16 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org;
linuxppc-rele...@webnode01-prod1.am.freescale.net
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 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,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the
size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR
Re: [PATCH] powerpc/perfctr: Check oprofile_cpu_type for NULL before using it
On Thu, 2009-08-06 at 21:03 +1000, Michael Ellerman wrote: Typing it seven times didn't make you think how about a helper? :) Copy/paste works fine :-) Seriously, I did think about it, but a couple of cases test more than one string so a totally trivial helper wouldn't do and I couldn't be bothered doing anything more complicated while under influenza :-) You are welcome to do something nicer for .32. BTW. While at it, I think we should move that stuff to a separate subdir too. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash on a idle system.
Benjamin Herrenschmidt wrote: Thanks. Since it's a memory corruption (or seems to be) however, it's possible that the bisection will mislead you. IE. The culprit could be somewhere else, and the commit you'll find via bisection just happens to move things around in the kernel in such a way that the corruption hits that code path instead of another rarely used one. I would suggest using printk to print out the content of memory where the code appears to have been smashed at different stages during boot (maybe even in the initcalls loop in init/main.c) to try to point out what appears to be causing the corruption. By the time machine is up and running the particular memory location in question is already overwritten. So seems like the corruption occurs during the boot. 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(0xc060) 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. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash on a idle system.
On Thu, 2009-08-06 at 19:03 +0530, Sachin Sant wrote: Benjamin Herrenschmidt wrote: Thanks. Since it's a memory corruption (or seems to be) however, it's possible that the bisection will mislead you. IE. The culprit could be somewhere else, and the commit you'll find via bisection just happens to move things around in the kernel in such a way that the corruption hits that code path instead of another rarely used one. I would suggest using printk to print out the content of memory where the code appears to have been smashed at different stages during boot (maybe even in the initcalls loop in init/main.c) to try to point out what appears to be causing the corruption. By the time machine is up and running the particular memory location in question is already overwritten. So seems like the corruption occurs during the boot. 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(0xc060) 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. Is it always the exact same pattern at the exact same address? Or does it change and if so how? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
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. 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 ? Thanks, Shaohua -- Thanks and Regards gautham ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerPC kernel linux-2.6.29.6 crashes at mm/slab.c for ipsec application
Hi all, Here is kernel bug for linux-2.6.29.6 for PowerPC (ppc440) target, while running ipsec application it is observed that kernel oops'es oftenly as show below : r...@powerpc:~# ./ipsec [ cut here ] kernel BUG at mm/slab.c:3002! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT LTT NESTING LEVEL : 0 Xilinx Virtex440 Modules linked in: nls_iso8859_1 nfsd NIP: c00a1e94 LR: c00a1d3c CTR: 000b REGS: ce8c9d20 TRAP: 0700 Not tainted (2.6.29.6.xilinx-ml507.0908010910-ipsec) MSR: 00021000 ME,CE CR: 22024428 XER: 0005 TASK = cfa2a430[974] 'watchdog' THREAD: ce8c8000 GPR00: 0028 ce8c9dd0 cfa2a430 cf802ea8 cf9e001c 000a cf9e GPR08: 0d80 0001 000a 0028 cf802ea0 1002b58c c0547bd0 c0547bd4 GPR16: c0547ba0 c050dd78 c050e60c 00d0 00200200 00100100 0001 GPR24: ce8c8034 ce8c8000 c052 cf802eb0 cf807560 cf809e00 NIP [c00a1e94] cache_alloc_refill+0x138/0x630 LR [c00a1d3c] kmem_cache_alloc+0x80/0xa0 Call Trace: [ce8c9dd0] [c050e60c] 0xc050e60c (unreliable) [ce8c9e30] [c00a1d3c] kmem_cache_alloc+0x80/0xa0 [ce8c9e50] [c00534ec] prepare_creds+0x3c/0xcc [ce8c9e70] [c005382c] copy_creds+0xa0/0x12c [ce8c9e80] [c00307dc] copy_process+0x1c0/0xe20 [ce8c9ee0] [c00314b8] do_fork+0x7c/0x338 [ce8c9f20] [c00065b4] sys_clone+0x58/0x88 [ce8c9f40] [c000e164] ret_from_syscall+0x0/0x3c Instruction dump: 2f8a 3bac0010 386c0008 409d0104 80cc 7f8c3000 419e00e8 81660010 801e001c 7d205810 3920 7d294914 0f09 7f8b0040 7d455378 409c0074 ---[ end trace b098f3001b420338 ]--- note: watchdog[974] exited with preempt_count 1 BUG: scheduling while atomic: watchdog/974/0x1002 Modules linked in: nls_iso8859_1 nfsd Call Trace: [ce8c99e0] [c0006184] show_stack+0x40/0x15c (unreliable) [ce8c9a10] [c002bab4] __schedule_bug+0x68/0x6c [ce8c9a20] [c03d5138] schedule+0x2bc/0x36c [ce8c9a70] [c002bae0] __cond_resched+0x28/0x54 [ce8c9a80] [c03d5304] _cond_resched+0x50/0x58 [ce8c9a90] [c00925c8] __mlock_vma_pages_range+0x84/0x2c4 [ce8c9b20] [c0094084] exit_mmap+0x60/0x1b0 [ce8c9b50] [c002fe64] mmput+0x50/0x114 [ce8c9b60] [c0034120] exit_mm+0x130/0x14c [ce8c9b90] [c0035db4] do_exit+0xd0/0x6b8 [ce8c9be0] [c000c234] die+0x1b0/0x1b8 [ce8c9c10] [c000c554] _exception+0x1d4/0x2b4 [ce8c9d10] [c000e78c] ret_from_except_full+0x0/0x4c [ce8c9dd0] [c050e60c] 0xc050e60c [ce8c9e30] [c00a1d3c] kmem_cache_alloc+0x80/0xa0 [ce8c9e50] [c00534ec] prepare_creds+0x3c/0xcc [ce8c9e70] [c005382c] copy_creds+0xa0/0x12c [ce8c9e80] [c00307dc] copy_process+0x1c0/0xe20 [ce8c9ee0] [c00314b8] do_fork+0x7c/0x338 [ce8c9f20] [c00065b4] sys_clone+0x58/0x88 [ce8c9f40] [c000e164] ret_from_syscall+0x0/0x3c BUG: scheduling while atomic: watchdog/974/0x1002 Modules linked in: nls_iso8859_1 nfsd Call Trace: [ce8c99e0] [c0006184] show_stack+0x40/0x15c (unreliable) [ce8c9a10] [c002bab4] __schedule_bug+0x68/0x6c [ce8c9a20] [c03d5138] schedule+0x2bc/0x36c [ce8c9a70] [c002bae0] __cond_resched+0x28/0x54 [ce8c9a80] [c03d5304] _cond_resched+0x50/0x58 [ce8c9a90] [c00925c8] __mlock_vma_pages_range+0x84/0x2c4 [ce8c9b20] [c0094084] exit_mmap+0x60/0x1b0 [ce8c9b50] [c002fe64] mmput+0x50/0x114 [ce8c9b60] [c0034120] exit_mm+0x130/0x14c [ce8c9b90] [c0035db4] do_exit+0xd0/0x6b8 [ce8c9be0] [c000c234] die+0x1b0/0x1b8 [ce8c9c10] [c000c554] _exception+0x1d4/0x2b4 [ce8c9d10] [c000e78c] ret_from_except_full+0x0/0x4c [ce8c9dd0] [c050e60c] 0xc050e60c [ce8c9e30] [c00a1d3c] kmem_cache_alloc+0x80/0xa0 [ce8c9e50] [c00534ec] prepare_creds+0x3c/0xcc [ce8c9e70] [c005382c] copy_creds+0xa0/0x12c [ce8c9e80] [c00307dc] copy_process+0x1c0/0xe20 [ce8c9ee0] [c00314b8] do_fork+0x7c/0x338 [ce8c9f20] [c00065b4] sys_clone+0x58/0x88 [ce8c9f40] [c000e164] ret_from_syscall+0x0/0x3c r...@inson:~# r...@inson:~# [ cut here ] kernel BUG at mm/slab.c:3002! Oops: Exception in kernel mode, sig: 5 [#2] PREEMPT LTT NESTING LEVEL : 0 Xilinx Virtex440 Modules linked in: nls_iso8859_1 nfsd NIP: c00a1e94 LR: c00a1d3c CTR: 000a REGS: ce9cbd20 TRAP: 0700 Tainted: G D (2.6.29.6.xilinx-ml507.0908010910-ipsec) MSR: 00021000 ME,CE CR: 22424848 XER: 0001 TASK = ce8fe030[1400] 'mvtsd.py' THREAD: ce9ca000 GPR00: 0028 ce9cbdd0 ce8fe030 cf802ea8 cf9e001c 0009 cf9e GPR08: 0d20 0001 0009 0028 cf802ea0 10018a3c c0547bd0 c0547bd4 GPR16: c0547ba0 c050dd78 c050e60c 00d0 00200200 00100100 0001 GPR24: ce9ca034 ce9ca000 c052 cf802eb0 cf807560 cf809e00 NIP [c00a1e94] cache_alloc_refill+0x138/0x630 LR [c00a1d3c] kmem_cache_alloc+0x80/0xa0 Call Trace: [ce9cbdd0] [c050e60c] 0xc050e60c (unreliable) [ce9cbe30] [c00a1d3c] kmem_cache_alloc+0x80/0xa0 [ce9cbe50] [c00534ec] prepare_creds+0x3c/0xcc [ce9cbe70] [c005382c] copy_creds+0xa0/0x12c [ce9cbe80] [c00307dc] copy_process+0x1c0/0xe20 [ce9cbee0] [c00314b8] do_fork+0x7c/0x338 [ce9cbf20] [c00065b4] sys_clone+0x58/0x88 [ce9cbf40] [c000e164] ret_from_syscall+0x0/0x3c Instruction dump: 2f8a
Re: kexec on e300 core / mpc5121
On Aug 5, 2009, at 5:49 PM, Kenneth Johansson wrote: On Wed, 2009-08-05 at 01:06 +0200, Sebastian Andrzej Siewior wrote: I've tried kexec on e300 core which should be easy since it is possible to disable the MMU on that core. However it does not work. Is it not possible to disable the mmu on all cpu's that have one ?? Nope. Book-E class PPC parts always have the mmu. Once I disable the MMU, I can't access my MBAR and print chars on the serial port. Is this normal or do I have still some caches on? Yes cache and mmu is separate. the 5121 is not cache coherent and do not limit cache to only memory regions so serial port or any memory mapped register is a no no unless you have cache off or cache on and mmu on with a correct setting for what address range to cache. Before you turn off the cache you need to flush out all dirty data. best done by simply reading in 32kb of crap from somewhere. otherwise you are sure to loose at least the stack and you do not want that. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: Kernel fault with simple UIO interrupt driver in 2.6.30.4
On Tue, 2009-08-04 at 09:23 +0200, Frank Prepelica wrote: Oh okay, I didnt think anybody would need it :) IRQ 20/IRQ3 Kernel Driver: IRQF_DISABLED is not guaranteed on shared IRQs Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x Oops: Kernel access of bad area, sig: 11 [#1] MPC831x RDB Modules linked in: NIP: LR: c004755c CTR: REGS: c7827d50 TRAP: 0400 Not tainted (2.6.30.4) MSR: 20001032 ME,IR,DR CR: 2822 XER: 2000 TASK = c7828000[1] 'swapper' THREAD: c7826000 GPR00: 0002 c7827e00 c7828000 0014 0002 0014 c73adb7c c06bb460 GPR08: 0014 07fff000 0001 GPR16: 007fff00 07ff9794 007ffeb0 GPR24: c73ad180 c02d70a4 c0574f28 9032 0014 c73adb40 c0574f08 Call Trace: [c7827e00] [c00474e4] 0xc00474e4 (unreliable) [c7827e20] [c0047754] 0xc0047754 [c7827e50] [c019c568] 0xc019c568 [c7827e90] [c019c7f8] 0xc019c7f8 [c7827ea0] [c0177a80] 0xc0177a80 [c7827ec0] [c0177b94] 0xc0177b94 [c7827ee0] [c01764d8] 0xc01764d8 [c7827f10] [c0177590] 0xc0177590 [c7827f20] [c017703c] 0xc017703c [c7827f40] [c0178080] 0xc0178080 [c7827f60] [c0319884] 0xc0319884 [c7827f70] [c00038dc] 0xc00038dc [c7827fe0] [c03037c0] 0xc03037c0 [c7827ff0] [c0010778] 0xc0010778 It would be more useful with symbols :) But, you can see that it's taking a 400, ie. faulting on instruction fetch - which suggests your driver is causing the kernel to try and execute at instruction 0x0 - why I'm not sure. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, 2009-08-05 at 22:19 +0530, M. Mohan Kumar wrote: Hi, When I align the dtstruct variable to 8 bytes, I am able to invoke kdump. When the line static unsigned dtstruct[TREEWORDS], *dt; changed to static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt; kexec-tool works. Hmm, odd. Can you check how it's aligned without your change? ie. in the original binary, is it 4 byte aligned? When you make the change, is the only thing that changes in the binary the alignedness of dtstruct, or does it cause other things to move around? I don't think an unaligned dt blob should have any effect on the kernel, ie. it should copy it in fine, but I'd have to look at the code. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC kernel linux-2.6.29.6 crashes at mm/slab.c for ipsec application
On Thu, Aug 06, 2009 at 06:46:26PM +0530, srikanth krishnakar wrote: Hi all, Here is kernel bug for linux-2.6.29.6 for PowerPC (ppc440) target, while running ipsec application it is observed that kernel oops'es oftenly as show below : r...@powerpc:~# ./ipsec [ cut here ] kernel BUG at mm/slab.c:3002! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT LTT NESTING LEVEL : 0 LTT? Any Clue or any bugs found in mm/slab.c for linux-2.6.29.6 while running IPSEC applications ? Do you have CONFIG_PREEMPT set? The oops output seems to think so. Also, seeing the LTT makes me wonder if you have added custom patches to your kernel? Do you have a simple testcase that could be run to recreate this? If so, could you provide it somewhere and perhaps your .config? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ftrace scripts and make V=1
On Thu, 6 Aug 2009, Ingo Molnar wrote:
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index d29baa2..4889c44 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -414,7 +414,10 @@ while (IN) {
$offset = hex $1;
} else {
# if we already have a function, and this is weak, skip it
- if (!defined($ref_func) !defined($weak{$text})) {
+ if (!defined($ref_func) !defined($weak{$text})
+# PPC64 can have symbols that start with .L and
+# gcc considers these special. Don't use them!
+$text !~ /^\.L/) {
$ref_func = $text;
$offset = hex $1;
}
Ah, indeed. I'm wondering whether also emitting a build warning
would be useful - just in the (admittedly unlikely) case of someone
wondering about why LM93_IN_FROM_REG does not show up in function
traces.
Actually, it just skips it as the function to use as the reference point.
It should still record the mcount for that function. Now we may have an
issues if all functions in a section start with .L
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
On Thu, 2009-08-06 at 17:03 +0200, Peter Zijlstra wrote: On Thu, 2009-08-06 at 10:03 +0530, Vaidyanathan Srinivasan wrote: This was the main objection to Venki's deepest sleep state for offline cpus patch. Well, my main objection was that is was a single raw function pointer without any management layer around it. We have the exact same mess with the idle routine - and that has bitten us in the past. That said, I still think it makes sense to share this with the idle routine, we can make some callbacks unsuitable for hot-unplug just fine. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
On Thu, 2009-08-06 at 10:03 +0530, Vaidyanathan Srinivasan wrote: This was the main objection to Venki's deepest sleep state for offline cpus patch. Well, my main objection was that is was a single raw function pointer without any management layer around it. We have the exact same mess with the idle routine - and that has bitten us in the past. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kexec on e300 core / mpc5121
On Thu, Aug 06, 2009 at 02:20:50AM +0200, Kenneth Johansson wrote: Before you turn off the cache you need to flush out all dirty data. best done by simply reading in 32kb of crap from somewhere. otherwise you are sure to loose at least the stack and you do not want that. 32KiB is usually not sufficient -- depending on the initial state, an 8-way 32KiB cache with PLRU (such as in e300) can require up to 52KiB of data (13 loads per set) to fully flush if you simply load+dcbf (in separate passes) an arbitrary chunk of data which may already be in the cache. if you have int crap[1024*32/4] __attribute__((aligned(32))) What will happen with the cache if you just load data into a register from that array ?? Wont it force out everything else in the cache to make room for the crap ? Under certain circumstances, the newly loaded flush data will replace previous flush data rather than the actual data you're trying to displace -- especially if some of the crap is already in the cache, or if there were some empty cache lines at the start of the process. It's not a true LRU. If you read 52K, and then dcbf that same 52K, with interrupts disabled (they can disturb the PLRU), you should be OK. It doesn't even need to be dedicated junk, any memory will work. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
need help getting SPI controller working on 405EX
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/):
[nfre...@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.0 -0700
--- spi.dts 2009-08-06 08:42:19.0 -0700
***
*** 207,210
--- 207,221
#size-cells = 0;
};
+
+ SPI0: s...@ef600600 {
+ cell-index = 0;
+ compatible = ibm,spi-405ex, ibm,spi;
+ reg = ef600600 6;
+ interrupts = 8 4;
+ interrupt-parent = UIC0;
+ mode = cpu;
+ };
RGMII0: emac-rg...@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:
[r...@10.2.3.28 /]$ find /proc/device-tree/ | grep spi
/proc/device-tree/plb/opb/s...@ef600600
/proc/device-tree/plb/opb/s...@ef600600/name
/proc/device-tree/plb/opb/s...@ef600600/mode
/proc/device-tree/plb/opb/s...@ef600600/interrupt-parent
/proc/device-tree/plb/opb/s...@ef600600/interrupts
/proc/device-tree/plb/opb/s...@ef600600/reg
/proc/device-tree/plb/opb/s...@ef600600/compatible
/proc/device-tree/plb/opb/s...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC kernel linux-2.6.29.6 crashes at mm/slab.c for ipsec application
Yes, You are right. CONFIG_PREEMPT is enabled in the kernel config. Attached is the config. Thanks -Srikanth On Thu, Aug 6, 2009 at 7:56 PM, Josh Boyer jwbo...@linux.vnet.ibm.comwrote: On Thu, Aug 06, 2009 at 06:46:26PM +0530, srikanth krishnakar wrote: Hi all, Here is kernel bug for linux-2.6.29.6 for PowerPC (ppc440) target, while running ipsec application it is observed that kernel oops'es oftenly as show below : r...@powerpc:~# ./ipsec [ cut here ] kernel BUG at mm/slab.c:3002! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT LTT NESTING LEVEL : 0 LTT? Any Clue or any bugs found in mm/slab.c for linux-2.6.29.6 while running IPSEC applications ? Do you have CONFIG_PREEMPT set? The oops output seems to think so. Also, seeing the LTT makes me wonder if you have added custom patches to your kernel? Do you have a simple testcase that could be run to recreate this? If so, could you provide it somewhere and perhaps your .config? josh -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29.6 # Mon Aug 3 20:22:33 2009 # # CONFIG_PPC64 is not set # # Processor support # # CONFIG_6xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set CONFIG_44x=y # CONFIG_E200 is not set CONFIG_PPC_FPU=y CONFIG_4xx=y CONFIG_BOOKE=y CONFIG_PTE_64BIT=y CONFIG_PHYS_64BIT=y CONFIG_PPC_MMU_NOHASH=y # CONFIG_PPC_MM_SLICES is not set CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_PPC_DCR_NATIVE=y CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-ipsec # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_HAVE_GET_CYCLES is not set CONFIG_HAVE_TRACE_CLOCK=y # CONFIG_HAVE_TRACE_CLOCK_GENERIC is not set # CONFIG_HAVE_TRACE_CLOCK_32_TO_64 is not set # CONFIG_HAVE_UNSYNCHRONIZED_TSC is not set # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_LTT=y CONFIG_LTT_FILTER=m # CONFIG_HAVE_LTT_DUMP_TABLES is not set CONFIG_LTT_RELAY_ALLOC=y CONFIG_LTT_RELAY_LOCKLESS=y # CONFIG_LTT_RELAY_IRQOFF is not set # CONFIG_LTT_RELAY_LOCKED is not set CONFIG_LTT_SERIALIZE=m CONFIG_LTT_FAST_SERIALIZE=y CONFIG_LTT_TRACEPROBES=m CONFIG_LTT_TRACE_CONTROL=m CONFIG_LTT_TRACER=y CONFIG_LTT_ALIGNMENT=y CONFIG_LTT_CHECK_ARCH_EFFICIENT_UNALIGNED_ACCESS=y # CONFIG_LTT_DEBUG_EVENT_SIZE is not set CONFIG_LTT_USERSPACE_EVENT=m CONFIG_LTT_VMCORE=y CONFIG_LTT_KPROBES=y
MPC8313 performance evaluation
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 mpc8...@400mhz I get a throughput of approx. 24500 frames/s using the predefined firewall rules. With the MPC8313 I get a significantly lower value: mpc8...@250mhz 12500fps mpc8...@333mhz 14500fps mpc8...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC8313 performance evaluation
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 mpc8...@400mhz I get a throughput of approx. 24500 frames/s using the predefined firewall rules. With the MPC8313 I get a significantly lower value: mpc8...@250mhz 12500fps mpc8...@333mhz 14500fps mpc8...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] arch/powerpc: Add kmalloc NULL tests
From: Julia Lawall ju...@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 ju...@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;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash on a idle system.
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(0xc060) 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
On Wed, 2009-08-05 at 00:15 +1000, Michael Ellerman wrote: c060 1010 .long 0x1010 0:mon c064 0008 .long 0x8 c068 1013 .long 0x1013 c06c 000f .long 0xf c0600010 7961626f rldimi. r1,r11,44,41 c0600014 6f74 xoris r20,r27,0 c0600018 00101600 .long 0x101600 c060001c 0c00 .long 0xc00 c0600020 0400 .long 0x400 c0600024 00101100 .long 0x101100 c0600028 08e9 .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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 2/3] powerpc/fsl-booke: read buffer overflow
From: Roel Kluin roel.kl...@gmail.com
cam[tlbcam_index] is checked before tlbcam_index ARRAY_SIZE(cam)
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Andrew Morton a...@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];
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 1/3] powerpc: Sky CPU: redundant or incorrect tests on unsigned
From: Roel Kluin roel.kl...@gmail.com
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Cc: Cyrill Gorcunov gorcu...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Kumar Gala ga...@gate.crashing.org
Cc: Brian Waite wa...@skycomputers.com
Signed-off-by: Andrew Morton a...@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;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 3/3] powerpc: avoid calculating possibly-invalid address
From: Roel Kluin roel.kl...@gmail.com
Check whether index is within bounds prior to calculating a
possibly-invalid address.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Cc: Bernd Petrovitsch be...@firmix.at
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Andrew Morton a...@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);
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
On Thu, 6 Aug 2009 17:04:18 +0530
Aggrwal Poonam-B10812 poonam.aggr...@freescale.com wrote:
Can u point me to some reference of this, shud they be partit...@0,
partit...@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:
partit...@0 {
label = kernel;
reg = 0x 0x0020;
};
partit...@20 {
label = root;
reg = 0x0020 0x03E0;
};
partit...@4000 {
label = persistent;
reg = 0x0400 0x0400;
};
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Move mpc8536ds.dts to address-cells/size-cells = 2
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 ga...@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 = ; // Filled by U-Boot
+ reg = 0 0 0 0;// Filled by U-Boot
};
s...@ffe0 {
@@ -50,7 +50,7 @@
#size-cells = 1;
device_type = soc;
compatible = simple-bus;
- ranges = 0x0 0xffe0 0x10;
+ ranges = 0x0 0 0xffe0 0x10;
bus-frequency = 0;// Filled out by uboot.
ecm-...@0 {
@@ -347,13 +347,13 @@
interrupt-parent = mpic;
interrupts = 24 0x2;
bus-range = 0 0xff;
- ranges = 0x0200 0 0x8000 0x8000 0 0x1000
- 0x0100 0 0x 0xffc0 0 0x0001;
+ ranges = 0x0200 0 0x8000 0 0x8000 0 0x1000
+ 0x0100 0 0x 0 0xffc0 0 0x0001;
clock-frequency = ;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = 0xffe08000 0x1000;
+ reg = 0 0xffe08000 0 0x1000;
};
pci1: p...@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 = 0x0200 0 0x9800 0x9800 0 0x0800
- 0x0100 0 0x 0xffc2 0 0x0001;
+ ranges = 0x0200 0 0x9800 0 0x9800 0 0x0800
+ 0x0100 0 0x 0 0xffc2 0 0x0001;
clock-frequency = ;
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 = 0x0200 0 0x9000 0x9000 0 0x0800
- 0x0100 0 0x 0xffc1 0 0x0001;
+ ranges = 0x0200 0 0x9000 0 0x9000 0 0x0800
+ 0x0100 0 0x 0 0xffc1 0 0x0001;
clock-frequency = ;
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 = 0x0200 0 0xa000 0xa000 0 0x2000
- 0x0100 0 0x 0xffc3 0 0x0001;
+ ranges = 0x0200 0 0xa000 0 0xa000 0 0x2000
+ 0x0100 0 0x 0 0xffc3 0 0x0001;
clock-frequency = ;
interrupt-parent = mpic;
interrupts = 27 0x2;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Added 36-bit physical device tree for mpc8572ds board
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 ga...@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 000..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,8...@0 {
+ device_type = cpu;
+ reg = 0;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0 0;// Filled by U-Boot
+ };
+
+ s...@fffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
+ ranges = 0x0 0xf 0xffe0 0x10;
+ bus-frequency = 0;// Filled out by uboot.
+
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 12;
+ };
+
+ e...@1000 {
+ compatible = fsl,mpc8536-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
+ memory-control...@2000 {
+ compatible = fsl,mpc8536-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 0x2;
+ };
+
+ L2: l2-cache-control...@2 {
+ compatible = fsl,mpc8536-l2-cache-controller;
+ reg = 0x2 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 16 0x2;
+ };
+
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 0x2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ i...@3100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 0x2;
+ interrupt-parent = mpic;
+ dfsrr;
+ r...@68 {
+ compatible = dallas,ds3232;
+ reg = 0x68;
+ interrupts = 0 0x1;
+ interrupt-parent = mpic;
+ };
+ };
+
+ d...@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-chan...@0 {
+ compatible = fsl,mpc8536-dma-channel,
+fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ cell-index = 0;
+ interrupt-parent = mpic;
+ interrupts = 20 2;
+ };
+ dma-chan...@80 {
+ compatible = fsl,mpc8536-dma-channel,
+
Re: [PATCH 2/10] arch/powerpc: introduce missing kfree
On Aug 2, 2009, at 3:44 AM, Julia Lawall wrote:
From: Julia Lawall ju...@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\);
|
ret...@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 ju...@diku.dk
---
arch/powerpc/sysdev/ipic.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
applied to next
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] arch/powerpc: Add kmalloc NULL tests
On Aug 6, 2009, at 3:04 PM, Julia Lawall wrote: From: Julia Lawall ju...@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 ju...@diku.dk --- arch/powerpc/sysdev/fsl_rio.c | 18 ++ 1 files changed, 14 insertions(+), 4 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 2/3] powerpc/fsl-booke: read buffer overflow
On Aug 6, 2009, at 6:00 PM, a...@linux-foundation.org wrote: From: Roel Kluin roel.kl...@gmail.com cam[tlbcam_index] is checked before tlbcam_index ARRAY_SIZE(cam) Signed-off-by: Roel Kluin roel.kl...@gmail.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- arch/powerpc/mm/fsl_booke_mmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
On Aug 1, 2009, at 3:52 AM, Julia Lawall wrote:
From: Julia Lawall ju...@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\);
|
ret...@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 ju...@diku.dk
---
arch/powerpc/sysdev/qe_lib/qe_ic.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
applied to next
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] 82xx, mgcoge: update defconfig for 2.6.32
On Aug 3, 2009, at 2:35 AM, Heiko Schocher wrote: - add I2C support - add FCC1 and FCC2 support Signed-off-by: Heiko Schocher h...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
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 h...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/86xx: Update GE Fanuc sbc310 DTS
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.we...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards
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 avoront...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/83xx: Add support for MPC8377E-WLAN boards
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 avoront...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards
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 avoront...@ru.mvista.com --- arch/powerpc/boot/dts/mpc8548cds.dts | 20 1 files changed, 20 insertions(+), 0 deletions(-) applied to next. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/86xx: Correct reading of information presented in cpuinfo
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.we...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/86xx: Enable XMC site on GE Fanuc SBC310
On Jun 30, 2009, at 9:32 AM, Martyn Welch wrote: This patch enables the XMC (PCIe daughter card) site on the SBC310. STG enter the description for the patch above. Signed-off-by: Martyn Welch martyn.we...@gefanuc.com --- arch/powerpc/boot/dts/gef_sbc310.dts | 37 + + 1 files changed, 37 insertions(+), 0 deletions(-) applied to next. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/86xx: Update GE Fanuc sbc310 DTS
On Aug 6, 2009, at 9:38 PM, Kumar Gala wrote: 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.we...@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. Ignore this, I see what you meant by the earlier patch... - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
On Fri, Aug 07, 2009 at 08:23:05AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2009-08-05 at 00:15 +1000, Michael Ellerman wrote: c060 1010 .long 0x1010 0:mon c064 0008 .long 0x8 c068 1013 .long 0x1013 c06c 000f .long 0xf c0600010 7961626f rldimi. r1,r11,44,41 c0600014 6f74 xoris r20,r27,0 c0600018 00101600 .long 0x101600 c060001c 0c00 .long 0xc00 c0600020 0400 .long 0x400 c0600024 00101100 .long 0x101100 c0600028 08e9 .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 I know we fixed it in Fedora for F11/F12. Did it get fixed upstream? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull from 'next' branch
Please pull from 'next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next to receive the following updates: arch/powerpc/boot/dts/gef_sbc310.dts | 64 +++- arch/powerpc/boot/dts/mgcoge.dts | 53 +++ arch/powerpc/boot/dts/mpc8377_rdb.dts |2 arch/powerpc/boot/dts/mpc8377_wlan.dts| 464 + arch/powerpc/boot/dts/mpc8378_rdb.dts |2 arch/powerpc/boot/dts/mpc8379_rdb.dts |2 arch/powerpc/boot/dts/mpc8536ds.dts | 32 +- arch/powerpc/boot/dts/mpc8536ds_36b.dts | 467 ++ arch/powerpc/boot/dts/mpc8548cds.dts | 20 + arch/powerpc/mm/fsl_booke_mmu.c |2 arch/powerpc/platforms/82xx/mgcoge.c | 69 +++- arch/powerpc/platforms/83xx/Kconfig |4 arch/powerpc/platforms/83xx/mpc837x_rdb.c | 28 + arch/powerpc/platforms/83xx/mpc83xx.h |4 arch/powerpc/platforms/86xx/gef_ppc9a.c | 37 +- arch/powerpc/sysdev/fsl_rio.c | 18 - arch/powerpc/sysdev/ipic.c|7 arch/powerpc/sysdev/qe_lib/qe_ic.c|5 18 files changed, 1219 insertions(+), 61 deletions(-) Anton Vorontsov (3): powerpc/83xx: Add support for MPC8377E-WLAN boards powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards Heiko Schocher (1): powerpc/82xx: mgcoge - updates for 2.6.32 Julia Lawall (3): powerpc/fsl_rio: Add kmalloc NULL tests powerpc/ipic: introduce missing kfree powerpc/qe: introduce missing kfree Kumar Gala (2): powerpc/85xx: Move mpc8536ds.dts to address-cells/size-cells = 2 powerpc/85xx: Added 36-bit physical device tree for mpc8572ds board Martyn Welch (3): powerpc/86xx: Correct reading of information presented in cpuinfo powerpc/86xx: Enable XMC site on GE Fanuc SBC310 powerpc/86xx: Update GE Fanuc sbc310 DTS Roel Kluin (1): powerpc/fsl-booke: read buffer overflow Sebastian Andrzej Siewior (1): powerpc/ipic: unmask all interrupt sources ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
On Thu, 2009-08-06 at 22:54 -0400, Josh Boyer wrote: On Fri, Aug 07, 2009 at 08:23:05AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2009-08-05 at 00:15 +1000, Michael Ellerman wrote: c060 1010 .long 0x1010 0:mon c064 0008 .long 0x8 c068 1013 .long 0x1013 c06c 000f .long 0xf c0600010 7961626f rldimi. r1,r11,44,41 c0600014 6f74 xoris r20,r27,0 c0600018 00101600 .long 0x101600 c060001c 0c00 .long 0xc00 c0600020 0400 .long 0x400 c0600024 00101100 .long 0x101100 c0600028 08e9 .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 I know we fixed it in Fedora for F11/F12. Did it get fixed upstream? I think Tony did yes. Not sure what's the status with the enterprise distros. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
On Fri, Aug 07, 2009 at 01:13:54PM +1000, Benjamin Herrenschmidt wrote: I think Tony did yes. Not sure what's the status with the enterprise distros. It's fixed in F11 and F12 (thanks to dwmw2), it's in my for-1.3.15 branch for yaboot. We're working on updateing the version in the enterprise, we'll see what the next release holds. Yours Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] 82xx, mgcoge: update defconfig for 2.6.32
Hello Kumar, Kumar Gala wrote: On Aug 3, 2009, at 2:35 AM, Heiko Schocher wrote: - add I2C support - add FCC1 and FCC2 support Signed-off-by: Heiko Schocher h...@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 Ups, Sorry, I based this patchset against: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git I make a patch against your next branch ... bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
