* RE: [PATCH 2/4] mpc8569mds: Add bscr setting for rtbi mode
From: Liu Yu-B13201 @ 2010-02-02 5:57 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, linuxppc-dev, davem
In-Reply-To: <fa686aa41002011357pb24d8a6k640ab5ae13f8fbbc@mail.gmail.com>
Thanks.
As the patchset is accepted.
Will commit another one to fix them.
=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Tuesday, February 02, 2010 5:58 AM
> To: Liu Yu-B13201
> Cc: galak@kernel.crashing.org; davem@davemloft.net;=20
> netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 2/4] mpc8569mds: Add bscr setting for rtbi mode
>=20
> On Thu, Jan 14, 2010 at 1:13 AM, Liu Yu <yu.liu@freescale.com> wrote:
> > Signed-off-by: Liu Yu <yu.liu@freescale.com>
> > ---
> > =A0arch/powerpc/platforms/85xx/mpc85xx_mds.c | =A0 24=20
> ++++++++++++++++++++++++
> > =A01 files changed, 24 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c=20
> b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > index c5028a2..0872e4a 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > @@ -237,6 +237,8 @@ static void __init mpc85xx_mds_setup_arch(void)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (machine_is(mpc8569_mds)) {
> > =A0#define BCSR7_UCC12_GETHnRST =A0 (0x1 << 2)
> > =A0#define BCSR8_UEM_MARVELL_RST =A0(0x1 << 1)
> > +#define BCSR_UCC_RGMII =A0 =A0 =A0 =A0 (0x1 << 6)
> > +#define BCSR_UCC_RTBI =A0 =A0 =A0 =A0 =A0(0x1 << 5)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * U-Boot mangles =
interrupt polarity=20
> for Marvell PHYs,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * so reset built-in =
and UEM Marvell=20
> PHYs, this puts
> > @@ -247,6 +249,28 @@ static void __init mpc85xx_mds_setup_arch(void)
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0setbits8(&bcsr_regs[7],=20
> BCSR7_UCC12_GETHnRST);
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0clrbits8(&bcsr_regs[8],=20
> BCSR8_UEM_MARVELL_RST);
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (np =3D NULL; (np =
=3D=20
> of_find_compatible_node(np,
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "network",
>=20
> Don't match on the 'type' field. Replace "network" with NULL and just
> rely on "ucc_geth" for matching.
>=20
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20
> "ucc_geth")) !=3D NULL;) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const =
unsigned int *prop;
>=20
> u32 please.
>=20
> Also, rather than reusing 'prop' for both char* and u32 values, which
> forces you to use ugly casts, use 2 local variables here.
>=20
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int =
ucc_num;
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 prop =
=3D of_get_property(np,=20
> "cell-index", NULL);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if =
(prop =3D=3D NULL)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 continue;
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
ucc_num =3D *prop - 1;
>=20
> Ugh. No bounds checking...
>=20
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 prop =
=3D of_get_property(np,=20
> "phy-connection-type", NULL);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if =
(prop =3D=3D NULL)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 continue;
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if =
(strcmp("rtbi", (const=20
> char *)prop) =3D=3D 0)
>=20
> (This is the ugly cast I was talking about.)
>=20
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0=20
> clrsetbits_8(&bcsr_regs[7 + ucc_num],
>=20
> ...not having bounds checking could result in badness in this=20
> array index.
>=20
> This patch is dangerous as written.
>=20
> Finally, while using cell-index seems convenient, I think it would be
> better to have a lookup table of the index into the BCSR register
> block from the UCC base address, which also gives you implicit bounds
> checking.
>=20
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>=20
>=20
^ permalink raw reply
* Re: [PATCH] powerpc: Add DMA mask to MPSC serial and network and UART device to serial
From: Benjamin Herrenschmidt @ 2010-02-02 7:38 UTC (permalink / raw)
To: Corey Minyard; +Cc: linuxppc-dev
In-Reply-To: <4B6716D8.2050209@acm.org>
On Mon, 2010-02-01 at 12:00 -0600, Corey Minyard wrote:
> That's done in ppc_dflt_bus_notify(), but that didn't seem an
> appropriate
> place to do this. If it is, it's easy enough to add it there, but
> that would mean it would get set for all devices on any type of ppc
> system.
Well, we are looking at setting up a sane default here. It can always be
overriden if necessary.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 0/3] powerpc: mpc5121: PSC UART support
From: Anatolij Gustschin @ 2010-02-02 7:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: wd, dzu
The support for mpc5121 PSC UART currently only works with
serial console. This patch series re-enable PSC UART support for
all 12 PSCs and document added DTS bingings.
---
.../powerpc/dts-bindings/fsl/mpc5121-psc.txt | 70 ++++++
arch/powerpc/include/asm/mpc52xx_psc.h | 4 +
drivers/serial/mpc52xx_uart.c | 250 +++++++++++++++++++-
3 files changed, 313 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH 1/3] serial: mpc52xx_uart: re-enable mpc5121 PSC UART support
From: Anatolij Gustschin @ 2010-02-02 7:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, wd, dzu
In-Reply-To: <1265096864-3506-1-git-send-email-agust@denx.de>
Currently the support for MPC5121 PSC UART in the mpc52xx_uart
driver is broken (only console pre-initialized by the bootloader
works). Re-enable it now by providing MPC5121 specific ops
for PSCx clock activation, FIFO controller init/uninit and
MPC5121 PSC FIFO shared interrupt handling functions.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
This patch has been tested using 5200/5121 multiplatform kernel
on tqm5200 and mpc5121ads boards (mpc52xx_uart staticaly linked
and as a driver module).
drivers/serial/mpc52xx_uart.c | 250 +++++++++++++++++++++++++++++++++++++++--
1 files changed, 239 insertions(+), 11 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 7ce9e9f..a084306 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -74,6 +74,7 @@
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/clk.h>
#include <asm/mpc52xx.h>
#include <asm/mpc52xx_psc.h>
@@ -113,6 +114,7 @@ static void mpc52xx_uart_of_enumerate(void);
/* Forward declaration of the interruption handling routine */
static irqreturn_t mpc52xx_uart_int(int irq, void *dev_id);
+static irqreturn_t mpc5xxx_uart_process_int(struct uart_port *port);
/* Simple macro to test if a port is console or not. This one is taken
@@ -145,6 +147,11 @@ struct psc_ops {
void (*cw_disable_ints)(struct uart_port *port);
void (*cw_restore_ints)(struct uart_port *port);
unsigned long (*getuartclk)(void *p);
+ int (*clock)(struct uart_port *port, int enable);
+ int (*fifoc_init)(void);
+ void (*fifoc_uninit)(void);
+ void (*get_irq)(struct uart_port *, struct device_node *);
+ irqreturn_t (*handle_irq)(struct uart_port *port);
};
#ifdef CONFIG_PPC_MPC52xx
@@ -256,6 +263,18 @@ static unsigned long mpc52xx_getuartclk(void *p)
return mpc5xxx_get_bus_frequency(p) / 2;
}
+static void mpc52xx_psc_get_irq(struct uart_port *port, struct device_node *np)
+{
+ port->irqflags = IRQF_DISABLED;
+ port->irq = irq_of_parse_and_map(np, 0);
+}
+
+/* 52xx specific interrupt handler. The caller holds the port lock */
+static irqreturn_t mpc52xx_psc_handle_irq(struct uart_port *port)
+{
+ return mpc5xxx_uart_process_int(port);
+}
+
static struct psc_ops mpc52xx_psc_ops = {
.fifo_init = mpc52xx_psc_fifo_init,
.raw_rx_rdy = mpc52xx_psc_raw_rx_rdy,
@@ -273,14 +292,32 @@ static struct psc_ops mpc52xx_psc_ops = {
.cw_disable_ints = mpc52xx_psc_cw_disable_ints,
.cw_restore_ints = mpc52xx_psc_cw_restore_ints,
.getuartclk = mpc52xx_getuartclk,
+ .get_irq = mpc52xx_psc_get_irq,
+ .handle_irq = mpc52xx_psc_handle_irq,
};
#endif /* CONFIG_MPC52xx */
#ifdef CONFIG_PPC_MPC512x
#define FIFO_512x(port) ((struct mpc512x_psc_fifo __iomem *)(PSC(port)+1))
+
+/* PSC FIFO Controller for mpc512x */
+struct psc_fifoc {
+ u32 fifoc_cmd;
+ u32 fifoc_int;
+ u32 fifoc_dma;
+ u32 fifoc_axe;
+ u32 fifoc_debug;
+};
+
+static struct psc_fifoc __iomem *psc_fifoc;
+static unsigned int psc_fifoc_irq;
+
static void mpc512x_psc_fifo_init(struct uart_port *port)
{
+ /* /32 prescaler */
+ out_be16(&PSC(port)->mpc52xx_psc_clock_select, 0xdd00);
+
out_be32(&FIFO_512x(port)->txcmd, MPC512x_PSC_FIFO_RESET_SLICE);
out_be32(&FIFO_512x(port)->txcmd, MPC512x_PSC_FIFO_ENABLE_SLICE);
out_be32(&FIFO_512x(port)->txalarm, 1);
@@ -393,6 +430,161 @@ static unsigned long mpc512x_getuartclk(void *p)
return mpc5xxx_get_bus_frequency(p);
}
+#define DEFAULT_FIFO_SIZE 16
+
+static unsigned int __init get_fifo_size(struct device_node *np,
+ char *fifo_name)
+{
+ const unsigned int *fp;
+
+ fp = of_get_property(np, fifo_name, NULL);
+ if (fp)
+ return *fp;
+
+ pr_warning("no %s property in %s node, defaulting to %d\n",
+ fifo_name, np->full_name, DEFAULT_FIFO_SIZE);
+
+ return DEFAULT_FIFO_SIZE;
+}
+
+#define FIFOC(_base) ((struct mpc512x_psc_fifo __iomem *) \
+ ((u32)(_base) + sizeof(struct mpc52xx_psc)))
+
+/* Init PSC FIFO Controller */
+static int __init mpc512x_psc_fifoc_init(void)
+{
+ struct device_node *np;
+ void __iomem *psc;
+ unsigned int tx_fifo_size;
+ unsigned int rx_fifo_size;
+ int fifobase = 0; /* current fifo address in 32 bit words */
+
+ np = of_find_compatible_node(NULL, NULL,
+ "fsl,mpc5121-psc-fifo");
+ if (!np) {
+ pr_err("%s: Can't find FIFOC node\n", __func__);
+ return -ENODEV;
+ }
+
+ psc_fifoc = of_iomap(np, 0);
+ if (!psc_fifoc) {
+ pr_err("%s: Can't map FIFOC\n", __func__);
+ return -ENODEV;
+ }
+
+ psc_fifoc_irq = irq_of_parse_and_map(np, 0);
+ of_node_put(np);
+ if (psc_fifoc_irq == NO_IRQ) {
+ pr_err("%s: Can't get FIFOC irq\n", __func__);
+ iounmap(psc_fifoc);
+ return -ENODEV;
+ }
+
+ for_each_compatible_node(np, NULL, "fsl,mpc5121-psc-uart") {
+ tx_fifo_size = get_fifo_size(np, "fsl,tx-fifo-size");
+ rx_fifo_size = get_fifo_size(np, "fsl,rx-fifo-size");
+
+ /* size in register is in 4 byte units */
+ tx_fifo_size /= 4;
+ rx_fifo_size /= 4;
+ if (!tx_fifo_size)
+ tx_fifo_size = 1;
+ if (!rx_fifo_size)
+ rx_fifo_size = 1;
+
+ psc = of_iomap(np, 0);
+ if (!psc) {
+ pr_err("%s: Can't map %s device\n",
+ __func__, np->full_name);
+ continue;
+ }
+
+ /* FIFO space is 4KiB, check if requested size is available */
+ if ((fifobase + tx_fifo_size + rx_fifo_size) > 0x1000) {
+ pr_err("%s: no fifo space available for %s\n",
+ __func__, np->full_name);
+ iounmap(psc);
+ /*
+ * chances are that another device requests less
+ * fifo space, so we continue.
+ */
+ continue;
+ }
+ /* set tx and rx fifo size registers */
+ out_be32(&FIFOC(psc)->txsz, (fifobase << 16) | tx_fifo_size);
+ fifobase += tx_fifo_size;
+ out_be32(&FIFOC(psc)->rxsz, (fifobase << 16) | rx_fifo_size);
+ fifobase += rx_fifo_size;
+
+ /* reset and enable the slices */
+ out_be32(&FIFOC(psc)->txcmd, 0x80);
+ out_be32(&FIFOC(psc)->txcmd, 0x01);
+ out_be32(&FIFOC(psc)->rxcmd, 0x80);
+ out_be32(&FIFOC(psc)->rxcmd, 0x01);
+
+ iounmap(psc);
+ }
+
+ return 0;
+}
+
+static void __exit mpc512x_psc_fifoc_uninit(void)
+{
+ irq_dispose_mapping(psc_fifoc_irq);
+ iounmap(psc_fifoc);
+}
+
+/* 512x specific interrupt handler. The caller holds the port lock */
+static irqreturn_t mpc512x_psc_handle_irq(struct uart_port *port)
+{
+ unsigned long fifoc_int;
+ int psc_num;
+
+ /* Read pending PSC FIFOC interrupts */
+ fifoc_int = in_be32(&psc_fifoc->fifoc_int);
+
+ /* Check if it is an interrupt for this port */
+ psc_num = (port->mapbase & 0xf00) >> 8;
+ if (test_bit(psc_num, &fifoc_int) ||
+ test_bit(psc_num + 16, &fifoc_int))
+ return mpc5xxx_uart_process_int(port);
+
+ return IRQ_NONE;
+}
+
+static int mpc512x_psc_clock(struct uart_port *port, int enable)
+{
+ struct clk *psc_clk;
+ int psc_num;
+ char clk_name[10];
+
+ if (uart_console(port))
+ return 0;
+
+ psc_num = (port->mapbase & 0xf00) >> 8;
+ snprintf(clk_name, sizeof(clk_name), "psc%d_clk", psc_num);
+ psc_clk = clk_get(port->dev, clk_name);
+ if (IS_ERR(psc_clk)) {
+ dev_err(port->dev, "Failed to get PSC clock entry!\n");
+ return -ENODEV;
+ }
+
+ dev_dbg(port->dev, "%s %sable\n", clk_name, enable ? "en" : "dis");
+
+ if (enable)
+ clk_enable(psc_clk);
+ else
+ clk_disable(psc_clk);
+
+ return 0;
+}
+
+static void mpc512x_psc_get_irq(struct uart_port *port, struct device_node *np)
+{
+ port->irqflags = IRQF_SHARED;
+ port->irq = psc_fifoc_irq;
+}
+
static struct psc_ops mpc512x_psc_ops = {
.fifo_init = mpc512x_psc_fifo_init,
.raw_rx_rdy = mpc512x_psc_raw_rx_rdy,
@@ -410,6 +602,11 @@ static struct psc_ops mpc512x_psc_ops = {
.cw_disable_ints = mpc512x_psc_cw_disable_ints,
.cw_restore_ints = mpc512x_psc_cw_restore_ints,
.getuartclk = mpc512x_getuartclk,
+ .clock = mpc512x_psc_clock,
+ .fifoc_init = mpc512x_psc_fifoc_init,
+ .fifoc_uninit = mpc512x_psc_fifoc_uninit,
+ .get_irq = mpc512x_psc_get_irq,
+ .handle_irq = mpc512x_psc_handle_irq,
};
#endif
@@ -519,10 +716,15 @@ mpc52xx_uart_startup(struct uart_port *port)
struct mpc52xx_psc __iomem *psc = PSC(port);
int ret;
+ if (psc_ops->clock) {
+ ret = psc_ops->clock(port, 1);
+ if (ret)
+ return ret;
+ }
+
/* Request IRQ */
ret = request_irq(port->irq, mpc52xx_uart_int,
- IRQF_DISABLED | IRQF_SAMPLE_RANDOM,
- "mpc52xx_psc_uart", port);
+ port->irqflags, "mpc52xx_psc_uart", port);
if (ret)
return ret;
@@ -553,6 +755,9 @@ mpc52xx_uart_shutdown(struct uart_port *port)
port->read_status_mask = 0;
out_be16(&psc->mpc52xx_psc_imr, port->read_status_mask);
+ if (psc_ops->clock)
+ psc_ops->clock(port, 0);
+
/* Release interrupt */
free_irq(port->irq, port);
}
@@ -851,15 +1056,12 @@ mpc52xx_uart_int_tx_chars(struct uart_port *port)
}
static irqreturn_t
-mpc52xx_uart_int(int irq, void *dev_id)
+mpc5xxx_uart_process_int(struct uart_port *port)
{
- struct uart_port *port = dev_id;
unsigned long pass = ISR_PASS_LIMIT;
unsigned int keepgoing;
u8 status;
- spin_lock(&port->lock);
-
/* While we have stuff to do, we continue */
do {
/* If we don't find anything to do, we stop */
@@ -886,11 +1088,23 @@ mpc52xx_uart_int(int irq, void *dev_id)
} while (keepgoing);
- spin_unlock(&port->lock);
-
return IRQ_HANDLED;
}
+static irqreturn_t
+mpc52xx_uart_int(int irq, void *dev_id)
+{
+ struct uart_port *port = dev_id;
+ irqreturn_t ret;
+
+ spin_lock(&port->lock);
+
+ ret = psc_ops->handle_irq(port);
+
+ spin_unlock(&port->lock);
+
+ return ret;
+}
/* ======================================================================== */
/* Console ( if applicable ) */
@@ -1152,7 +1366,7 @@ mpc52xx_uart_of_probe(struct of_device *op, const struct of_device_id *match)
return -EINVAL;
}
- port->irq = irq_of_parse_and_map(op->node, 0);
+ psc_ops->get_irq(port, op->node);
if (port->irq == NO_IRQ) {
dev_dbg(&op->dev, "Could not get irq\n");
return -EINVAL;
@@ -1164,7 +1378,8 @@ mpc52xx_uart_of_probe(struct of_device *op, const struct of_device_id *match)
/* Add the port to the uart sub-system */
ret = uart_add_one_port(&mpc52xx_uart_driver, port);
if (ret) {
- irq_dispose_mapping(port->irq);
+ if (!(port->irqflags & IRQF_SHARED))
+ irq_dispose_mapping(port->irq);
return ret;
}
@@ -1180,7 +1395,8 @@ mpc52xx_uart_of_remove(struct of_device *op)
if (port) {
uart_remove_one_port(&mpc52xx_uart_driver, port);
- irq_dispose_mapping(port->irq);
+ if (!(port->irqflags & IRQF_SHARED))
+ irq_dispose_mapping(port->irq);
}
return 0;
@@ -1288,6 +1504,15 @@ mpc52xx_uart_init(void)
mpc52xx_uart_of_enumerate();
+ /*
+ * Map the PSC FIFO Controller and init if on MPC512x.
+ */
+ if (psc_ops->fifoc_init) {
+ ret = psc_ops->fifoc_init();
+ if (ret)
+ return ret;
+ }
+
ret = of_register_platform_driver(&mpc52xx_uart_of_driver);
if (ret) {
printk(KERN_ERR "%s: of_register_platform_driver failed (%i)\n",
@@ -1302,6 +1527,9 @@ mpc52xx_uart_init(void)
static void __exit
mpc52xx_uart_exit(void)
{
+ if (psc_ops->fifoc_uninit)
+ psc_ops->fifoc_uninit();
+
of_unregister_platform_driver(&mpc52xx_uart_of_driver);
uart_unregister_driver(&mpc52xx_uart_driver);
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] powerpc: doc/dts-bindings: document mpc5121 psc uart dts-bindings
From: Anatolij Gustschin @ 2010-02-02 7:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, wd, dzu
In-Reply-To: <1265096864-3506-1-git-send-email-agust@denx.de>
Support for MPC5121 PSC UART in the mpc52xx_uart driver
added new DTS properties for FSL MPC5121 PSC FIFO Controller.
Provide documentation of the new properties and some examples.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
.../powerpc/dts-bindings/fsl/mpc5121-psc.txt | 70 ++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt b/Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt
new file mode 100644
index 0000000..8832e87
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt
@@ -0,0 +1,70 @@
+MPC5121 PSC Device Tree Bindings
+
+PSC in UART mode
+----------------
+
+For PSC in UART mode the needed PSC serial devices
+are specified by fsl,mpc5121-psc-uart nodes in the
+fsl,mpc5121-immr SoC node. Additionally the PSC FIFO
+Controller node fsl,mpc5121-psc-fifo is requered there:
+
+fsl,mpc5121-psc-uart nodes
+--------------------------
+
+Required properties :
+ - compatible : Should contain "fsl,mpc5121-psc-uart" and "fsl,mpc5121-psc"
+ - cell-index : Index of the PSC in hardware
+ - reg : Offset and length of the register set for the PSC device
+ - interrupts : <a b> where a is the interrupt number of the
+ PSC FIFO Controller and b is a field that represents an
+ encoding of the sense and level information for the interrupt.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+Recommended properties :
+ - fsl,rx-fifo-size : the size of the RX fifo slice (a multiple of 4)
+ - fsl,tx-fifo-size : the size of the TX fifo slice (a multiple of 4)
+
+
+fsl,mpc5121-psc-fifo node
+-------------------------
+
+Required properties :
+ - compatible : Should be "fsl,mpc5121-psc-fifo"
+ - reg : Offset and length of the register set for the PSC
+ FIFO Controller
+ - interrupts : <a b> where a is the interrupt number of the
+ PSC FIFO Controller and b is a field that represents an
+ encoding of the sense and level information for the interrupt.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+
+Example for a board using PSC0 and PSC1 devices in serial mode:
+
+serial@11000 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <0>;
+ reg = <0x11000 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = < &ipic >;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+};
+
+serial@11100 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <1>;
+ reg = <0x11100 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = < &ipic >;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+};
+
+pscfifo@11f00 {
+ compatible = "fsl,mpc5121-psc-fifo";
+ reg = <0x11f00 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = < &ipic >;
+};
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] powerpc: mpc5121: enable support for more PSC UARTs
From: Anatolij Gustschin @ 2010-02-02 7:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, wd, dzu
In-Reply-To: <1265096864-3506-1-git-send-email-agust@denx.de>
MPC5121 has 12 PSC devices. Enable UART support for all of
them by defining the number of max. PSCs depending on
selection of PPC_MPC512x platform support.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/mpc52xx_psc.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h b/arch/powerpc/include/asm/mpc52xx_psc.h
index fb84120..42561f4 100644
--- a/arch/powerpc/include/asm/mpc52xx_psc.h
+++ b/arch/powerpc/include/asm/mpc52xx_psc.h
@@ -25,7 +25,11 @@
#include <asm/types.h>
/* Max number of PSCs */
+#ifdef CONFIG_PPC_MPC512x
+#define MPC52xx_PSC_MAXNUM 12
+#else
#define MPC52xx_PSC_MAXNUM 6
+#endif
/* Programmable Serial Controller (PSC) status register bits */
#define MPC52xx_PSC_SR_UNEX_RX 0x0001
--
1.6.3.3
^ permalink raw reply related
* RE: fsldma: cleanup driver and fix async_tx compatibility
From: Dudhat Dipen-B09055 @ 2010-02-02 7:50 UTC (permalink / raw)
To: Ira W. Snyder
Cc: herbert, Suresh Vishnu-B05022, Tabi Timur-B04825, linuxppc-dev,
dan.j.williams, Gupta Maneesh-B18878, Li Yang-R58472
In-Reply-To: <20100111162900.GA10110@ovro.caltech.edu>
=20
Hi Ira,
Do these patches accepted to open source kernel??
- Dipen
-----Original Message-----
From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]=20
Sent: Monday, January 11, 2010 9:59 PM
To: Dudhat Dipen-B09055
Cc: dan.j.williams@intel.com; galak@kernel.crashing.org;
herbert@gondor.apana.org.au; Tabi Timur-B04825; linuxppc-dev@ozlabs.org;
Suresh Vishnu-B05022; Gupta Maneesh-B18878; Li Yang-R58472
Subject: Re: fsldma: cleanup driver and fix async_tx compatibility
On Mon, Jan 11, 2010 at 11:17:04AM +0530, Dudhat Dipen-B09055 wrote:
>=20
> Hi Ira,
>=20
> I have tested your patches with async DMA memcpy support. Though I=20
> haven't captured the improvement figures.
> It works fine for RAID5 memcpy offload as interrupts are coming for=20
> separate DMA channels while I have ran IOZONE onto RAID partition.
>=20
Excellent, thanks for running these tests. I'm glad to hear that the
RAID offload is working now.
You shouldn't notice any difference in performance. On a 32MB memcpy
operation, broken into 32x 1MB memcpy(), 1x interrupt(), I noticed less
than 0.1% difference (approx 100,000 ns / 0.1ms). This is probably at or
near the limits of my measurement accuracy.
Ira
> Regards,
> Dipen
> =20
>=20
> -----Original Message-----
> From: Dudhat Dipen-B09055
> Sent: Tuesday, January 05, 2010 11:38 AM
> To: 'Ira W. Snyder'; dan.j.williams@intel.com
> Cc: galak@kernel.crashing.org; herbert@gondor.apana.org.au; Tabi=20
> Timur-B04825; linuxppc-dev@ozlabs.org; Suresh Vishnu-B05022; Gupta=20
> Maneesh-B18878; Li Yang-R58472
> Subject: RE: fsldma: cleanup driver and fix async_tx compatibility
>=20
>=20
> Hi Ira,
>=20
> I will test it on 85xx hardware and let you know once done.
>=20
> Thanks
> Dipen
> =20
>=20
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Friday, January 01, 2010 11:41 AM
> To: dan.j.williams@intel.com
> Cc: galak@kernel.crashing.org; herbert@gondor.apana.org.au; Tabi=20
> Timur-B04825; linuxppc-dev@ozlabs.org; Suresh Vishnu-B05022; Dudhat=20
> Dipen-B09055; Gupta Maneesh-B18878; Li Yang-R58472
> Subject: fsldma: cleanup driver and fix async_tx compatibility
>=20
> This patch series cleans up the Freescale DMAEngine driver, including=20
> verifying the locking and making sure that all code paths are correct.
> There were a few places that seemed suspicious, and they have been=20
> fixed.
>=20
> I have written a quick memory->memory DMAEngine test driver, and the=20
> performance is identical before and after my changes (<0.1% change). I
> measured both setting up the DMA operation (via
> device_prep_dma_interrupt() and device_prep_dma_memcpy()) and the=20
> actual DMA transfer itself.
>=20
> As an added bonus, the interrupt load is measurably reduced. My test=20
> driver transfers 32MB as 32x 1MB chunks + 1 interrupt descriptor,=20
> using the functions noted above. Previous to this patch series, 31=20
> interrupts were generated. After this patch series, only a single=20
> interrupt is generated for the whole transaction.
>=20
> Some testing on 85xx/86xx hardware would be appreciated. Also, some=20
> testing by the users attempting to use async_tx and talitos to handle=20
> RAID offload would be great as well.
>=20
> Documentation/powerpc/dts-bindings/fsl/dma.txt | 17 +-
> drivers/dma/fsldma.c | 1036
> ++++++++++++------------
> drivers/dma/fsldma.h | 35 +-
> 3 files changed, 556 insertions(+), 532 deletions(-)
>=20
> Thanks,
> Ira
>=20
^ permalink raw reply
* Re: [PATCH 1/7] powerpc: Reduce footprint of irq_stat
From: Christoph Hellwig @ 2010-02-02 8:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Christoph Hellwig, Anton Blanchard
In-Reply-To: <1265065630.8287.46.camel@pasglop>
On Tue, Feb 02, 2010 at 10:07:10AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-02-01 at 22:55 +0100, Christoph Hellwig wrote:
>
> > > +typedef struct {
> > > + unsigned int __softirq_pending;
> > > +} ____cacheline_aligned irq_cpustat_t;
> >
> > No need to bother with an irq_cpustat_t type at all in this case, just
> > declare a softirq_pending per-cpu variable.
>
> I think his subsequent patches add members to that struct for
> CE, MCE etc... stats.
Well, if you want those in a structure for arch-local reasons please
give them an arch-local name. I really want to get rid of the current
concept of a generic irq_cpustat_t - it doens't make much sense in
it's current form. Instead the API will be the local_softirq_pending()
function/macro with arch specific or a generic implementation.
^ permalink raw reply
* Locale issue
From: Eda Ercan @ 2010-02-02 8:54 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am trying to setlocale on ppc, but due to memory shortage, the
locale package is not installed completely- only the related files are
copied. There may be a missing file but I cannot find which is.
int main()
{
if ( setlocale(LC_COLLATE,"tr_TR") == NULL )
printf("could not set locale\n");
return 0;
}
setlocale does not work and the code prints the err message. strace
output is as follows. I cannot understand why it is trying to open
"/usr/lib/locale/tr/LC_COLLATE" after finding
"/usr/lib/locale/tr_TR/LC_COLLATE".
Does anybody have an idea??
execve("./m", ["m"], [/* 8 vars */]) = 0
uname({sys="Linux", node="z1", ...}) = 0
brk(0) = 0x10010a4c
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x30015000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\300"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1299948, ...}) = 0
mmap(0xfea1000, 1370752, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xfea1000
mprotect(0xffd8000, 96896, PROT_NONE) = 0
mmap(0xffe1000, 49152, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x130000) = 0xffe1000
mmap(0xffed000, 10880, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
close(3) = 0
brk(0) = 0x10010a4c
brk(0x10011a4c) = 0x10011a4c
brk(0x10012000) = 0x10012000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x30016000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
read(3, "", 4096) = 0
close(3) = 0
munmap(0x30016000, 4096) = 0
open("/usr/lib/locale/tr_TR/LC_COLLATE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=22471, ...}) = 0
mmap(NULL, 22471, PROT_READ, MAP_PRIVATE, 3, 0) = 0x30016000
close(3) = 0
munmap(0x30016000, 22471) = 0
open("/usr/lib/locale/tr/LC_COLLATE", O_RDONLY) = -1 ENOENT (No such
file or directory)
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(3, 0), ...}) = 0
ioctl(1, TCGETS, {B9600 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x30016000
write(1, "could not set locale\n", 21could not set locale
) = 21
munmap(0x30016000, 4096) = 0
exit(0) = ?
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: fsldma: cleanup driver and fix async_tx compatibility
From: Dan Williams @ 2010-02-02 15:04 UTC (permalink / raw)
To: Dudhat Dipen-B09055
Cc: herbert@gondor.apana.org.au, Ira W. Snyder, Suresh Vishnu-B05022,
Tabi Timur-B04825, linuxppc-dev@ozlabs.org, Gupta Maneesh-B18878,
Li Yang-R58472
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A6105CC5@zin33exm23.fsl.freescale.net>
Dudhat Dipen-B09055 wrote:
>
> Hi Ira,
>
> Do these patches accepted to open source kernel??
Yes, they should appear on the 'next' branch of async_tx.git by the end
of the day.
--
Dan
^ permalink raw reply
* [PATCH] eeh: Fixing a bug when pci structure is null
From: Breno Leitao @ 2010-02-02 17:46 UTC (permalink / raw)
To: benh, linuxppc-dev; +Cc: Linas Vepstas
In-Reply-To: <1264789719-15591-1-git-send-email-leitao@linux.vnet.ibm.com>
During a EEH recover, the pci_dev structure can be null, mainly if an
eeh event is detected during cpi config operation. In this case, the
pci_dev will not be known (and will be null) and the kernel will crash
with the following message:
Unable to handle kernel paging request for data at address 0x000000a0
Faulting instruction address: 0xc00000000006b8b4
Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c00000000006b8b4] .eeh_event_handler+0x10c/0x1a0
LR [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
Call Trace:
[c0000003a80dff00] [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
[c0000003a80dff90] [c000000000031f1c] .kernel_thread+0x54/0x70
The bug occurs because pci_name() tries to access a null pointer.
This patch just guarantee that pci_name() is not called on Null pointers.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
---
arch/powerpc/include/asm/ppc-pci.h | 7 +++++++
arch/powerpc/platforms/pseries/eeh.c | 4 ++--
arch/powerpc/platforms/pseries/eeh_driver.c | 4 ++--
arch/powerpc/platforms/pseries/eeh_event.c | 2 +-
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 2828f9d..724dbe2 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -137,6 +137,13 @@ struct device_node * find_device_pe(struct device_node *dn);
void eeh_sysfs_add_device(struct pci_dev *pdev);
void eeh_sysfs_remove_device(struct pci_dev *pdev);
+static inline const char *eeh_pci_name(struct pci_dev *pdev)
+{
+ if (NULL==pdev)
+ return "<null>";
+ return pci_name(pdev);
+}
+
#endif /* CONFIG_EEH */
#else /* CONFIG_PCI */
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index ccd8dd0..f9360fe 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -491,7 +491,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
pdn->eeh_mode & EEH_MODE_NOCHECK) {
ignored_check++;
pr_debug("EEH: Ignored check (%x) for %s %s\n",
- pdn->eeh_mode, pci_name (dev), dn->full_name);
+ pdn->eeh_mode, eeh_pci_name (dev), dn->full_name);
return 0;
}
@@ -515,7 +515,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
printk (KERN_ERR "EEH: %d reads ignored for recovering device at "
"location=%s driver=%s pci addr=%s\n",
pdn->eeh_check_count, location,
- dev->driver->name, pci_name(dev));
+ dev->driver->name, eeh_pci_name(dev));
printk (KERN_ERR "EEH: Might be infinite loop in %s driver\n",
dev->driver->name);
dump_stack();
diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c
index ef8e454..8f948a0 100644
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -337,7 +337,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
location = location ? location : "unknown";
printk(KERN_ERR "EEH: Error: Cannot find partition endpoint "
"for location=%s pci addr=%s\n",
- location, pci_name(event->dev));
+ location, eeh_pci_name(event->dev));
return NULL;
}
@@ -368,7 +368,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
pci_str = pci_name (frozen_pdn->pcidev);
drv_str = pcid_name (frozen_pdn->pcidev);
} else {
- pci_str = pci_name (event->dev);
+ pci_str = eeh_pci_name (event->dev);
drv_str = pcid_name (event->dev);
}
diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
index ddb80f5..ec5df8f 100644
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@ -80,7 +80,7 @@ static int eeh_event_handler(void * dummy)
eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
- pci_name(event->dev));
+ eeh_pci_name(event->dev));
pdn = handle_eeh_events(event);
^ permalink raw reply
* Re: [PATCH] eeh: Fixing a bug when pci structure is null
From: Wolfram Sang @ 2010-02-02 18:05 UTC (permalink / raw)
To: Breno Leitao; +Cc: Linas Vepstas, linuxppc-dev
In-Reply-To: <4B6864F4.1030106@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5051 bytes --]
On Tue, Feb 02, 2010 at 03:46:28PM -0200, Breno Leitao wrote:
> During a EEH recover, the pci_dev structure can be null, mainly if an
> eeh event is detected during cpi config operation. In this case, the
> pci_dev will not be known (and will be null) and the kernel will crash
> with the following message:
>
> Unable to handle kernel paging request for data at address 0x000000a0
> Faulting instruction address: 0xc00000000006b8b4
> Oops: Kernel access of bad area, sig: 11 [#1]
>
> NIP [c00000000006b8b4] .eeh_event_handler+0x10c/0x1a0
> LR [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
> Call Trace:
> [c0000003a80dff00] [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
> [c0000003a80dff90] [c000000000031f1c] .kernel_thread+0x54/0x70
>
> The bug occurs because pci_name() tries to access a null pointer.
> This patch just guarantee that pci_name() is not called on Null pointers.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
> Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
> ---
> arch/powerpc/include/asm/ppc-pci.h | 7 +++++++
> arch/powerpc/platforms/pseries/eeh.c | 4 ++--
> arch/powerpc/platforms/pseries/eeh_driver.c | 4 ++--
> arch/powerpc/platforms/pseries/eeh_event.c | 2 +-
> 4 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
> index 2828f9d..724dbe2 100644
> --- a/arch/powerpc/include/asm/ppc-pci.h
> +++ b/arch/powerpc/include/asm/ppc-pci.h
> @@ -137,6 +137,13 @@ struct device_node * find_device_pe(struct device_node *dn);
> void eeh_sysfs_add_device(struct pci_dev *pdev);
> void eeh_sysfs_remove_device(struct pci_dev *pdev);
>
> +static inline const char *eeh_pci_name(struct pci_dev *pdev)
> +{
> + if (NULL==pdev)
> + return "<null>";
> + return pci_name(pdev);
What about:
return pdev ? pci_name(pdev) : "<null>";
> +}
> +
> #endif /* CONFIG_EEH */
>
> #else /* CONFIG_PCI */
> diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
> index ccd8dd0..f9360fe 100644
> --- a/arch/powerpc/platforms/pseries/eeh.c
> +++ b/arch/powerpc/platforms/pseries/eeh.c
> @@ -491,7 +491,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
> pdn->eeh_mode & EEH_MODE_NOCHECK) {
> ignored_check++;
> pr_debug("EEH: Ignored check (%x) for %s %s\n",
> - pdn->eeh_mode, pci_name (dev), dn->full_name);
> + pdn->eeh_mode, eeh_pci_name (dev), dn->full_name);
No space after function name, please.
> return 0;
> }
>
> @@ -515,7 +515,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
> printk (KERN_ERR "EEH: %d reads ignored for recovering device at "
> "location=%s driver=%s pci addr=%s\n",
> pdn->eeh_check_count, location,
> - dev->driver->name, pci_name(dev));
> + dev->driver->name, eeh_pci_name(dev));
ditto
> printk (KERN_ERR "EEH: Might be infinite loop in %s driver\n",
> dev->driver->name);
> dump_stack();
> diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c
> index ef8e454..8f948a0 100644
> --- a/arch/powerpc/platforms/pseries/eeh_driver.c
> +++ b/arch/powerpc/platforms/pseries/eeh_driver.c
> @@ -337,7 +337,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
> location = location ? location : "unknown";
> printk(KERN_ERR "EEH: Error: Cannot find partition endpoint "
> "for location=%s pci addr=%s\n",
> - location, pci_name(event->dev));
> + location, eeh_pci_name(event->dev));
> return NULL;
> }
>
> @@ -368,7 +368,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
> pci_str = pci_name (frozen_pdn->pcidev);
> drv_str = pcid_name (frozen_pdn->pcidev);
> } else {
> - pci_str = pci_name (event->dev);
> + pci_str = eeh_pci_name (event->dev);
ditto
> drv_str = pcid_name (event->dev);
> }
>
> diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
> index ddb80f5..ec5df8f 100644
> --- a/arch/powerpc/platforms/pseries/eeh_event.c
> +++ b/arch/powerpc/platforms/pseries/eeh_event.c
> @@ -80,7 +80,7 @@ static int eeh_event_handler(void * dummy)
> eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
>
> printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
> - pci_name(event->dev));
> + eeh_pci_name(event->dev));
>
> pdn = handle_eeh_events(event);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCHv2 2/2] Update ibm,client-architecture call field based on device tree
From: Joel Schopp @ 2010-02-02 18:37 UTC (permalink / raw)
To: Joel Schopp, linuxppc-dev
In-Reply-To: <20100202034832.GD12389@ozlabs.org>
>> + if(*cores != NR_CPUS)
>> + prom_printf("client-architecture structure corrupted\n");
>> + *cores = (NR_CPUS / prom_smt_way());
>> + prom_printf("setting client-architecture cores to %x\n", *cores);
>>
>
> I don't know if I'm painting a bike shed of if this is a real concern, but if
> *cores isn't NR_CPUS shouldn't we do nothing rather then clobbering it?
>
> Yours Tony
>
If it isn't NR_CPUS we're pretty broken if we set it or if we don't. My
previous version did a BUILD_BUG_ON() but Ben didn't like that and said
he preferred just a warning message.
^ permalink raw reply
* Re: [PATCH] serial/mpc52xx_uart: Drop outdated comments
From: Wolfram Sang @ 2010-02-02 18:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-serial
In-Reply-To: <1262985569-29826-1-git-send-email-w.sang@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]
On Fri, Jan 08, 2010 at 10:19:29PM +0100, Wolfram Sang wrote:
> Most things mentioned are either obsolete (platform-support) or wrong (device
> numbering, DCD spport) these days. The remaining rest is obvious.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Ping. Anyone interested in this patch?
> ---
> drivers/serial/mpc52xx_uart.c | 33 ---------------------------------
> 1 files changed, 0 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index 7ce9e9f..c7ec1a2 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -29,39 +29,6 @@
> * kind, whether express or implied.
> */
>
> -/* Platform device Usage :
> - *
> - * Since PSCs can have multiple function, the correct driver for each one
> - * is selected by calling mpc52xx_match_psc_function(...). The function
> - * handled by this driver is "uart".
> - *
> - * The driver init all necessary registers to place the PSC in uart mode without
> - * DCD. However, the pin multiplexing aren't changed and should be set either
> - * by the bootloader or in the platform init code.
> - *
> - * The idx field must be equal to the PSC index (e.g. 0 for PSC1, 1 for PSC2,
> - * and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and
> - * so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly
> - * fpr the console code : without this 1:1 mapping, at early boot time, when we
> - * are parsing the kernel args console=ttyPSC?, we wouldn't know which PSC it
> - * will be mapped to.
> - */
> -
> -/* OF Platform device Usage :
> - *
> - * This driver is only used for PSCs configured in uart mode. The device
> - * tree will have a node for each PSC with "mpc52xx-psc-uart" in the compatible
> - * list.
> - *
> - * By default, PSC devices are enumerated in the order they are found. However
> - * a particular PSC number can be forces by adding 'device_no = <port#>'
> - * to the device node.
> - *
> - * The driver init all necessary registers to place the PSC in uart mode without
> - * DCD. However, the pin multiplexing aren't changed and should be set either
> - * by the bootloader or in the platform init code.
> - */
> -
> #undef DEBUG
>
> #include <linux/device.h>
> --
> 1.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] serial/mpc52xx_uart: Drop outdated comments
From: Grant Likely @ 2010-02-02 19:06 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <20100202185812.GM4757@pengutronix.de>
On Tue, Feb 2, 2010 at 11:58 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Fri, Jan 08, 2010 at 10:19:29PM +0100, Wolfram Sang wrote:
>> Most things mentioned are either obsolete (platform-support) or wrong (device
>> numbering, DCD spport) these days. The remaining rest is obvious.
>>
>> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>
> Ping. Anyone interested in this patch?
I haven't forgotten, I just haven't gotten around to looking at it.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 8/8] fsldma: major cleanups and fixes
From: Dan Williams @ 2010-02-02 21:02 UTC (permalink / raw)
To: Ira W. Snyder
Cc: R58472@freescale.com, B04825@freescale.com,
linuxppc-dev@ozlabs.org, scottwood@freescale.com,
Dipen.Dudhat@freescale.com, Maneesh.Gupta@freescale.com,
herbert@gondor.apana.org.au
In-Reply-To: <1262820846-13198-9-git-send-email-iws@ovro.caltech.edu>
Ira W. Snyder wrote:
> Fix locking. Use two queues in the driver, one for pending transacions, and
> one for transactions which are actually running on the hardware. Call
> dma_run_dependencies() on descriptor cleanup so that the async_tx API works
> correctly.
I notice that fsldma diverges from other dma drivers in that the
callback is performed with interrupts disabled. MD/raid5 currently
assumes that interrupts are enabled in its callback routines (see
ops_complete_biofill()'s use of spin_lock_irq()). On top of these
changes can we align fsldma to the other raid offload drivers (mv_xor,
iop-adma, ioatdma) and provide callbacks with irq's enabled?
I'll proceed with applying these patches as they obviously improve
things, but you will hit the irq problem when performing reads to a
degraded array.
--
Dan
^ permalink raw reply
* Re: [PATCH 8/8] fsldma: major cleanups and fixes
From: Ira W. Snyder @ 2010-02-02 21:16 UTC (permalink / raw)
To: Dan Williams
Cc: R58472@freescale.com, B04825@freescale.com,
linuxppc-dev@ozlabs.org, scottwood@freescale.com,
Dipen.Dudhat@freescale.com, Maneesh.Gupta@freescale.com,
herbert@gondor.apana.org.au
In-Reply-To: <4B6892F4.9070906@intel.com>
On Tue, Feb 02, 2010 at 02:02:44PM -0700, Dan Williams wrote:
> Ira W. Snyder wrote:
> > Fix locking. Use two queues in the driver, one for pending transacions, and
> > one for transactions which are actually running on the hardware. Call
> > dma_run_dependencies() on descriptor cleanup so that the async_tx API works
> > correctly.
>
> I notice that fsldma diverges from other dma drivers in that the
> callback is performed with interrupts disabled. MD/raid5 currently
> assumes that interrupts are enabled in its callback routines (see
> ops_complete_biofill()'s use of spin_lock_irq()). On top of these
> changes can we align fsldma to the other raid offload drivers (mv_xor,
> iop-adma, ioatdma) and provide callbacks with irq's enabled?
>
> I'll proceed with applying these patches as they obviously improve
> things, but you will hit the irq problem when performing reads to a
> degraded array.
>
In the fsldma driver, all callbacks are run from tasklet (softirq)
context. That's under local_irq_disable(), right? Hardirq's certainly
aren't disabled there.
Is a DMAEngine user expected to call the device_is_tx_complete()
function until it returns that the DMA has completed?
If so, it is pretty easy to switch to a workqueue instead of a tasklet
to handle the callbacks. The cost is increased latency until the
callbacks are processed.
Would you want a driver-wide singlethreaded workqueue? A driver-wide
multi-threaded workqueue? A workqueue per-device? A workqueue
per-channel? This starts to get excessive, IMO.
Ira
^ permalink raw reply
* Re: [PATCH 8/8] fsldma: major cleanups and fixes
From: Dan Williams @ 2010-02-02 21:23 UTC (permalink / raw)
To: Ira W. Snyder
Cc: R58472@freescale.com, B04825@freescale.com,
linuxppc-dev@ozlabs.org, scottwood@freescale.com,
Dipen.Dudhat@freescale.com, Maneesh.Gupta@freescale.com,
herbert@gondor.apana.org.au
In-Reply-To: <20100202211656.GA2609@ovro.caltech.edu>
Ira W. Snyder wrote:
> In the fsldma driver, all callbacks are run from tasklet (softirq)
> context. That's under local_irq_disable(), right? Hardirq's certainly
> aren't disabled there.
Actually, my mistake, the cleanup routine does spin_lock_irqsave(), but
I now see that it drops the lock across the callback:
/* Run the link descriptor callback function */
if (callback) {
spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
dev_dbg(fsl_chan->dev, "link descriptor %p callback\n", desc);
callback(callback_param);
spin_lock_irqsave(&fsl_chan->desc_lock, flags);
}
...so I retract my comment about surprising the raid5 code.
--
Dan
^ permalink raw reply
* Re: [PATCH 8/8] fsldma: major cleanups and fixes
From: Ira W. Snyder @ 2010-02-02 21:36 UTC (permalink / raw)
To: Dan Williams
Cc: R58472@freescale.com, B04825@freescale.com,
linuxppc-dev@ozlabs.org, scottwood@freescale.com,
Dipen.Dudhat@freescale.com, Maneesh.Gupta@freescale.com,
herbert@gondor.apana.org.au
In-Reply-To: <4B6897BC.60203@intel.com>
On Tue, Feb 02, 2010 at 02:23:08PM -0700, Dan Williams wrote:
> Ira W. Snyder wrote:
> > In the fsldma driver, all callbacks are run from tasklet (softirq)
> > context. That's under local_irq_disable(), right? Hardirq's certainly
> > aren't disabled there.
>
> Actually, my mistake, the cleanup routine does spin_lock_irqsave(), but
> I now see that it drops the lock across the callback:
>
> /* Run the link descriptor callback function */
> if (callback) {
> spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
> dev_dbg(fsl_chan->dev, "link descriptor %p callback\n", desc);
> callback(callback_param);
> spin_lock_irqsave(&fsl_chan->desc_lock, flags);
> }
>
> ...so I retract my comment about surprising the raid5 code.
I'm glad to hear that :)
Thanks for picking up the patches.
Ira
^ permalink raw reply
* [patch 1/2] powerpc: Sky CPU: redundant or incorrect tests on unsigned
From: akpm @ 2010-02-02 22:40 UTC (permalink / raw)
To: benh; +Cc: waite, roel.kluin, gorcunov, linuxppc-dev, galak, akpm
From: Roel Kluin <roel.kluin@gmail.com>
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Brian Waite <waite@skycomputers.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/misc/hdpuftrs/hdpu_cpustate.c | 5 -----
1 file changed, 5 deletions(-)
diff -puN drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned drivers/misc/hdpuftrs/hdpu_cpustate.c
--- a/drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
+++ a/drivers/misc/hdpuftrs/hdpu_cpustate.c
@@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
if (count == 0)
return 0;
@@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct fil
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
-
if (count == 0)
return 0;
_
^ permalink raw reply
* [patch 2/2] kbuild: move -fno-dwarf2-cfi-asm to powerpc only
From: akpm @ 2010-02-02 22:40 UTC (permalink / raw)
To: benh; +Cc: mmarek, ak, kyle, linuxppc-dev, andi, akpm
From: Andi Kleen <andi@firstfloor.org>
Better dwarf2 unwind information is a good thing, it allows better
debugging with kgdb and crash and helps systemtap.
Commit 003086497f07f7f1e67c0c295e261740f822b377 ("Build with
-fno-dwarf2-cfi-asm") disabled some CFI information globally to work
around a module loader bug on powerpc.
But this disables the better unwind tables for all architectures, not just
powerpc. Move the workaround to powerpc and also add a suitable comment
that's it really a workaround.
This improves dwarf2 unwind tables on x86 at least.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Makefile | 3 ---
arch/powerpc/Makefile | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff -puN Makefile~kbuild-move-fno-dwarf2-cfi-asm-to-powerpc-only Makefile
--- a/Makefile~kbuild-move-fno-dwarf2-cfi-asm-to-powerpc-only
+++ a/Makefile
@@ -579,9 +579,6 @@ KBUILD_CFLAGS += $(call cc-option,-Wno-p
# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
-# revert to pre-gcc-4.4 behaviour of .eh_frame
-KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
-
# conserve stack if available
KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
diff -puN arch/powerpc/Makefile~kbuild-move-fno-dwarf2-cfi-asm-to-powerpc-only arch/powerpc/Makefile
--- a/arch/powerpc/Makefile~kbuild-move-fno-dwarf2-cfi-asm-to-powerpc-only
+++ a/arch/powerpc/Makefile
@@ -112,6 +112,11 @@ KBUILD_CFLAGS += $(call cc-option,-mspe=
# kernel considerably.
KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
+# FIXME: the module load should be taught about the additional relocs
+# generated by this.
+# revert to pre-gcc-4.4 behaviour of .eh_frame
+KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
+
# Never use string load/store instructions as they are
# often slow when they are implemented at all
KBUILD_CFLAGS += -mno-string
_
^ permalink raw reply
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: Dave Kleikamp @ 2010-02-03 2:03 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Sergio Durigan Junior, Torez Smith,
Thiago Jung Bauermann, David Gibson
In-Reply-To: <1263854072.27291.47.camel@norville.austin.ibm.com>
On Mon, 2010-01-18 at 16:34 -0600, Dave Kleikamp wrote:
> On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> > Is GDB smart enough to deal w/no condition_regs? On some Book-E
> > devices we have 2 IACs, 2 DACs, and 0 DVCs. Does it need to be in the
> > features?
>
> I wasn't aware that the bookE devices had varying numbers of these
> registers. I guess I will have to make it a runtime option.
Kumar,
Can you tell me which bookE processors have 2 IAC's, and which have no
DVC's?
I think we still may be able to make these compile-time options as long
no two cpus that run on the same binary kernel vary in the number of
registers. Right now I know the 403 only has 2 IAC's, and I don't
intend to expose the DVC's for the 40x processors anyway.
If they don't need to be run-time configurable, I think it would be
cleaner to define the number of each type of register in CONFIG_ flags
and put the logic into the Kconfig files.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2010-02-03 6:16 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <1264191106.2224.0-2010-02-02-19-31-49@antares>
Hello Albrecht,
Sorry for the delay ... your mail got stuck in a Notes "spam filter".
On Friday 22 January 2010 21:11:39 Albrecht Dre=DF wrote:
> Are there any "final" conclusions from your tests?
Yes.
=46or the small product using the 2.6 kernel we turned all snooping and
the kernel coherent flag off, which avoided crashes of the FEC and/or
hard disk since we introduced that change.
We are currently investigating problems that we are seeing on the
2.4.25 (DENX and Lite5200B based) boards for a long time. Here we are
having problems with corrupt filesystems and FEC hick ups. In this
case we are using UDMA2, because we cannot yet get MWDMA2 work on
2.4.25, well knowing that there might be a problem with UDMA2 and LPC.
So we also turned of snooping and are currently in the testing phase
(again).
> ... two compactflash cards with vfat file systems attached to the
> ata bus; - a nfs3 network drive, connected via a 100MBit line, on a
> Xeon serve
Are you using MWDMA2 with the compact flash cards? What is the load on
the different (DMA) channels? ATA reads or writes?
> ... a signal processor attached to the localbus, using bestcomm and
> the fifo for the bulk transfer
Are you using an own driver, or are you using Grant's SCLPC+SDMA
driver? BD task?
Our latest product uses an SMSC MOST150 Spynic and an FPGA to sample
data from a MOST ring via SCLPC+SDMA (single non BD task from the old
=46reescale Betstcomm API) on the 2.4.25. Here moving from memory
accesses to SCLPC+SDMA helped somewhat, probably by avoiding the
UDMA2/LPC problem by mainly letting the SDMA scheduler do the
scheduling of the LPC traffic, which avoids the LPC arbiter problem
"somehow".
The probability for seeing problems or crashes increases a lot with
the bandwidth. I think, and I might be wrong, esp. when an arbiter or
scheduler (LPC/PCI or SDMA) needs to switch users or tasks. In our
case we have data running with about 3-6 MB/s (avg.) via the LPC to
the hard disks or somewhat more using FTP from the hard disk to the
=46EC.
> I did not observe any issues
The filesystem crashes are seldom, but happen often enough to be able
to reproduce them once every 1 or 2 days under heavy load, and to
produce failures in the field, what's even worse. And they
statistically increased a lot wen we ran out of GPIO on the MPC5200B
and then used an CPLD or FPGA to replace them, just a few bits to MUX
SPI lines, but that was enough.
> but your statements are making me really nervous...
That was not my intention. The best thing is to run very ugly tests
with very high load for at least 24h. Due to the fact that we see
those problems on different boards we (the SW guys) no longer can
assume self made HW problems (HW guys), esp. when reading Freescale's
advice with the XLB config.
It might happen that we switch to 2.6 on our older products, hoping
that at least the LPC/IDE problem disappears by using MWDMA2 instead
of UDMA2.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* [PATCH] powerpc: Add coherent_dma_mask to mv64x60 devices
From: Corey Minyard @ 2010-02-03 15:08 UTC (permalink / raw)
To: linuxppc-dev
From: Corey Minyard <cminyard@mvista.com>
DMA ops requires that coherent_dma_mask be set properly for a device,
but this was not being done for devices on the MV64x60 that use DMA.
Both the serial and ethernet devices need this or they won't be able
to allocate memory.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
---
Mark Greer pointed me to the right place, I believe this is the
correct way to handle the problem.
Index: linux-2.6/arch/powerpc/sysdev/mv64x60_dev.c
===================================================================
--- linux-2.6.orig/arch/powerpc/sysdev/mv64x60_dev.c
+++ linux-2.6/arch/powerpc/sysdev/mv64x60_dev.c
@@ -16,6 +16,7 @@
#include <linux/mv643xx.h>
#include <linux/platform_device.h>
#include <linux/of_platform.h>
+#include <linux/dma-mapping.h>
#include <asm/prom.h>
@@ -189,6 +190,7 @@ static int __init mv64x60_mpsc_device_se
pdev = platform_device_alloc(MPSC_CTLR_NAME, port_number);
if (!pdev)
return -ENOMEM;
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
err = platform_device_add_resources(pdev, r, 5);
if (err)
@@ -302,6 +304,7 @@ static int __init mv64x60_eth_device_set
if (!pdev)
return -ENOMEM;
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
err = platform_device_add_resources(pdev, r, 1);
if (err)
goto error;
^ permalink raw reply
* [PATCH] eeh: Fixing a bug when pci structure is null
From: Breno Leitao @ 2010-02-03 15:56 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Linas Vepstas, linuxppc-dev
In-Reply-To: <20100202180503.GL4757@pengutronix.de>
During a EEH recover, the pci_dev structure can be null, mainly if an
eeh event is detected during cpi config operation. In this case, the
pci_dev will not be known (and will be null) the kernel will crash
with the following message:
Unable to handle kernel paging request for data at address 0x000000a0
Faulting instruction address: 0xc00000000006b8b4
Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c00000000006b8b4] .eeh_event_handler+0x10c/0x1a0
LR [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
Call Trace:
[c0000003a80dff00] [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
[c0000003a80dff90] [c000000000031f1c] .kernel_thread+0x54/0x70
The bug occurs because pci_name() tries to access a null pointer.
This patch just guarantee that pci_name() is not called on Null pointers.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
---
arch/powerpc/include/asm/ppc-pci.h | 5 +++++
arch/powerpc/platforms/pseries/eeh.c | 4 ++--
arch/powerpc/platforms/pseries/eeh_driver.c | 4 ++--
arch/powerpc/platforms/pseries/eeh_event.c | 2 +-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 2828f9d..42fdff0 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -137,6 +137,11 @@ struct device_node * find_device_pe(struct device_node *dn);
void eeh_sysfs_add_device(struct pci_dev *pdev);
void eeh_sysfs_remove_device(struct pci_dev *pdev);
+static inline const char *eeh_pci_name(struct pci_dev *pdev)
+{
+ return pdev ? pci_name(pdev) : "<null>";
+}
+
#endif /* CONFIG_EEH */
#else /* CONFIG_PCI */
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index ccd8dd0..3304f32 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -491,7 +491,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
pdn->eeh_mode & EEH_MODE_NOCHECK) {
ignored_check++;
pr_debug("EEH: Ignored check (%x) for %s %s\n",
- pdn->eeh_mode, pci_name (dev), dn->full_name);
+ pdn->eeh_mode, eeh_pci_name(dev), dn->full_name);
return 0;
}
@@ -515,7 +515,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
printk (KERN_ERR "EEH: %d reads ignored for recovering device at "
"location=%s driver=%s pci addr=%s\n",
pdn->eeh_check_count, location,
- dev->driver->name, pci_name(dev));
+ dev->driver->name, eeh_pci_name(dev));
printk (KERN_ERR "EEH: Might be infinite loop in %s driver\n",
dev->driver->name);
dump_stack();
diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c
index ef8e454..977d87d 100644
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -337,7 +337,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
location = location ? location : "unknown";
printk(KERN_ERR "EEH: Error: Cannot find partition endpoint "
"for location=%s pci addr=%s\n",
- location, pci_name(event->dev));
+ location, eeh_pci_name(event->dev));
return NULL;
}
@@ -368,7 +368,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
pci_str = pci_name (frozen_pdn->pcidev);
drv_str = pcid_name (frozen_pdn->pcidev);
} else {
- pci_str = pci_name (event->dev);
+ pci_str = eeh_pci_name(event->dev);
drv_str = pcid_name (event->dev);
}
diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
index ddb80f5..ec5df8f 100644
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@ -80,7 +80,7 @@ static int eeh_event_handler(void * dummy)
eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
- pci_name(event->dev));
+ eeh_pci_name(event->dev));
pdn = handle_eeh_events(event);
--
1.6.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox