[PATCH] powerpc/pseries: remove duplicate SCSI_BNX2_ISCSI in pseries_defconfig
Remove duplicate assignment of SCSI_BNX2_ISCSI in pseries_defconfig introduced by: 37e0c21e powerpc/pseries: Enable iSCSI support for a number of cards causes warning: arch/powerpc/configs/pseries_defconfig:151:warning: override: reassigning to symbol SCSI_BNX2_ISCSI Signed-off-by: Michael Neuling diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index c9f212b..80bc5de 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -148,7 +148,6 @@ CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_CXGB3_ISCSI=m CONFIG_SCSI_CXGB4_ISCSI=m CONFIG_SCSI_BNX2_ISCSI=m -CONFIG_SCSI_BNX2_ISCSI=m CONFIG_BE2ISCSI=m CONFIG_SCSI_IBMVSCSI=y CONFIG_SCSI_IBMVFC=m ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Liu Shuo
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip whose page size is larger than 2K bytes,
we divide a page into multi-2K pages for MTD layer driver. In that case,
we force to set the page size to 2K bytes. We convert the page address of
MTD layer driver to a real page address in flash chips and a column index
in fsl_elbc driver. We can issue any column address by UA instruction of
elbc controller.
Signed-off-by: Liu Shuo
Signed-off-by: Li Yang
---
drivers/mtd/nand/fsl_elbc_nand.c | 61 +
1 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index a212116..eea7a22 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -76,6 +76,10 @@ struct fsl_elbc_fcm_ctrl {
unsigned int oob;/* Non zero if operating on OOB data */
unsigned int counter;/* counter for the initializations */
char *oob_poi; /* Place to write ECC after read back*/
+
+ int subpage_shift; /* If writesize > 2048, these two members*/
+ int subpage_mask;/* are used to calculate the real page */
+/* address and real column address */
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -164,18 +168,27 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
int buf_num;
+ u32 real_ca = column;
- elbc_fcm_ctrl->page = page_addr;
+ if (priv->page_size && elbc_fcm_ctrl->subpage_shift) {
+ real_ca = (page_addr & elbc_fcm_ctrl->subpage_mask) * 2112;
+ page_addr >>= elbc_fcm_ctrl->subpage_shift;
+ }
- out_be32(&lbc->fbar,
-page_addr >> (chip->phys_erase_shift - chip->page_shift));
+ elbc_fcm_ctrl->page = page_addr;
if (priv->page_size) {
+ real_ca += (oob ? 2048 : 0);
+ elbc_fcm_ctrl->use_mdr = 1;
+ elbc_fcm_ctrl->mdr = real_ca;
+
+ out_be32(&lbc->fbar, page_addr >> 6);
out_be32(&lbc->fpar,
((page_addr << FPAR_LP_PI_SHIFT) & FPAR_LP_PI) |
(oob ? FPAR_LP_MS : 0) | column);
buf_num = (page_addr & 1) << 2;
} else {
+ out_be32(&lbc->fbar, page_addr >> 5);
out_be32(&lbc->fpar,
((page_addr << FPAR_SP_PI_SHIFT) & FPAR_SP_PI) |
(oob ? FPAR_SP_MS : 0) | column);
@@ -256,10 +269,11 @@ static void fsl_elbc_do_read(struct nand_chip *chip, int
oob)
if (priv->page_size) {
out_be32(&lbc->fir,
(FIR_OP_CM0 << FIR_OP0_SHIFT) |
-(FIR_OP_CA << FIR_OP1_SHIFT) |
-(FIR_OP_PA << FIR_OP2_SHIFT) |
-(FIR_OP_CM1 << FIR_OP3_SHIFT) |
-(FIR_OP_RBW << FIR_OP4_SHIFT));
+(FIR_OP_UA << FIR_OP1_SHIFT) |
+(FIR_OP_UA << FIR_OP2_SHIFT) |
+(FIR_OP_PA << FIR_OP3_SHIFT) |
+(FIR_OP_CM1 << FIR_OP4_SHIFT) |
+(FIR_OP_RBW << FIR_OP5_SHIFT));
out_be32(&lbc->fcr, (NAND_CMD_READ0 << FCR_CMD0_SHIFT) |
(NAND_CMD_READSTART << FCR_CMD1_SHIFT));
@@ -399,12 +413,13 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd,
unsigned int command,
if (priv->page_size) {
out_be32(&lbc->fir,
(FIR_OP_CM2 << FIR_OP0_SHIFT) |
-(FIR_OP_CA << FIR_OP1_SHIFT) |
-(FIR_OP_PA << FIR_OP2_SHIFT) |
-(FIR_OP_WB << FIR_OP3_SHIFT) |
-(FIR_OP_CM3 << FIR_OP4_SHIFT) |
-(FIR_OP_CW1 << FIR_OP5_SHIFT) |
-(FIR_OP_RS << FIR_OP6_SHIFT));
+(FIR_OP_UA << FIR_OP1_SHIFT) |
+(FIR_OP_UA << FIR_OP2_SHIFT) |
+(FIR_OP_PA << FIR_OP3_SHIFT) |
+(FIR_OP_WB << FIR_OP4_SHIFT) |
+(FIR_OP_CM3 << FIR_OP5_SHIFT) |
+(FIR_OP_CW1 << FIR_OP6_SHIFT) |
+(FIR_OP_RS << FIR_OP7_SHIFT));
} else {
out_be32(&lbc->fir,
(FIR_OP_CM0 << FIR_OP0_SHIFT) |
@@ -453,6 +468,9 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned
int command,
[PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
From: Liu Shuo The global data fsl_lbc_ctrl_dev->nand don't have to be freed in fsl_elbc_chip_remove(). The right place to do that is in fsl_elbc_nand_remove() if elbc_fcm_ctrl->counter is zero. Signed-off-by: Liu Shuo --- drivers/mtd/nand/fsl_elbc_nand.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 0bb254c..a212116 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -829,7 +829,6 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv) elbc_fcm_ctrl->chips[priv->bank] = NULL; kfree(priv); - kfree(elbc_fcm_ctrl); return 0; } -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
On Mon, 2011-06-27 at 16:56 -0500, Scott Wood wrote:
> As is done in read_tsc() on x86, make sure that we don't return a timebase
> value smaller than cycle_last, which can happen on SMP if the timebases are
> not perfectly synchronized. It is less expensive than total enforcement of
> monotonicity, since we don't need to add another variable and update it on
> each read, but it will prevent core timekeeping functions from translating
> a small timebase regression into a large jump forward.
>
> Based on commit d8bb6f4c1670c8324e4135c61ef07486f7f17379 for x86.
You are applying a bandage on a wooden leg here userspace (vDSO)
will see the time going backward if you aren't well synchronized as
well, so you're stuffed anyways.
Cheers,
Ben.
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/kernel/time.c | 15 ++-
> 1 files changed, 14 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index f33acfd..b66ce41 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -806,9 +806,22 @@ static cycle_t rtc_read(struct clocksource *cs)
> return (cycle_t)get_rtc();
> }
>
> +/*
> + * We compare the timebase to the cycle_last value in the clocksource
> + * structure to avoid a nasty time-warp. This can be observed in a very
> + * small window right after one CPU updated cycle_last under the xtime lock,
> + * and the other CPU reads a TSC value which is smaller than the cycle_last
> + * reference value due to a TSC which is slighty behind. This delta is
> + * nowhere else observable, but in that case it results in a large forward
> + * time jump due to the unsigned delta calculation of the time keeping core
> + * code, which is necessary to support wrapping clocksources like pm timer.
> + */
> static cycle_t timebase_read(struct clocksource *cs)
> {
> - return (cycle_t)get_tb();
> + cycle_t ret = (cycle_t)get_tb();
> +
> + return ret >= clocksource_timebase.cycle_last ?
> +ret : clocksource_timebase.cycle_last;
> }
>
> void update_vsyscall(struct timespec *wall_time, struct timespec *wtm,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] serial/8250: move UPIO_TSI to powerpc
On 06/27/2011 02:45 PM, Arnd Bergmann wrote: This iotype is only used by the legacy_serial code in powerpc, so the code should live there, rather than be compiled in for every 8250 driver. Signed-off-by: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: linuxppc-dev@lists.ozlabs.org Cc: Greg Kroah-Hartman Cc: linux-ser...@vger.kernel.org --- arch/powerpc/kernel/legacy_serial.c | 24 drivers/tty/serial/8250.c | 23 --- 2 files changed, 24 insertions(+), 23 deletions(-) This seems vaguely familiar: https://lkml.org/lkml/2008/10/6/297 So just for the hell of it... Acked-by: David Daney ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/timebase_read: don't return time older than cycle_last
As is done in read_tsc() on x86, make sure that we don't return a timebase
value smaller than cycle_last, which can happen on SMP if the timebases are
not perfectly synchronized. It is less expensive than total enforcement of
monotonicity, since we don't need to add another variable and update it on
each read, but it will prevent core timekeeping functions from translating
a small timebase regression into a large jump forward.
Based on commit d8bb6f4c1670c8324e4135c61ef07486f7f17379 for x86.
Signed-off-by: Scott Wood
---
arch/powerpc/kernel/time.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index f33acfd..b66ce41 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -806,9 +806,22 @@ static cycle_t rtc_read(struct clocksource *cs)
return (cycle_t)get_rtc();
}
+/*
+ * We compare the timebase to the cycle_last value in the clocksource
+ * structure to avoid a nasty time-warp. This can be observed in a very
+ * small window right after one CPU updated cycle_last under the xtime lock,
+ * and the other CPU reads a TSC value which is smaller than the cycle_last
+ * reference value due to a TSC which is slighty behind. This delta is
+ * nowhere else observable, but in that case it results in a large forward
+ * time jump due to the unsigned delta calculation of the time keeping core
+ * code, which is necessary to support wrapping clocksources like pm timer.
+ */
static cycle_t timebase_read(struct clocksource *cs)
{
- return (cycle_t)get_tb();
+ cycle_t ret = (cycle_t)get_tb();
+
+ return ret >= clocksource_timebase.cycle_last ?
+ ret : clocksource_timebase.cycle_last;
}
void update_vsyscall(struct timespec *wall_time, struct timespec *wtm,
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] serial/8250: move UPIO_TSI to powerpc
This iotype is only used by the legacy_serial code in powerpc, so the
code should live there, rather than be compiled in for every 8250
driver.
Signed-off-by: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Greg Kroah-Hartman
Cc: linux-ser...@vger.kernel.org
---
arch/powerpc/kernel/legacy_serial.c | 24
drivers/tty/serial/8250.c | 23 ---
2 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
index 2b97b80..b229e1e 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -47,6 +47,24 @@ static struct __initdata of_device_id
legacy_serial_parents[] = {
static unsigned int legacy_serial_count;
static int legacy_serial_console = -1;
+static unsigned int tsi_serial_in(struct uart_port *p, int offset)
+{
+ unsigned int tmp;
+ offset = offset << p->regshift;
+ if (offset == UART_IIR) {
+ tmp = readl(p->membase + (UART_IIR & ~3));
+ return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
+ } else
+ return readb(p->membase + offset);
+}
+
+static void tsi_serial_out(struct uart_port *p, int offset, int value)
+{
+ offset = offset << p->regshift;
+ if (!((offset == UART_IER) && (value & UART_IER_UUE)))
+ writeb(value, p->membase + offset);
+}
+
static int __init add_legacy_port(struct device_node *np, int want_index,
int iotype, phys_addr_t base,
phys_addr_t taddr, unsigned long irq,
@@ -102,6 +120,7 @@ static int __init add_legacy_port(struct device_node *np,
int want_index,
legacy_serial_ports[index].iobase = base;
else
legacy_serial_ports[index].mapbase = base;
+
legacy_serial_ports[index].iotype = iotype;
legacy_serial_ports[index].uartclk = clock;
legacy_serial_ports[index].irq = irq;
@@ -112,6 +131,11 @@ static int __init add_legacy_port(struct device_node *np,
int want_index,
legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
legacy_serial_infos[index].irq_check_parent = irq_check_parent;
+ if (iotype == UPIO_TSI) {
+ legacy_serial_ports[index].serial_in = tsi_serial_in;
+ legacy_serial_ports[index].serial_out = tsi_serial_out;
+ }
+
printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
index, np->full_name);
printk(KERN_DEBUG " %s=%llx, taddr=%llx, irq=%lx, clk=%d, speed=%d\n",
diff --git a/drivers/tty/serial/8250.c b/drivers/tty/serial/8250.c
index c8f107e..d575ccb 100644
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -345,24 +345,6 @@ static unsigned int mem32_serial_in(struct uart_port *p,
int offset)
return readl(p->membase + offset);
}
-static unsigned int tsi_serial_in(struct uart_port *p, int offset)
-{
- unsigned int tmp;
- offset = map_8250_in_reg(p, offset) << p->regshift;
- if (offset == UART_IIR) {
- tmp = readl(p->membase + (UART_IIR & ~3));
- return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
- } else
- return readb(p->membase + offset);
-}
-
-static void tsi_serial_out(struct uart_port *p, int offset, int value)
-{
- offset = map_8250_out_reg(p, offset) << p->regshift;
- if (!((offset == UART_IER) && (value & UART_IER_UUE)))
- writeb(value, p->membase + offset);
-}
-
/* Save the LCR value so it can be re-written when a Busy Detect IRQ occurs. */
static inline void dwapb_save_out_value(struct uart_port *p, int offset,
int value)
@@ -431,11 +413,6 @@ static void set_io_from_upio(struct uart_port *p)
p->serial_out = mem32_serial_out;
break;
- case UPIO_TSI:
- p->serial_in = tsi_serial_in;
- p->serial_out = tsi_serial_out;
- break;
-
case UPIO_DWAPB:
p->serial_in = mem_serial_in;
p->serial_out = dwapb_serial_out;
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 0/2] Improve CPC925 EDAC handling code on Maple
Hello, On 6/17/11, Dmitry Eremin-Solenikov wrote: > Hello, colleagues, > > Another respin of this patchset. > > Changes since previous version: > * Fix comments in cpc925_edac.c > * Rename cpc925_cpu_getmask() to cpc925_cpu_mask_disabled() > * Don't return an error from init code if it's a U3 and not U3H > > arch/powerpc/platforms/maple/setup.c | 41 + > drivers/edac/cpc925_edac.c | 67 > +-- > 2 files changed, 83 insertions(+), 25 deletions(-) Any chance to get this version reviewed/merged? Sorry for being noisy. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx: Add P5020 SoC device tree include stub
Split out common (non-board specific) parts of the SoC related device
tree into a stub so multiple board dts files can include it and we can
reduce duplication and maintenance effort.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/p5020ds.dts | 571 +---
arch/powerpc/boot/dts/p5020si.dtsi | 652
2 files changed, 653 insertions(+), 570 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p5020si.dtsi
diff --git a/arch/powerpc/boot/dts/p5020ds.dts
b/arch/powerpc/boot/dts/p5020ds.dts
index 069cff7..8366e2f 100644
--- a/arch/powerpc/boot/dts/p5020ds.dts
+++ b/arch/powerpc/boot/dts/p5020ds.dts
@@ -32,7 +32,7 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-/dts-v1/;
+/include/ "p5020si.dtsi"
/ {
model = "fsl,P5020DS";
@@ -41,292 +41,12 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
- aliases {
- ccsr = &soc;
-
- serial0 = &serial0;
- serial1 = &serial1;
- serial2 = &serial2;
- serial3 = &serial3;
- pci0 = &pci0;
- pci1 = &pci1;
- pci2 = &pci2;
- pci3 = &pci3;
- usb0 = &usb0;
- usb1 = &usb1;
- dma0 = &dma0;
- dma1 = &dma1;
- sdhc = &sdhc;
- msi0 = &msi0;
- msi1 = &msi1;
- msi2 = &msi2;
-
- crypto = &crypto;
- sec_jr0 = &sec_jr0;
- sec_jr1 = &sec_jr1;
- sec_jr2 = &sec_jr2;
- sec_jr3 = &sec_jr3;
- rtic_a = &rtic_a;
- rtic_b = &rtic_b;
- rtic_c = &rtic_c;
- rtic_d = &rtic_d;
- sec_mon = &sec_mon;
- };
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu0: PowerPC,e5500@0 {
- device_type = "cpu";
- reg = <0>;
- next-level-cache = <&L2_0>;
- L2_0: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu1: PowerPC,e5500@1 {
- device_type = "cpu";
- reg = <1>;
- next-level-cache = <&L2_1>;
- L2_1: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- };
-
memory {
device_type = "memory";
};
soc: soc@ffe00 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "soc";
- compatible = "simple-bus";
- ranges = <0x 0xf 0xfe00 0x100>;
- reg = <0xf 0xfe00 0 0x1000>;
-
- soc-sram-error {
- compatible = "fsl,soc-sram-error";
- interrupts = <16 2 1 29>;
- };
-
- corenet-law@0 {
- compatible = "fsl,corenet-law";
- reg = <0x0 0x1000>;
- fsl,num-laws = <32>;
- };
-
- memory-controller@8000 {
- compatible = "fsl,qoriq-memory-controller-v4.5",
"fsl,qoriq-memory-controller";
- reg = <0x8000 0x1000>;
- interrupts = <16 2 1 23>;
- };
-
- memory-controller@9000 {
- compatible = "fsl,qoriq-memory-controller-v4.5",
"fsl,qoriq-memory-controller";
- reg = <0x9000 0x1000>;
- interrupts = <16 2 1 22>;
- };
-
- cpc: l3-cache-controller@1 {
- compatible = "fsl,p5020-l3-cache-controller",
"fsl,p4080-l3-cache-controller", "cache";
- reg = <0x1 0x1000
- 0x11000 0x1000>;
- interrupts = <16 2 1 27
- 16 2 1 26>;
- };
-
- corenet-cf@18000 {
- compatible = "fsl,corenet-cf";
- reg = <0x18000 0x1000>;
- interrupts = <16 2 1 31>;
- fsl,ccf-num-csdids = <32>;
- fsl,ccf-num-snoopids = <32>;
- };
-
- iommu@2 {
- compatible = "fsl,pamu-v1.0", "fsl,pamu";
- reg = <0x2 0x4000>;
- interrupts = <
- 24 2 0 0
- 16 2 1 30>;
- };
-
- mpic: pic@4 {
- clock-frequency = <0>;
- interrupt-controller;
- #address-cells = <0>;
-
[PATCH 1/2] powerpc/85xx: Add P3041 SoC device tree include stub
Split out common (non-board specific) parts of the SoC related device
tree into a stub so multiple board dts files can include it and we can
reduce duplication and maintenance effort.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/p3041ds.dts | 579 +---
arch/powerpc/boot/dts/p3041si.dtsi | 660
2 files changed, 661 insertions(+), 578 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p3041si.dtsi
diff --git a/arch/powerpc/boot/dts/p3041ds.dts
b/arch/powerpc/boot/dts/p3041ds.dts
index c2a1e3a..69cae67 100644
--- a/arch/powerpc/boot/dts/p3041ds.dts
+++ b/arch/powerpc/boot/dts/p3041ds.dts
@@ -32,7 +32,7 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-/dts-v1/;
+/include/ "p3041si.dtsi"
/ {
model = "fsl,P3041DS";
@@ -41,300 +41,12 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
- aliases {
- ccsr = &soc;
-
- serial0 = &serial0;
- serial1 = &serial1;
- serial2 = &serial2;
- serial3 = &serial3;
- pci0 = &pci0;
- pci1 = &pci1;
- pci2 = &pci2;
- pci3 = &pci3;
- usb0 = &usb0;
- usb1 = &usb1;
- dma0 = &dma0;
- dma1 = &dma1;
- sdhc = &sdhc;
- msi0 = &msi0;
- msi1 = &msi1;
- msi2 = &msi2;
-
- crypto = &crypto;
- sec_jr0 = &sec_jr0;
- sec_jr1 = &sec_jr1;
- sec_jr2 = &sec_jr2;
- sec_jr3 = &sec_jr3;
- rtic_a = &rtic_a;
- rtic_b = &rtic_b;
- rtic_c = &rtic_c;
- rtic_d = &rtic_d;
- sec_mon = &sec_mon;
- };
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu0: PowerPC,e500mc@0 {
- device_type = "cpu";
- reg = <0>;
- next-level-cache = <&L2_0>;
- L2_0: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu1: PowerPC,e500mc@1 {
- device_type = "cpu";
- reg = <1>;
- next-level-cache = <&L2_1>;
- L2_1: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu2: PowerPC,e500mc@2 {
- device_type = "cpu";
- reg = <2>;
- next-level-cache = <&L2_2>;
- L2_2: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu3: PowerPC,e500mc@3 {
- device_type = "cpu";
- reg = <3>;
- next-level-cache = <&L2_3>;
- L2_3: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- };
-
memory {
device_type = "memory";
};
soc: soc@ffe00 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "soc";
- compatible = "simple-bus";
- ranges = <0x 0xf 0xfe00 0x100>;
- reg = <0xf 0xfe00 0 0x1000>;
-
- soc-sram-error {
- compatible = "fsl,soc-sram-error";
- interrupts = <16 2 1 29>;
- };
-
- corenet-law@0 {
- compatible = "fsl,corenet-law";
- reg = <0x0 0x1000>;
- fsl,num-laws = <32>;
- };
-
- memory-controller@8000 {
- compatible = "fsl,qoriq-memory-controller-v4.5",
"fsl,qoriq-memory-controller";
- reg = <0x8000 0x1000>;
- interrupts = <16 2 1 23>;
- };
-
- cpc: l3-cache-controller@1 {
- compatible = "fsl,p3041-l3-cache-controller",
"fsl,p4080-l3-cache-controller", "cache";
- reg = <0x1 0x1000>;
- interrupts = <16 2 1 27>;
- };
-
- corenet-cf@18000 {
- compatible = "fsl,corenet-cf";
- reg = <0x18000 0x1000>;
- interrupts = <16 2 1 31>;
- fsl,ccf-num-csdids = <32>;
- fsl,ccf-num-snoopids = <32>;
- };
-
- iommu@2 {
- compatible = "fsl,pamu-v1.0", "fsl,pamu";
- reg = <0x2 0x4000>;
- interrupts = <
-
Re: [PATCH] powerpc/85xx: clamp the P1022DS DIU pixel clock to allowed values
On Jun 23, 2011, at 2:48 PM, Timur Tabi wrote: > To ensure that the DIU pixel clock will not be set to an invalid value, > clamp the PXCLK divider to the allowed range (2-255). This also acts as > a limiter for the pixel clock. > > Signed-off-by: Timur Tabi > --- > arch/powerpc/platforms/85xx/p1022_ds.c |7 ++- > 1 files changed, 6 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] powerpc/85xx: enable the framebuffer console for the defconfigs
On Jun 23, 2011, at 2:48 PM, Timur Tabi wrote: > Enable framebuffer console support by default in the defconfigs for the > Freescale 85xx-based reference board. This allows the boot messages to > be shown on the video display on the P1022DS. > > Signed-off-by: Timur Tabi > --- > arch/powerpc/configs/mpc85xx_defconfig |4 > arch/powerpc/configs/mpc85xx_smp_defconfig |4 > 2 files changed, 8 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 1/2] powerpc/86xx: enable the framebuffer console on the MPC8610 HPCD
On Jun 23, 2011, at 11:16 AM, Timur Tabi wrote: > Enable framebuffer console support by default in the defconfig on the > Freescale MPC8610 HPCD reference board. This allows the boot messages to > be shown on the video display. > > Signed-off-by: Timur Tabi > --- > arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |5 + > 1 files changed, 5 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/85xx: Add P4080 SoC device tree include stub
On Jun 23, 2011, at 7:06 AM, Kumar Gala wrote: > Split out common (non-board specific) parts of the SoC related device > tree into a stub so multiple board dts files can include it and we can > reduce duplication and maintenance effort. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/boot/dts/p4080ds.dts | 588 + > arch/powerpc/boot/dts/p4080si.dtsi | 661 > 2 files changed, 662 insertions(+), 587 deletions(-) > create mode 100644 arch/powerpc/boot/dts/p4080si.dtsi applied to next - K ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/e500mc: Add support for the wait instruction in e500_idle
On Jun 22, 2011, at 6:10 PM, Scott Wood wrote: > e500mc cannot doze or nap due to an erratum (as well as having a > different mechanism than previous e500), but it has a "wait" instruction > that is similar to doze. > > On 64-bit, due to the soft-irq-disable mechanism, the existing > book3e_idle should be used instead. > > Signed-off-by: Vakul Garg > Signed-off-by: Scott Wood > --- > arch/powerpc/kernel/idle_e500.S| 12 > arch/powerpc/platforms/85xx/p3041_ds.c |1 + > arch/powerpc/platforms/85xx/p4080_ds.c |1 + > arch/powerpc/platforms/85xx/p5020_ds.c |5 + > 4 files changed, 19 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/85xx: disable timebase synchronization under the hypervisor
On Jun 14, 2011, at 6:04 PM, Timur Tabi wrote: > The Freescale hypervisor does not allow guests to write to the timebase > registers (virtualizing the timebase register was deemed too complicated), > so don't try to synchronize the timebase registers when we're running > under the hypervisor. > > This typically happens when kexec support is enabled. > > Signed-off-by: Timur Tabi > --- > arch/powerpc/platforms/85xx/p3041_ds.c | 11 +++ > arch/powerpc/platforms/85xx/p4080_ds.c | 11 +++ > arch/powerpc/platforms/85xx/p5020_ds.c | 11 +++ > 3 files changed, 33 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 2/2] powerpc/86xx: improve calculation of DIU pixel clock on the MPC8610 HPCD
On Jun 23, 2011, at 11:16 AM, Timur Tabi wrote: > mpc8610hpcd_set_pixel_clock() calculates the correct value of the PXCLK > bits in the CLKDVDR register for a given pixel clock rate. The code which > performs this calculation is overly complicated and includes an error > estimation routine that doesn't work most of the time anyway. Replace the > code with the simpler routine that's currently used on the P1022DS. > > Signed-off-by: Timur Tabi > --- > arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 107 --- > 1 files changed, 48 insertions(+), 59 deletions(-) applied to next - K ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/4xx: Regression failed on sil24 (and other) drivers
On Mon, 2011-06-27 at 06:31 -0500, Ayman El-Khashab wrote: > That was my initial thought as well, but I wasn't versed > enough in the pci magic in order to completely figure it > out. > > Here is the output, it is dmesg, iomem, then ioports for the > passing and then the failing cases. Ok, I can see some resource allocation errors in the log, I don't have enough active brain cells left today to figure out what's going on but I'll have a look tomorrow. Cheers, Ben. > thanks > ayman > > == Passing == > > Using PowerPC 44x Platform machine description > Linux version 2.6.36-rc3-00186-g0e52247-dirty (aymane@lablinux) (gcc version > 4.2.2) #18 Sat Jun 25 13:51:44 CDT 2011 > Found initrd at 0xdfa5c000:0xdfe4cbfa > Found legacy serial port 0 for /plb/opb/serial@ef600300 > mem=4ef600300, taddr=4ef600300, irq=0, clk=6451612, speed=0 > Found legacy serial port 1 for /plb/opb/serial@ef600400 > mem=4ef600400, taddr=4ef600400, irq=0, clk=6451612, speed=0 > Top of RAM: 0x2000, Total RAM: 0x2000 > Memory hole size: 0MB > Zone PFN ranges: > DMA 0x -> 0x0002 > Normal empty > HighMem empty > Movable zone start PFN for each node > early_node_map[1] active PFN ranges > 0: 0x -> 0x0002 > On node 0 totalpages: 131072 > free_area_init_node: node 0, pgdat c03b9f48, node_mem_map c03ed000 > DMA zone: 1024 pages used for memmap > DMA zone: 0 pages reserved > DMA zone: 130048 pages, LIFO batch:31 > MMU: Allocated 1088 bytes of context maps for 255 contexts > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 > Kernel command line: root=/dev/ram rw mem=512M > ip=169.254.0.180:169.254.0.100:169.254.0.100:255.255.255.0:tanosx:eth0:off > panic=1 console=ttyS0,57600 > PID hash table entries: 2048 (order: 1, 8192 bytes) > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > High memory: 0k > Memory: 511668k/524288k available (3692k kernel code, 12620k reserved, 176k > data, 141k bss, 184k init) > Kernel virtual memory layout: > * 0xfffcf000..0xf000 : fixmap > * 0xffc0..0xffe0 : highmem PTEs > * 0xffa0..0xffc0 : consistent mem > * 0xffa0..0xffa0 : early ioremap > * 0xe100..0xffa0 : vmalloc & ioremap > SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > NR_IRQS:512 > UIC0 (32 IRQ sources) at DCR 0xc0 > UIC1 (32 IRQ sources) at DCR 0xd0 > irq: irq 30 on host /interrupt-controller0 mapped to virtual irq 30 > UIC2 (32 IRQ sources) at DCR 0xe0 > irq: irq 10 on host /interrupt-controller0 mapped to virtual irq 16 > UIC3 (32 IRQ sources) at DCR 0xf0 > irq: irq 16 on host /interrupt-controller0 mapped to virtual irq 17 > time_init: decrementer frequency = 800.10 MHz > time_init: processor frequency = 800.10 MHz > clocksource: timebase mult[50] shift[22] registered > clockevent: decrementer mult[ccf7] shift[32] cpu[0] > pid_max: default: 32768 minimum: 301 > Mount-cache hash table entries: 512 > NET: Registered protocol family 16 > i2c-core: driver [dummy] registered > irq: irq 11 on host /interrupt-controller1 mapped to virtual irq 18 > 256k L2-cache enabled > PCIE0: Checking link... > PCIE0: No device detected. > PCI host bridge /plb/pciex@d (primary) ranges: > MEM 0x000e..0x000e7fff -> 0x8000 > MEM 0x000f..0x000f000f -> 0x > IO 0x000f8000..0x000f8000 -> 0x > Removing ISA hole at 0x000f > 4xx PCI DMA offset set to 0x > /plb/pciex@d: Legacy ISA memory support enabled > PCIE0: successfully set as root-complex > PCIE1: Checking link... > PCIE1: Device detected, waiting for link... > PCIE1: link is up ! > PCI host bridge /plb/pciex@d2000 (primary) ranges: > MEM 0x000e8000..0x000e -> 0x8000 > MEM 0x000f0010..0x000f001f -> 0x > IO 0x000f8001..0x000f8001 -> 0x > Removing ISA hole at 0x000f0010 > 4xx PCI DMA offset set to 0x > /plb/pciex@d2000: Legacy ISA memory support enabled > PCIE1: successfully set as root-complex > PCI host bridge /plb/pci@c0ec0 (primary) ranges: > MEM 0x000d8000..0x000d -> 0x8000 > MEM 0x000c0ee0..0x000c0eef -> 0x > IO 0x000c0800..0x000c0800 -> 0x > Removing ISA hole at 0x000c0ee0 > 4xx PCI DMA offset set to 0x > /plb/pci@c0ec0: Legacy ISA memory support enabled > PCI: Probing PCI hardware > pci_bus :40: scanning bus > pci :40:00.0: found [aaa0:bed0] class 000604 header type 01 > pci :40:00.0: reg 10: [mem 0x-0x7fff pref] > pci_bus :40: fixups for bus > pci :40:00.0: scanning [bus 41-7f] behind bridge, pass 0 > pci_bus
Re: powerpc/4xx: Regression failed on sil24 (and other) drivers
On Mon, Jun 27, 2011 at 08:19:56PM +1000, Benjamin Herrenschmidt wrote: > On Sat, 2011-06-25 at 18:52 -0500, Ayman El-Khashab wrote: > > I noticed during a recent development with the 460SX that a > > simple device that once worked stopped. I did a bisect to > > find the offending commit and it turns out to be this one: > > > > 0e52247a2ed1f211f0c4f682dc999610a368903f is the first bad > > commit > > commit 0e52247a2ed1f211f0c4f682dc999610a368903f > > Author: Cam Macdonell > > Date: Tue Sep 7 17:25:20 2010 -0700 > > > > PCI: fix pci_resource_alignment prototype > > > > > > The device driver fails with "error -22" on a 460SX (which > > has the 36 bit pci space). > > > > sil24 /drivers/ata/sata_sil24.c > > Can you send a dmesg & output of /proc/iomem & ioport with and without > the patch (same kernel otherwise) ? > > Also can you try to figure out (printk's) where in the driver does it > fail ? (Which function fails) Yes, here is the output from a canyonlands (460ex) that exhibits the same problem and in the same place. Of the two devices I have that fail (sil24 and one other), both fail in exactly the same place in lib/devres.c within the function pcim_iomap_regions. In that function, there is the following call -- it fails b/c len returns 0 and tha failure bubbles up to "error -22". len = pci_resource_len(pdev, i); > It's possible that this changes something in the core resource > assignment code causing something else to fail elsewhere or exposing > another bug elsewhere with the consequence of leaving the SiL with badly > assigned resources. That was my initial thought as well, but I wasn't versed enough in the pci magic in order to completely figure it out. Here is the output, it is dmesg, iomem, then ioports for the passing and then the failing cases. thanks ayman == Passing == Using PowerPC 44x Platform machine description Linux version 2.6.36-rc3-00186-g0e52247-dirty (aymane@lablinux) (gcc version 4.2.2) #18 Sat Jun 25 13:51:44 CDT 2011 Found initrd at 0xdfa5c000:0xdfe4cbfa Found legacy serial port 0 for /plb/opb/serial@ef600300 mem=4ef600300, taddr=4ef600300, irq=0, clk=6451612, speed=0 Found legacy serial port 1 for /plb/opb/serial@ef600400 mem=4ef600400, taddr=4ef600400, irq=0, clk=6451612, speed=0 Top of RAM: 0x2000, Total RAM: 0x2000 Memory hole size: 0MB Zone PFN ranges: DMA 0x -> 0x0002 Normal empty HighMem empty Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0002 On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c03b9f48, node_mem_map c03ed000 DMA zone: 1024 pages used for memmap DMA zone: 0 pages reserved DMA zone: 130048 pages, LIFO batch:31 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/ram rw mem=512M ip=169.254.0.180:169.254.0.100:169.254.0.100:255.255.255.0:tanosx:eth0:off panic=1 console=ttyS0,57600 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) High memory: 0k Memory: 511668k/524288k available (3692k kernel code, 12620k reserved, 176k data, 141k bss, 184k init) Kernel virtual memory layout: * 0xfffcf000..0xf000 : fixmap * 0xffc0..0xffe0 : highmem PTEs * 0xffa0..0xffc0 : consistent mem * 0xffa0..0xffa0 : early ioremap * 0xe100..0xffa0 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:512 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 irq: irq 30 on host /interrupt-controller0 mapped to virtual irq 30 UIC2 (32 IRQ sources) at DCR 0xe0 irq: irq 10 on host /interrupt-controller0 mapped to virtual irq 16 UIC3 (32 IRQ sources) at DCR 0xf0 irq: irq 16 on host /interrupt-controller0 mapped to virtual irq 17 time_init: decrementer frequency = 800.10 MHz time_init: processor frequency = 800.10 MHz clocksource: timebase mult[50] shift[22] registered clockevent: decrementer mult[ccf7] shift[32] cpu[0] pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 NET: Registered protocol family 16 i2c-core: driver [dummy] registered irq: irq 11 on host /interrupt-controller1 mapped to virtual irq 18 256k L2-cache enabled PCIE0: Checking link... PCIE0: No device detected. PCI host bridge /plb/pciex@d (primary) ranges: MEM 0x000e..0x000e7fff -> 0x8000 MEM 0x000f..0x000f000f -> 0x IO 0x000f8000..0x000f8000 -> 0x Removing ISA hole at 0x000f 4xx PCI DMA offset set to 0x /plb/pciex@d: Legacy ISA memory support enabled PCIE0: successfully set as root-complex PCIE1: Checking link... PCIE1: Device
Re: powerpc/4xx: Regression failed on sil24 (and other) drivers
On Sat, 2011-06-25 at 18:52 -0500, Ayman El-Khashab wrote: > I noticed during a recent development with the 460SX that a > simple device that once worked stopped. I did a bisect to > find the offending commit and it turns out to be this one: > > 0e52247a2ed1f211f0c4f682dc999610a368903f is the first bad > commit > commit 0e52247a2ed1f211f0c4f682dc999610a368903f > Author: Cam Macdonell > Date: Tue Sep 7 17:25:20 2010 -0700 > > PCI: fix pci_resource_alignment prototype > > I found it working with 2.6.36 but it seems that it is in > the current trunk as well. > > I patched my code to take out this commit and (quickly) > verified it was ok. I am guessing the patch is ok since it > converts int types to resource_size_t. My guess is that the > problem is in the sil24 driver but I did not see anything > obvious in that code. Any tips on what could be wrong? Is > the problem potentially somewhere being called by that code? > > The device driver fails with "error -22" on a 460SX (which > has the 36 bit pci space). > > sil24 /drivers/ata/sata_sil24.c Can you send a dmesg & output of /proc/iomem & ioport with and without the patch (same kernel otherwise) ? Also can you try to figure out (printk's) where in the driver does it fail ? (Which function fails) It's possible that this changes something in the core resource assignment code causing something else to fail elsewhere or exposing another bug elsewhere with the consequence of leaving the SiL with badly assigned resources. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
On Mon, 2011-06-27 at 05:14 -0500, Ayman El-Khashab wrote: > > I took care of that in my patch. Basically it let the > > system go to gen-2 speeds and negotiate down. > > [marri] Great thx. > > Ok, so I am back from doing whatever it is that I do. Shall > I go ahead and take a stab at making a new functor to handle > the "link check"? -- which IIRC was the thought from last > month about how best to handle the 460SX and whatever some > people were using internally. Catch up with Tony (CC), he's working on something similar for a new variant of that PCIe controller used internally by some IBM stuff. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
On Tue, May 31, 2011 at 02:27:19PM -0700, Tirumala Marri wrote: > Not sure how I would know -- But with my eiger kit, I got a > cd from amcc that had a patched 2.6.30 or something kernel > in it to support the 460SX. The pci code was basically > subverted by adding a "port->link=1" at the very end of the > link check to always force it to succeed. However this code > never appeared in the public git repositories, so I am not > sure how the 460SX functioned (if it ever did) since the > link check that is in there now can't work on that SOC. > > > [marri]I don't know what PCI-E devices you use. We use E1000 > As a device for testing. Link-up was working before the submission. > There were some changes happened afterwards to the common code > Which seems to affected all 4xx devices. I will try latest code > On our other SoCs. Well, briefly we build a custom processor board that has a couple powerpcs on it and some pcie switches. We end up plugging our devices into the switches which is unlike what most people try. In any case, we use several different drive controllers for SAS, SCSI, and SSDs. For testing purposes (i.e. when things don't go the way they should) we have an adapter to make "regular" pcie slots that we plug in whatever. But our switches are on the board with the CPUs so as far as the CPU goes, it will always see a gen-2 link 8 lane link, irrespective of what the endpoint actually is. We let the switches handle the speed changes and the port bifurcation. > I took care of that in my patch. Basically it let the > system go to gen-2 speeds and negotiate down. > [marri] Great thx. Ok, so I am back from doing whatever it is that I do. Shall I go ahead and take a stab at making a new functor to handle the "link check"? -- which IIRC was the thought from last month about how best to handle the 460SX and whatever some people were using internally. Ayman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze
On Sun, Jun 26, 2011 at 11:47:13PM +0900, Masami Hiramatsu wrote: > (2011/06/24 19:29), Steven Rostedt wrote: > > On Fri, 2011-06-24 at 17:21 +0800, Yong Zhang wrote: > >> Hi, > >> > >> When I use kprobe to do something, I found some wired thing. > >> > >> When CONFIG_FUNCTION_TRACER is disabled: > >> (gdb) disassemble do_fork > >> Dump of assembler code for function do_fork: > >>0xc0037390 <+0>:mflrr0 > >>0xc0037394 <+4>:stwur1,-64(r1) > >>0xc0037398 <+8>:mfcrr12 > >>0xc003739c <+12>: stmwr27,44(r1) > >> > >> Then I: > >> modprobe kprobe_example func=do_fork offset=4 > >> ls > >> Things works well. > >> > >> But when CONFIG_FUNCTION_TRACER is enabled: > >> (gdb) disassemble do_fork > >> Dump of assembler code for function do_fork: > >>0xc0040334 <+0>:mflrr0 > >>0xc0040338 <+4>:stw r0,4(r1) > >>0xc004033c <+8>:bl 0xc00109d4 > >>0xc0040340 <+12>: stwur1,-80(r1) > >>0xc0040344 <+16>: mflrr0 > >>0xc0040348 <+20>: stw r0,84(r1) > >>0xc004034c <+24>: mfcrr12 > >> Then I: > >> modprobe kprobe_example func=do_fork offset=12 > >> ls > >> 'ls' will never retrun. system freeze. > > > > I'm not sure if x86 had a similar issue. > > > > Masami, have any ideas to why this happened? > > No, I don't familiar with ppc implementation. I guess > that single-step resume code failed to emulate the > instruction, but it strongly depends on ppc arch. > Maybe IBM people may know what happened. > > Ananth, Jim, would you have any ideas? On powerpc, we emulate sstep whenever possible. Only recently support to emulate loads and stores got added. I don't have access to a powerpc box today... but will try to recreate the problem ASAP and see what could be happening in the presence of mcount. Ananth ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hwrng: ppc4xx - add support for ppc4xx TRNG
On Tue, Jun 21, 2011 at 10:56:02AM -0500, Matt Mackall wrote: > On Tue, 2011-06-21 at 08:19 -0400, Josh Boyer wrote: > > Various PowerPC 4xx SoCs contain a TRNG embedded in the Security function. > > This adds a device driver for that TRNG. > > > > Signed-off-by: Josh Boyer > > Looks good. > > Acked-by: Matt Mackall Also applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] crypto: crypto4xx - Perform read/modify/write on device control register
On Tue, Jun 21, 2011 at 08:13:21AM -0400, Josh Boyer wrote: > The Security function on the AMCC SoCs has multiple engines within a > single MMIO range. The crypto driver currently enables the 3DES > functionality by doing a blind write to the device control register. > This can unintentionally disable other functions like the PKA or TRNG > when the driver is loaded. > > Perform a read/modify/write to enable the 3DES function instead. > > Signed-off-by: Josh Boyer Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
