* Re: [PATCH 3/4] powerpc/mpic: parse 4-cell intspec types other than zero
From: Kumar Gala @ 2011-05-06 1:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20110324214354.GB9524@schlenkerla.am.freescale.net>
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/mpic.h | 2 ++
> arch/powerpc/sysdev/mpic.c | 37 =
++++++++++++++++++++++++++++++++++++-
> 2 files changed, 38 insertions(+), 1 deletions(-)
Ben,
Did you plan on review and pull this in or expect me to?
- k
>=20
> diff --git a/arch/powerpc/include/asm/mpic.h =
b/arch/powerpc/include/asm/mpic.h
> index 7005ee0..25a0cb3 100644
> --- a/arch/powerpc/include/asm/mpic.h
> +++ b/arch/powerpc/include/asm/mpic.h
> @@ -371,6 +371,8 @@ struct mpic
> * NOTE: This flag trumps MPIC_WANTS_RESET.
> */
> #define MPIC_NO_RESET 0x00004000
> +/* Freescale MPIC (compatible includes "fsl,mpic") */
> +#define MPIC_FSL 0x00008000
>=20
> /* MPIC HW modification ID */
> #define MPIC_REGSET_MASK 0xf0000000
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 0f7c671..69f96ec 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -6,6 +6,7 @@
> * with various broken implementations of this HW.
> *
> * Copyright (C) 2004 Benjamin Herrenschmidt, IBM Corp.
> + * Copyright 2010-2011 Freescale Semiconductor, Inc.
> *
> * This file is subject to the terms and conditions of the GNU =
General Public
> * License. See the file COPYING in the main directory of this =
archive
> @@ -1030,6 +1031,7 @@ static int mpic_host_xlate(struct irq_host *h, =
struct device_node *ct,
> irq_hw_number_t *out_hwirq, unsigned int =
*out_flags)
>=20
> {
> + struct mpic *mpic =3D h->host_data;
> static unsigned char map_mpic_senses[4] =3D {
> IRQ_TYPE_EDGE_RISING,
> IRQ_TYPE_LEVEL_LOW,
> @@ -1038,7 +1040,38 @@ static int mpic_host_xlate(struct irq_host *h, =
struct device_node *ct,
> };
>=20
> *out_hwirq =3D intspec[0];
> - if (intsize > 1) {
> + if (intsize >=3D 4 && (mpic->flags & MPIC_FSL)) {
> + /*
> + * Freescale MPIC with extended intspec:
> + * First two cells are as usual. Third specifies
> + * an "interrupt type". Fourth is type-specific data.
> + *
> + * See =
Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
> + */
> + switch (intspec[2]) {
> + case 0:
> + case 1: /* no EISR/EIMR support for now, treat as shared =
IRQ */
> + break;
> + case 2:
> + if (intspec[0] >=3D ARRAY_SIZE(mpic->ipi_vecs))
> + return -EINVAL;
> +
> + *out_hwirq =3D mpic->ipi_vecs[intspec[0]];
> + break;
> + case 3:
> + if (intspec[0] >=3D =
ARRAY_SIZE(mpic->timer_vecs))
> + return -EINVAL;
> +
> + *out_hwirq =3D mpic->timer_vecs[intspec[0]];
> + break;
> + default:
> + pr_debug("%s: unknown irq type %u\n",
> + __func__, intspec[2]);
> + return -EINVAL;
> + }
> +
> + *out_flags =3D map_mpic_senses[intspec[1] & 3];
> + } else if (intsize > 1) {
> u32 mask =3D 0x3;
>=20
> /* Apple invented a new race of encoding on machines =
with
> @@ -1137,6 +1170,8 @@ struct mpic * __init mpic_alloc(struct =
device_node *node,
> /* Check for "big-endian" in device-tree */
> if (node && of_get_property(node, "big-endian", NULL) !=3D NULL)
> mpic->flags |=3D MPIC_BIG_ENDIAN;
> + if (node && of_device_is_compatible(node, "fsl,mpic"))
> + mpic->flags |=3D MPIC_FSL;
>=20
> /* Look for protected sources */
> if (node) {
> --=20
> 1.7.1
>=20
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: add the mpic global timer support
From: Kumar Gala @ 2011-05-06 1:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20110324214355.GC9524@schlenkerla.am.freescale.net>
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Add support for MPIC timers as requestable interrupt sources.
>=20
> Based on http://patchwork.ozlabs.org/patch/20941/ by Dave Liu.
>=20
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/mpic.h | 3 +-
> arch/powerpc/sysdev/mpic.c | 92 =
++++++++++++++++++++++++++++++++++++---
> 2 files changed, 88 insertions(+), 7 deletions(-)
Ben,
Did you plan on review and pull this in or expect me to?
- k
>=20
> diff --git a/arch/powerpc/include/asm/mpic.h =
b/arch/powerpc/include/asm/mpic.h
> index 25a0cb3..664bee6 100644
> --- a/arch/powerpc/include/asm/mpic.h
> +++ b/arch/powerpc/include/asm/mpic.h
> @@ -263,6 +263,7 @@ struct mpic
> #ifdef CONFIG_SMP
> struct irq_chip hc_ipi;
> #endif
> + struct irq_chip hc_tm;
> const char *name;
> /* Flags */
> unsigned int flags;
> @@ -281,7 +282,7 @@ struct mpic
>=20
> /* vector numbers used for internal sources (ipi/timers) */
> unsigned int ipi_vecs[4];
> - unsigned int timer_vecs[4];
> + unsigned int timer_vecs[8];
>=20
> /* Spurious vector to program into unused sources */
> unsigned int spurious_vec;
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 69f96ec..c173e67 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -219,6 +219,28 @@ static inline void _mpic_ipi_write(struct mpic =
*mpic, unsigned int ipi, u32 valu
> _mpic_write(mpic->reg_type, &mpic->gregs, offset, value);
> }
>=20
> +static inline u32 _mpic_tm_read(struct mpic *mpic, unsigned int tm)
> +{
> + unsigned int offset =3D MPIC_INFO(TIMER_VECTOR_PRI) +
> + ((tm & 3) * MPIC_INFO(TIMER_STRIDE));
> +
> + if (tm >=3D 4)
> + offset +=3D 0x1000 / 4;
> +
> + return _mpic_read(mpic->reg_type, &mpic->tmregs, offset);
> +}
> +
> +static inline void _mpic_tm_write(struct mpic *mpic, unsigned int tm, =
u32 value)
> +{
> + unsigned int offset =3D MPIC_INFO(TIMER_VECTOR_PRI) +
> + ((tm & 3) * MPIC_INFO(TIMER_STRIDE));
> +
> + if (tm >=3D 4)
> + offset +=3D 0x1000 / 4;
> +
> + _mpic_write(mpic->reg_type, &mpic->tmregs, offset, value);
> +}
> +
> static inline u32 _mpic_cpu_read(struct mpic *mpic, unsigned int reg)
> {
> unsigned int cpu =3D mpic_processor_id(mpic);
> @@ -269,6 +291,8 @@ static inline void _mpic_irq_write(struct mpic =
*mpic, unsigned int src_no,
> #define mpic_write(b,r,v) _mpic_write(mpic->reg_type,&(b),(r),(v))
> #define mpic_ipi_read(i) _mpic_ipi_read(mpic,(i))
> #define mpic_ipi_write(i,v) _mpic_ipi_write(mpic,(i),(v))
> +#define mpic_tm_read(i) _mpic_tm_read(mpic,(i))
> +#define mpic_tm_write(i,v) _mpic_tm_write(mpic,(i),(v))
> #define mpic_cpu_read(i) _mpic_cpu_read(mpic,(i))
> #define mpic_cpu_write(i,v) _mpic_cpu_write(mpic,(i),(v))
> #define mpic_irq_read(s,r) _mpic_irq_read(mpic,(s),(r))
> @@ -628,6 +652,13 @@ static unsigned int mpic_is_ipi(struct mpic =
*mpic, unsigned int irq)
> return (src >=3D mpic->ipi_vecs[0] && src <=3D =
mpic->ipi_vecs[3]);
> }
>=20
> +/* Determine if the linux irq is a timer */
> +static unsigned int mpic_is_tm(struct mpic *mpic, unsigned int irq)
> +{
> + unsigned int src =3D mpic_irq_to_hw(irq);
> +
> + return (src >=3D mpic->timer_vecs[0] && src <=3D =
mpic->timer_vecs[7]);
> +}
>=20
> /* Convert a cpu mask from logical to physical cpu numbers. */
> static inline u32 mpic_physmask(u32 cpumask)
> @@ -814,6 +845,25 @@ static void mpic_end_ipi(struct irq_data *d)
>=20
> #endif /* CONFIG_SMP */
>=20
> +static void mpic_unmask_tm(struct irq_data *d)
> +{
> + struct mpic *mpic =3D mpic_from_irq_data(d);
> + unsigned int src =3D mpic_irq_to_hw(d->irq) - =
mpic->timer_vecs[0];
> +
> + DBG("%s: enable_tm: %d (tm %d)\n", mpic->name, irq, src);
> + mpic_tm_write(src, mpic_tm_read(src) & ~MPIC_VECPRI_MASK);
> + mpic_tm_read(src);
> +}
> +
> +static void mpic_mask_tm(struct irq_data *d)
> +{
> + struct mpic *mpic =3D mpic_from_irq_data(d);
> + unsigned int src =3D mpic_irq_to_hw(d->irq) - =
mpic->timer_vecs[0];
> +
> + mpic_tm_write(src, mpic_tm_read(src) | MPIC_VECPRI_MASK);
> + mpic_tm_read(src);
> +}
> +
> int mpic_set_affinity(struct irq_data *d, const struct cpumask =
*cpumask,
> bool force)
> {
> @@ -948,6 +998,12 @@ static struct irq_chip mpic_ipi_chip =3D {
> };
> #endif /* CONFIG_SMP */
>=20
> +static struct irq_chip mpic_tm_chip =3D {
> + .irq_mask =3D mpic_mask_tm,
> + .irq_unmask =3D mpic_unmask_tm,
> + .irq_eoi =3D mpic_end_irq,
> +};
> +
> #ifdef CONFIG_MPIC_U3_HT_IRQS
> static struct irq_chip mpic_irq_ht_chip =3D {
> .irq_startup =3D mpic_startup_ht_irq,
> @@ -991,6 +1047,16 @@ static int mpic_host_map(struct irq_host *h, =
unsigned int virq,
> }
> #endif /* CONFIG_SMP */
>=20
> + if (hw >=3D mpic->timer_vecs[0] && hw <=3D mpic->timer_vecs[7]) =
{
> + WARN_ON(!(mpic->flags & MPIC_PRIMARY));
> +
> + DBG("mpic: mapping as timer\n");
> + set_irq_chip_data(virq, mpic);
> + set_irq_chip_and_handler(virq, &mpic->hc_tm,
> + handle_fasteoi_irq);
> + return 0;
> + }
> +
> if (hw >=3D mpic->irq_count)
> return -EINVAL;
>=20
> @@ -1147,6 +1213,9 @@ struct mpic * __init mpic_alloc(struct =
device_node *node,
> mpic->hc_ipi.name =3D name;
> #endif /* CONFIG_SMP */
>=20
> + mpic->hc_tm =3D mpic_tm_chip;
> + mpic->hc_tm.name =3D name;
> +
> mpic->flags =3D flags;
> mpic->isu_size =3D isu_size;
> mpic->irq_count =3D irq_count;
> @@ -1157,10 +1226,14 @@ struct mpic * __init mpic_alloc(struct =
device_node *node,
> else
> intvec_top =3D 255;
>=20
> - mpic->timer_vecs[0] =3D intvec_top - 8;
> - mpic->timer_vecs[1] =3D intvec_top - 7;
> - mpic->timer_vecs[2] =3D intvec_top - 6;
> - mpic->timer_vecs[3] =3D intvec_top - 5;
> + mpic->timer_vecs[0] =3D intvec_top - 12;
> + mpic->timer_vecs[1] =3D intvec_top - 11;
> + mpic->timer_vecs[2] =3D intvec_top - 10;
> + mpic->timer_vecs[3] =3D intvec_top - 9;
> + mpic->timer_vecs[4] =3D intvec_top - 8;
> + mpic->timer_vecs[5] =3D intvec_top - 7;
> + mpic->timer_vecs[6] =3D intvec_top - 6;
> + mpic->timer_vecs[7] =3D intvec_top - 5;
> mpic->ipi_vecs[0] =3D intvec_top - 4;
> mpic->ipi_vecs[1] =3D intvec_top - 3;
> mpic->ipi_vecs[2] =3D intvec_top - 2;
> @@ -1363,15 +1436,17 @@ void __init mpic_init(struct mpic *mpic)
> /* Set current processor priority to max */
> mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
>=20
> - /* Initialize timers: just disable them all */
> + /* Initialize timers to our reserved vectors and mask them for =
now */
> for (i =3D 0; i < 4; i++) {
> mpic_write(mpic->tmregs,
> i * MPIC_INFO(TIMER_STRIDE) +
> - MPIC_INFO(TIMER_DESTINATION), 0);
> + MPIC_INFO(TIMER_DESTINATION),
> + 1 << hard_smp_processor_id());
> mpic_write(mpic->tmregs,
> i * MPIC_INFO(TIMER_STRIDE) +
> MPIC_INFO(TIMER_VECTOR_PRI),
> MPIC_VECPRI_MASK |
> + (9 << MPIC_VECPRI_PRIORITY_SHIFT) |
> (mpic->timer_vecs[0] + i));
> }
>=20
> @@ -1480,6 +1555,11 @@ void mpic_irq_set_priority(unsigned int irq, =
unsigned int pri)
> ~MPIC_VECPRI_PRIORITY_MASK;
> mpic_ipi_write(src - mpic->ipi_vecs[0],
> reg | (pri << =
MPIC_VECPRI_PRIORITY_SHIFT));
> + } else if (mpic_is_tm(mpic, irq)) {
> + reg =3D mpic_tm_read(src - mpic->timer_vecs[0]) &
> + ~MPIC_VECPRI_PRIORITY_MASK;
> + mpic_tm_write(src - mpic->timer_vecs[0],
> + reg | (pri << =
MPIC_VECPRI_PRIORITY_SHIFT));
> } else {
> reg =3D mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI))
> & ~MPIC_VECPRI_PRIORITY_MASK;
> --=20
> 1.7.1
^ permalink raw reply
* Re: [PATCH v2 3/7] mmc: sdhci: make sdhci-of device drivers self registered
From: Shawn Guo @ 2011-05-06 2:15 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Chris Ball, sameo, Arnd Bergmann, patches, devicetree-discuss,
linux-mmc, Saeed Bishara, Xiaobo Xie, kernel, Mike Rapoport,
Olof Johansson, Shawn Guo, linuxppc-dev, Albert Herranz,
linux-arm-kernel
In-Reply-To: <20110505142344.GA13400@oksana.dev.rtsoft.ru>
On Thu, May 05, 2011 at 06:23:44PM +0400, Anton Vorontsov wrote:
> On Thu, May 05, 2011 at 09:22:54PM +0800, Shawn Guo wrote:
> [...]
> > - * Copyright (c) 2007 Freescale Semiconductor, Inc.
> > - * Copyright (c) 2009 MontaVista Software, Inc.
> > - *
> > - * Authors: Xiaobo Xie <X.Xie@freescale.com>
> > - * Anton Vorontsov <avorontsov@ru.mvista.com>
> [...]
> > -#ifdef CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
> > -
> > -/*
> > - * These accessors are designed for big endian hosts doing I/O to
> > - * little endian controllers incorporating a 32-bit hardware byte swapper.
> > - */
> > -
> > -u32 sdhci_be32bs_readl(struct sdhci_host *host, int reg)
> > -{
> > - return in_be32(host->ioaddr + reg);
> > -}
> > -
> > -u16 sdhci_be32bs_readw(struct sdhci_host *host, int reg)
> > -{
> > - return in_be16(host->ioaddr + (reg ^ 0x2));
> > -}
> > -
> > -u8 sdhci_be32bs_readb(struct sdhci_host *host, int reg)
> > -{
> > - return in_8(host->ioaddr + (reg ^ 0x3));
> > -}
> > -
> > -void sdhci_be32bs_writel(struct sdhci_host *host, u32 val, int reg)
> > -{
> > - out_be32(host->ioaddr + reg, val);
> > -}
> > -
> > -void sdhci_be32bs_writew(struct sdhci_host *host, u16 val, int reg)
> > -{
> > - struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > - int base = reg & ~0x3;
> > - int shift = (reg & 0x2) * 8;
> > -
> > - switch (reg) {
> > - case SDHCI_TRANSFER_MODE:
> > - /*
> > - * Postpone this write, we must do it together with a
> > - * command write that is down below.
> > - */
> > - pltfm_host->xfer_mode_shadow = val;
> > - return;
> > - case SDHCI_COMMAND:
> > - sdhci_be32bs_writel(host, val << 16 | pltfm_host->xfer_mode_shadow,
> > - SDHCI_TRANSFER_MODE);
> > - return;
> > - }
> > - clrsetbits_be32(host->ioaddr + base, 0xffff << shift, val << shift);
> > -}
> > -
> > -void sdhci_be32bs_writeb(struct sdhci_host *host, u8 val, int reg)
> > -{
> > - int base = reg & ~0x3;
> > - int shift = (reg & 0x3) * 8;
> > -
> > - clrsetbits_be32(host->ioaddr + base , 0xff << shift, val << shift);
> > -}
> > -#endif /* CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER */
> [...]
> > +#ifdef CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
> > +/*
> > + * These accessors are designed for big endian hosts doing I/O to
> > + * little endian controllers incorporating a 32-bit hardware byte swapper.
> > + */
> > +u32 sdhci_be32bs_readl(struct sdhci_host *host, int reg)
> > +{
> > + return in_be32(host->ioaddr + reg);
> > +}
> > +
> > +u16 sdhci_be32bs_readw(struct sdhci_host *host, int reg)
> > +{
> > + return in_be16(host->ioaddr + (reg ^ 0x2));
> > +}
> > +
> > +u8 sdhci_be32bs_readb(struct sdhci_host *host, int reg)
> > +{
> > + return in_8(host->ioaddr + (reg ^ 0x3));
> > +}
> > +
> > +void sdhci_be32bs_writel(struct sdhci_host *host, u32 val, int reg)
> > +{
> > + out_be32(host->ioaddr + reg, val);
> > +}
> > +
> > +void sdhci_be32bs_writew(struct sdhci_host *host, u16 val, int reg)
> > +{
> > + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > + int base = reg & ~0x3;
> > + int shift = (reg & 0x2) * 8;
> > +
> > + switch (reg) {
> > + case SDHCI_TRANSFER_MODE:
> > + /*
> > + * Postpone this write, we must do it together with a
> > + * command write that is down below.
> > + */
> > + pltfm_host->xfer_mode_shadow = val;
> > + return;
> > + case SDHCI_COMMAND:
> > + sdhci_be32bs_writel(host, val << 16 | pltfm_host->xfer_mode_shadow,
> > + SDHCI_TRANSFER_MODE);
> > + return;
> > + }
> > + clrsetbits_be32(host->ioaddr + base, 0xffff << shift, val << shift);
> > +}
> > +
> > +void sdhci_be32bs_writeb(struct sdhci_host *host, u8 val, int reg)
> > +{
> > + int base = reg & ~0x3;
> > + int shift = (reg & 0x3) * 8;
> > +
> > + clrsetbits_be32(host->ioaddr + base , 0xff << shift, val << shift);
> > +}
> > +#endif /* CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER */
>
> I noticed you're very careful wrt copyright/authorship notices,
> except for this case. How about retaining copyright stuff when
> you merge these two files?
>
Obviously, need to be more careful. Will add. Thanks.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: add the mpic global timer support
From: Benjamin Herrenschmidt @ 2011-05-06 3:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F923130F-46AA-4E8E-89B0-27FC9EC020BD@kernel.crashing.org>
On Thu, 2011-05-05 at 20:07 -0500, Kumar Gala wrote:
> On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
>
> > Add support for MPIC timers as requestable interrupt sources.
> >
> > Based on http://patchwork.ozlabs.org/patch/20941/ by Dave Liu.
> >
> > Signed-off-by: Dave Liu <daveliu@freescale.com>
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
> > ---
> > arch/powerpc/include/asm/mpic.h | 3 +-
> > arch/powerpc/sysdev/mpic.c | 92 ++++++++++++++++++++++++++++++++++++---
> > 2 files changed, 88 insertions(+), 7 deletions(-)
>
> Ben,
>
> Did you plan on review and pull this in or expect me to?
I might have been waiting for you I think ... :-) Or I wasn't sure. Feel
free to pick them up (if you do so, tag them as such in patchwork).
Cheers,
Ben.
> - k
>
>
> >
> > diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
> > index 25a0cb3..664bee6 100644
> > --- a/arch/powerpc/include/asm/mpic.h
> > +++ b/arch/powerpc/include/asm/mpic.h
> > @@ -263,6 +263,7 @@ struct mpic
> > #ifdef CONFIG_SMP
> > struct irq_chip hc_ipi;
> > #endif
> > + struct irq_chip hc_tm;
> > const char *name;
> > /* Flags */
> > unsigned int flags;
> > @@ -281,7 +282,7 @@ struct mpic
> >
> > /* vector numbers used for internal sources (ipi/timers) */
> > unsigned int ipi_vecs[4];
> > - unsigned int timer_vecs[4];
> > + unsigned int timer_vecs[8];
> >
> > /* Spurious vector to program into unused sources */
> > unsigned int spurious_vec;
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 69f96ec..c173e67 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -219,6 +219,28 @@ static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int ipi, u32 valu
> > _mpic_write(mpic->reg_type, &mpic->gregs, offset, value);
> > }
> >
> > +static inline u32 _mpic_tm_read(struct mpic *mpic, unsigned int tm)
> > +{
> > + unsigned int offset = MPIC_INFO(TIMER_VECTOR_PRI) +
> > + ((tm & 3) * MPIC_INFO(TIMER_STRIDE));
> > +
> > + if (tm >= 4)
> > + offset += 0x1000 / 4;
> > +
> > + return _mpic_read(mpic->reg_type, &mpic->tmregs, offset);
> > +}
> > +
> > +static inline void _mpic_tm_write(struct mpic *mpic, unsigned int tm, u32 value)
> > +{
> > + unsigned int offset = MPIC_INFO(TIMER_VECTOR_PRI) +
> > + ((tm & 3) * MPIC_INFO(TIMER_STRIDE));
> > +
> > + if (tm >= 4)
> > + offset += 0x1000 / 4;
> > +
> > + _mpic_write(mpic->reg_type, &mpic->tmregs, offset, value);
> > +}
> > +
> > static inline u32 _mpic_cpu_read(struct mpic *mpic, unsigned int reg)
> > {
> > unsigned int cpu = mpic_processor_id(mpic);
> > @@ -269,6 +291,8 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
> > #define mpic_write(b,r,v) _mpic_write(mpic->reg_type,&(b),(r),(v))
> > #define mpic_ipi_read(i) _mpic_ipi_read(mpic,(i))
> > #define mpic_ipi_write(i,v) _mpic_ipi_write(mpic,(i),(v))
> > +#define mpic_tm_read(i) _mpic_tm_read(mpic,(i))
> > +#define mpic_tm_write(i,v) _mpic_tm_write(mpic,(i),(v))
> > #define mpic_cpu_read(i) _mpic_cpu_read(mpic,(i))
> > #define mpic_cpu_write(i,v) _mpic_cpu_write(mpic,(i),(v))
> > #define mpic_irq_read(s,r) _mpic_irq_read(mpic,(s),(r))
> > @@ -628,6 +652,13 @@ static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int irq)
> > return (src >= mpic->ipi_vecs[0] && src <= mpic->ipi_vecs[3]);
> > }
> >
> > +/* Determine if the linux irq is a timer */
> > +static unsigned int mpic_is_tm(struct mpic *mpic, unsigned int irq)
> > +{
> > + unsigned int src = mpic_irq_to_hw(irq);
> > +
> > + return (src >= mpic->timer_vecs[0] && src <= mpic->timer_vecs[7]);
> > +}
> >
> > /* Convert a cpu mask from logical to physical cpu numbers. */
> > static inline u32 mpic_physmask(u32 cpumask)
> > @@ -814,6 +845,25 @@ static void mpic_end_ipi(struct irq_data *d)
> >
> > #endif /* CONFIG_SMP */
> >
> > +static void mpic_unmask_tm(struct irq_data *d)
> > +{
> > + struct mpic *mpic = mpic_from_irq_data(d);
> > + unsigned int src = mpic_irq_to_hw(d->irq) - mpic->timer_vecs[0];
> > +
> > + DBG("%s: enable_tm: %d (tm %d)\n", mpic->name, irq, src);
> > + mpic_tm_write(src, mpic_tm_read(src) & ~MPIC_VECPRI_MASK);
> > + mpic_tm_read(src);
> > +}
> > +
> > +static void mpic_mask_tm(struct irq_data *d)
> > +{
> > + struct mpic *mpic = mpic_from_irq_data(d);
> > + unsigned int src = mpic_irq_to_hw(d->irq) - mpic->timer_vecs[0];
> > +
> > + mpic_tm_write(src, mpic_tm_read(src) | MPIC_VECPRI_MASK);
> > + mpic_tm_read(src);
> > +}
> > +
> > int mpic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
> > bool force)
> > {
> > @@ -948,6 +998,12 @@ static struct irq_chip mpic_ipi_chip = {
> > };
> > #endif /* CONFIG_SMP */
> >
> > +static struct irq_chip mpic_tm_chip = {
> > + .irq_mask = mpic_mask_tm,
> > + .irq_unmask = mpic_unmask_tm,
> > + .irq_eoi = mpic_end_irq,
> > +};
> > +
> > #ifdef CONFIG_MPIC_U3_HT_IRQS
> > static struct irq_chip mpic_irq_ht_chip = {
> > .irq_startup = mpic_startup_ht_irq,
> > @@ -991,6 +1047,16 @@ static int mpic_host_map(struct irq_host *h, unsigned int virq,
> > }
> > #endif /* CONFIG_SMP */
> >
> > + if (hw >= mpic->timer_vecs[0] && hw <= mpic->timer_vecs[7]) {
> > + WARN_ON(!(mpic->flags & MPIC_PRIMARY));
> > +
> > + DBG("mpic: mapping as timer\n");
> > + set_irq_chip_data(virq, mpic);
> > + set_irq_chip_and_handler(virq, &mpic->hc_tm,
> > + handle_fasteoi_irq);
> > + return 0;
> > + }
> > +
> > if (hw >= mpic->irq_count)
> > return -EINVAL;
> >
> > @@ -1147,6 +1213,9 @@ struct mpic * __init mpic_alloc(struct device_node *node,
> > mpic->hc_ipi.name = name;
> > #endif /* CONFIG_SMP */
> >
> > + mpic->hc_tm = mpic_tm_chip;
> > + mpic->hc_tm.name = name;
> > +
> > mpic->flags = flags;
> > mpic->isu_size = isu_size;
> > mpic->irq_count = irq_count;
> > @@ -1157,10 +1226,14 @@ struct mpic * __init mpic_alloc(struct device_node *node,
> > else
> > intvec_top = 255;
> >
> > - mpic->timer_vecs[0] = intvec_top - 8;
> > - mpic->timer_vecs[1] = intvec_top - 7;
> > - mpic->timer_vecs[2] = intvec_top - 6;
> > - mpic->timer_vecs[3] = intvec_top - 5;
> > + mpic->timer_vecs[0] = intvec_top - 12;
> > + mpic->timer_vecs[1] = intvec_top - 11;
> > + mpic->timer_vecs[2] = intvec_top - 10;
> > + mpic->timer_vecs[3] = intvec_top - 9;
> > + mpic->timer_vecs[4] = intvec_top - 8;
> > + mpic->timer_vecs[5] = intvec_top - 7;
> > + mpic->timer_vecs[6] = intvec_top - 6;
> > + mpic->timer_vecs[7] = intvec_top - 5;
> > mpic->ipi_vecs[0] = intvec_top - 4;
> > mpic->ipi_vecs[1] = intvec_top - 3;
> > mpic->ipi_vecs[2] = intvec_top - 2;
> > @@ -1363,15 +1436,17 @@ void __init mpic_init(struct mpic *mpic)
> > /* Set current processor priority to max */
> > mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
> >
> > - /* Initialize timers: just disable them all */
> > + /* Initialize timers to our reserved vectors and mask them for now */
> > for (i = 0; i < 4; i++) {
> > mpic_write(mpic->tmregs,
> > i * MPIC_INFO(TIMER_STRIDE) +
> > - MPIC_INFO(TIMER_DESTINATION), 0);
> > + MPIC_INFO(TIMER_DESTINATION),
> > + 1 << hard_smp_processor_id());
> > mpic_write(mpic->tmregs,
> > i * MPIC_INFO(TIMER_STRIDE) +
> > MPIC_INFO(TIMER_VECTOR_PRI),
> > MPIC_VECPRI_MASK |
> > + (9 << MPIC_VECPRI_PRIORITY_SHIFT) |
> > (mpic->timer_vecs[0] + i));
> > }
> >
> > @@ -1480,6 +1555,11 @@ void mpic_irq_set_priority(unsigned int irq, unsigned int pri)
> > ~MPIC_VECPRI_PRIORITY_MASK;
> > mpic_ipi_write(src - mpic->ipi_vecs[0],
> > reg | (pri << MPIC_VECPRI_PRIORITY_SHIFT));
> > + } else if (mpic_is_tm(mpic, irq)) {
> > + reg = mpic_tm_read(src - mpic->timer_vecs[0]) &
> > + ~MPIC_VECPRI_PRIORITY_MASK;
> > + mpic_tm_write(src - mpic->timer_vecs[0],
> > + reg | (pri << MPIC_VECPRI_PRIORITY_SHIFT));
> > } else {
> > reg = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI))
> > & ~MPIC_VECPRI_PRIORITY_MASK;
> > --
> > 1.7.1
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/pseries: Add support for IO event interrupts
From: Benjamin Herrenschmidt @ 2011-05-06 3:51 UTC (permalink / raw)
To: Tseng-Hui (Frank) Lin; +Cc: tsenglin, linuxppc-dev
In-Reply-To: <1304634768.5943.4.camel@flin.austin.ibm.com>
On Thu, 2011-05-05 at 17:32 -0500, Tseng-Hui (Frank) Lin wrote:
> From: Tseng-Hui (Frank) Lin <thlin@linux.vnet.ibm.com>
>
> This patch adds support for handling IO Event interrupts which come
> through at the /event-sources/ibm,io-events device tree node.
>
> The interrupts come through ibm,io-events device tree node are generated
> by the firmware to report IO events. The firmware uses the same interrupt
> to report multiple types of events for multiple devices. Each device may
> have its own event handler. This patch implements a plateform interrupt
> handler that is triggered by the IO event interrupts come through
> ibm,io-events device tree node, pull in the IO events from RTAS and call
> device event handlers registered in the notifier list.
>
> Device event handlers are expected to use atomic_notifier_chain_register()
> and atomic_notifier_chain_unregister() to register/unregister their
> event handler in pseries_ioei_notifier_list list with IO event interrupt.
> Device event handlers are responsible to identify if the event belongs
> to the device event handler. The device event handle should return NOTIFY_OK
> after the event is handled if the event belongs to the device event handler,
> or NOTIFY_DONE otherwise.
>
> Change log:
> - Fixed compilation errors
> - Fix comments to be docbook compliant
> - Fix some code format
>
> Signed-off-by: Tseng-Hui (Frank) Lin <thlin@us.ibm.com>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
Next time, please put the change log -after- the "---" so it is not part
of what gets committed. I've fixed it up by hand for now.
Cheers,
Ben.
> arch/powerpc/include/asm/io_event_irq.h | 54 ++++++
> arch/powerpc/platforms/pseries/Kconfig | 18 ++
> arch/powerpc/platforms/pseries/Makefile | 1 +
> arch/powerpc/platforms/pseries/io_event_irq.c | 231 +++++++++++++++++++++++++
> 4 files changed, 304 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/io_event_irq.h b/arch/powerpc/include/asm/io_event_irq.h
> new file mode 100644
> index 0000000..b1a9a1b
> --- /dev/null
> +++ b/arch/powerpc/include/asm/io_event_irq.h
> @@ -0,0 +1,54 @@
> +/*
> + * Copyright 2010, 2011 Mark Nelson and Tseng-Hui (Frank) Lin, IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#ifndef _ASM_POWERPC_IO_EVENT_IRQ_H
> +#define _ASM_POWERPC_IO_EVENT_IRQ_H
> +
> +#include <linux/types.h>
> +#include <linux/notifier.h>
> +
> +#define PSERIES_IOEI_RPC_MAX_LEN 216
> +
> +#define PSERIES_IOEI_TYPE_ERR_DETECTED 0x01
> +#define PSERIES_IOEI_TYPE_ERR_RECOVERED 0x02
> +#define PSERIES_IOEI_TYPE_EVENT 0x03
> +#define PSERIES_IOEI_TYPE_RPC_PASS_THRU 0x04
> +
> +#define PSERIES_IOEI_SUBTYPE_NOT_APP 0x00
> +#define PSERIES_IOEI_SUBTYPE_REBALANCE_REQ 0x01
> +#define PSERIES_IOEI_SUBTYPE_NODE_ONLINE 0x03
> +#define PSERIES_IOEI_SUBTYPE_NODE_OFFLINE 0x04
> +#define PSERIES_IOEI_SUBTYPE_DUMP_SIZE_CHANGE 0x05
> +#define PSERIES_IOEI_SUBTYPE_TORRENT_IRV_UPDATE 0x06
> +#define PSERIES_IOEI_SUBTYPE_TORRENT_HFI_CFGED 0x07
> +
> +#define PSERIES_IOEI_SCOPE_NOT_APP 0x00
> +#define PSERIES_IOEI_SCOPE_RIO_HUB 0x36
> +#define PSERIES_IOEI_SCOPE_RIO_BRIDGE 0x37
> +#define PSERIES_IOEI_SCOPE_PHB 0x38
> +#define PSERIES_IOEI_SCOPE_EADS_GLOBAL 0x39
> +#define PSERIES_IOEI_SCOPE_EADS_SLOT 0x3A
> +#define PSERIES_IOEI_SCOPE_TORRENT_HUB 0x3B
> +#define PSERIES_IOEI_SCOPE_SERVICE_PROC 0x51
> +
> +/* Platform Event Log Format, Version 6, data portition of IO event section */
> +struct pseries_io_event {
> + uint8_t event_type; /* 0x00 IO-Event Type */
> + uint8_t rpc_data_len; /* 0x01 RPC data length */
> + uint8_t scope; /* 0x02 Error/Event Scope */
> + uint8_t event_subtype; /* 0x03 I/O-Event Sub-Type */
> + uint32_t drc_index; /* 0x04 DRC Index */
> + uint8_t rpc_data[PSERIES_IOEI_RPC_MAX_LEN];
> + /* 0x08 RPC Data (0-216 bytes, */
> + /* padded to 4 bytes alignment) */
> +};
> +
> +extern struct atomic_notifier_head pseries_ioei_notifier_list;
> +
> +#endif /* _ASM_POWERPC_IO_EVENT_IRQ_H */
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index b044922..71af4c5 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -50,6 +50,24 @@ config SCANLOG
> tristate "Scanlog dump interface"
> depends on RTAS_PROC && PPC_PSERIES
>
> +config IO_EVENT_IRQ
> + bool "IO Event Interrupt support"
> + depends on PPC_PSERIES
> + default y
> + help
> + Select this option, if you want to enable support for IO Event
> + interrupts. IO event interrupt is a mechanism provided by RTAS
> + to return information about hardware error and non-error events
> + which may need OS attention. RTAS returns events for multiple
> + event types and scopes. Device drivers can register their handlers
> + to receive events.
> +
> + This option will only enable the IO event platform code. You
> + will still need to enable or compile the actual drivers
> + that use this infrastruture to handle IO event interrupts.
> +
> + Say Y if you are unsure.
> +
> config LPARCFG
> bool "LPAR Configuration Data"
> depends on PPC_PSERIES || PPC_ISERIES
> diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
> index 4cfefba..3556e40 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
> obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
> obj-$(CONFIG_CMM) += cmm.o
> obj-$(CONFIG_DTL) += dtl.o
> +obj-$(CONFIG_IO_EVENT_IRQ) += io_event_irq.o
>
> ifeq ($(CONFIG_PPC_PSERIES),y)
> obj-$(CONFIG_SUSPEND) += suspend.o
> diff --git a/arch/powerpc/platforms/pseries/io_event_irq.c b/arch/powerpc/platforms/pseries/io_event_irq.c
> new file mode 100644
> index 0000000..c829e60
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/io_event_irq.c
> @@ -0,0 +1,231 @@
> +/*
> + * Copyright 2010 2011 Mark Nelson and Tseng-Hui (Frank) Lin, IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/list.h>
> +#include <linux/notifier.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/rtas.h>
> +#include <asm/irq.h>
> +#include <asm/io_event_irq.h>
> +
> +#include "pseries.h"
> +
> +/*
> + * IO event interrupt is a mechanism provided by RTAS to return
> + * information about hardware error and non-error events. Device
> + * drivers can register their event handlers to receive events.
> + * Device drivers are expected to use atomic_notifier_chain_register()
> + * and atomic_notifier_chain_unregister() to register and unregister
> + * their event handlers. Since multiple IO event types and scopes
> + * share an IO event interrupt, the event handlers are called one
> + * by one until the IO event is claimed by one of the handlers.
> + * The event handlers are expected to return NOTIFY_OK if the
> + * event is handled by the event handler or NOTIFY_DONE if the
> + * event does not belong to the handler.
> + *
> + * Usage:
> + *
> + * Notifier function:
> + * #include <asm/io_event_irq.h>
> + * int event_handler(struct notifier_block *nb, unsigned long val, void *data) {
> + * p = (struct pseries_io_event_sect_data *) data;
> + * if (! is_my_event(p->scope, p->event_type)) return NOTIFY_DONE;
> + * :
> + * :
> + * return NOTIFY_OK;
> + * }
> + * struct notifier_block event_nb = {
> + * .notifier_call = event_handler,
> + * }
> + *
> + * Registration:
> + * atomic_notifier_chain_register(&pseries_ioei_notifier_list, &event_nb);
> + *
> + * Unregistration:
> + * atomic_notifier_chain_unregister(&pseries_ioei_notifier_list, &event_nb);
> + */
> +
> +ATOMIC_NOTIFIER_HEAD(pseries_ioei_notifier_list);
> +EXPORT_SYMBOL_GPL(pseries_ioei_notifier_list);
> +
> +static int ioei_check_exception_token;
> +
> +/* pSeries event log format */
> +
> +/* Two bytes ASCII section IDs */
> +#define PSERIES_ELOG_SECT_ID_PRIV_HDR (('P' << 8) | 'H')
> +#define PSERIES_ELOG_SECT_ID_USER_HDR (('U' << 8) | 'H')
> +#define PSERIES_ELOG_SECT_ID_PRIMARY_SRC (('P' << 8) | 'S')
> +#define PSERIES_ELOG_SECT_ID_EXTENDED_UH (('E' << 8) | 'H')
> +#define PSERIES_ELOG_SECT_ID_FAILING_MTMS (('M' << 8) | 'T')
> +#define PSERIES_ELOG_SECT_ID_SECONDARY_SRC (('S' << 8) | 'S')
> +#define PSERIES_ELOG_SECT_ID_DUMP_LOCATOR (('D' << 8) | 'H')
> +#define PSERIES_ELOG_SECT_ID_FW_ERROR (('S' << 8) | 'W')
> +#define PSERIES_ELOG_SECT_ID_IMPACT_PART_ID (('L' << 8) | 'P')
> +#define PSERIES_ELOG_SECT_ID_LOGIC_RESOURCE_ID (('L' << 8) | 'R')
> +#define PSERIES_ELOG_SECT_ID_HMC_ID (('H' << 8) | 'M')
> +#define PSERIES_ELOG_SECT_ID_EPOW (('E' << 8) | 'P')
> +#define PSERIES_ELOG_SECT_ID_IO_EVENT (('I' << 8) | 'E')
> +#define PSERIES_ELOG_SECT_ID_MANUFACT_INFO (('M' << 8) | 'I')
> +#define PSERIES_ELOG_SECT_ID_CALL_HOME (('C' << 8) | 'H')
> +#define PSERIES_ELOG_SECT_ID_USER_DEF (('U' << 8) | 'D')
> +
> +/* Vendor specific Platform Event Log Format, Version 6, section header */
> +struct pseries_elog_section {
> + uint16_t id; /* 0x00 2-byte ASCII section ID */
> + uint16_t length; /* 0x02 Section length in bytes */
> + uint8_t version; /* 0x04 Section version */
> + uint8_t subtype; /* 0x05 Section subtype */
> + uint16_t creator_component; /* 0x06 Creator component ID */
> + uint8_t data[]; /* 0x08 Start of section data */
> +};
> +
> +static char ioei_rtas_buf[RTAS_DATA_BUF_SIZE] __cacheline_aligned;
> +
> +/**
> + * Find data portion of a specific section in RTAS extended event log.
> + * @elog: RTAS error/event log.
> + * @sect_id: secsion ID.
> + *
> + * Return:
> + * pointer to the section data of the specified section
> + * NULL if not found
> + */
> +static struct pseries_elog_section *find_xelog_section(struct rtas_error_log *elog,
> + uint16_t sect_id)
> +{
> + struct rtas_ext_event_log_v6 *xelog =
> + (struct rtas_ext_event_log_v6 *) elog->buffer;
> + struct pseries_elog_section *sect;
> + unsigned char *p, *log_end;
> +
> + /* Check that we understand the format */
> + if (elog->extended_log_length < sizeof(struct rtas_ext_event_log_v6) ||
> + xelog->log_format != RTAS_V6EXT_LOG_FORMAT_EVENT_LOG ||
> + xelog->company_id != RTAS_V6EXT_COMPANY_ID_IBM)
> + return NULL;
> +
> + log_end = elog->buffer + elog->extended_log_length;
> + p = xelog->vendor_log;
> + while (p < log_end) {
> + sect = (struct pseries_elog_section *)p;
> + if (sect->id == sect_id)
> + return sect;
> + p += sect->length;
> + }
> + return NULL;
> +}
> +
> +/**
> + * Find the data portion of an IO Event section from event log.
> + * @elog: RTAS error/event log.
> + *
> + * Return:
> + * pointer to a valid IO event section data. NULL if not found.
> + */
> +static struct pseries_io_event * ioei_find_event(struct rtas_error_log *elog)
> +{
> + struct pseries_elog_section *sect;
> +
> + /* We should only ever get called for io-event interrupts, but if
> + * we do get called for another type then something went wrong so
> + * make some noise about it.
> + * RTAS_TYPE_IO only exists in extended event log version 6 or later.
> + * No need to check event log version.
> + */
> + if (unlikely(elog->type != RTAS_TYPE_IO)) {
> + printk_once(KERN_WARNING "io_event_irq: Unexpected event type %d",
> + elog->type);
> + return NULL;
> + }
> +
> + sect = find_xelog_section(elog, PSERIES_ELOG_SECT_ID_IO_EVENT);
> + if (unlikely(!sect)) {
> + printk_once(KERN_WARNING "io_event_irq: RTAS extended event "
> + "log does not contain an IO Event section. "
> + "Could be a bug in system firmware!\n");
> + return NULL;
> + }
> + return (struct pseries_io_event *) §->data;
> +}
> +
> +/*
> + * PAPR:
> + * - check-exception returns the first found error or event and clear that
> + * error or event so it is reported once.
> + * - Each interrupt returns one event. If a plateform chooses to report
> + * multiple events through a single interrupt, it must ensure that the
> + * interrupt remains asserted until check-exception has been used to
> + * process all out-standing events for that interrupt.
> + *
> + * Implementation notes:
> + * - Events must be processed in the order they are returned. Hence,
> + * sequential in nature.
> + * - The owner of an event is determined by combinations of scope,
> + * event type, and sub-type. There is no easy way to pre-sort clients
> + * by scope or event type alone. For example, Torrent ISR route change
> + * event is reported with scope 0x00 (Not Applicatable) rather than
> + * 0x3B (Torrent-hub). It is better to let the clients to identify
> + * who owns the the event.
> + */
> +
> +static irqreturn_t ioei_interrupt(int irq, void *dev_id)
> +{
> + struct pseries_io_event *event;
> + int rtas_rc;
> +
> + for (;;) {
> + rtas_rc = rtas_call(ioei_check_exception_token, 6, 1, NULL,
> + RTAS_VECTOR_EXTERNAL_INTERRUPT,
> + virq_to_hw(irq),
> + RTAS_IO_EVENTS, 1 /* Time Critical */,
> + __pa(ioei_rtas_buf),
> + RTAS_DATA_BUF_SIZE);
> + if (rtas_rc != 0)
> + break;
> +
> + event = ioei_find_event((struct rtas_error_log *)ioei_rtas_buf);
> + if (!event)
> + continue;
> +
> + atomic_notifier_call_chain(&pseries_ioei_notifier_list,
> + 0, event);
> + }
> + return IRQ_HANDLED;
> +}
> +
> +static int __init ioei_init(void)
> +{
> + struct device_node *np;
> +
> + ioei_check_exception_token = rtas_token("check-exception");
> + if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE) {
> + pr_warning("IO Event IRQ not supported on this system !\n");
> + return -ENODEV;
> + }
> + np = of_find_node_by_path("/event-sources/ibm,io-events");
> + if (np) {
> + request_event_sources_irqs(np, ioei_interrupt, "IO_EVENT");
> + of_node_put(np);
> + } else {
> + pr_err("io_event_irq: No ibm,io-events on system! "
> + "IO Event interrupt disabled.\n");
> + return -ENODEV;
> + }
> + return 0;
> +}
> +machine_subsys_initcall(pseries, ioei_init);
> +
>
^ permalink raw reply
* Re: [PATCH] powerpc, hw_breakpoints: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg
From: Ingo Molnar @ 2011-05-06 6:13 UTC (permalink / raw)
To: Frederic Weisbecker, Benjamin Herrenschmidt, Paul Mackerras
Cc: Prasad, LPPC, LKML, v2.6.33..
In-Reply-To: <1304639598-4707-1-git-send-email-fweisbec@gmail.com>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> We make use of ptrace_get_breakpoints() / ptrace_put_breakpoints()
> to protect ptrace_set_debugreg() even if CONFIG_HAVE_HW_BREAKPOINT
> if off. However in this case, these APIs are not implemented.
>
> To fix this, push the protection down inside the relevant ifdef.
> Best would be to export the code inside CONFIG_HAVE_HW_BREAKPOINT
> into a standalone function to cleanup the ifdefury there and call
> the breakpoint ref API inside. But as it is more invasive, this
> should be rather made in an -rc1.
>
> Fixes:
>
> arch/powerpc/kernel/ptrace.c:1594: error: implicit declaration of function 'ptrace_get_breakpoints'
> make[2]: *** [arch/powerpc/kernel/ptrace.o] Error 1
> make[1]: *** [arch/powerpc/kernel] Error 2
> make: *** [sub-make] Error 2
Thanks.
I'll need a PowerPC ack for this. Note: it's dependent on hw-breakpoint fixes
in tip:perf/urgent so the commit will want to go there too.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 7/7] ARM: mxc: remove esdhc.h and use the public one
From: Uwe Kleine-König @ 2011-05-06 8:39 UTC (permalink / raw)
To: Shawn Guo
Cc: Anton Vorontsov, sameo, Arnd Bergmann, patches,
devicetree-discuss, linux-mmc, Saeed Bishara, linux-arm-kernel,
kernel, Mike Rapoport, Olof Johansson, Chris Ball, linuxppc-dev,
Albert Herranz, Xiaobo Xie
In-Reply-To: <1304601778-13837-8-git-send-email-shawn.guo@linaro.org>
Hello Shawn,
On Thu, May 05, 2011 at 09:22:58PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> .../plat-mxc/devices/platform-sdhci-esdhc-imx.c | 1 -
> arch/arm/plat-mxc/include/mach/devices-common.h | 2 +-
what about removing arch/arm/plat-mxc/include/mach/esdhc.h in this
patch as advertised in the subject?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [tip:perf/urgent] hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()
From: tip-bot for Frederic Weisbecker @ 2011-05-06 9:43 UTC (permalink / raw)
To: linux-tip-commits
Cc: fweisbec, mingo, linux-kernel, mingo, prasad, hpa, tglx,
linuxppc-dev, stable
In-Reply-To: <1304639598-4707-1-git-send-email-fweisbec@gmail.com>
Commit-ID: 925f83c085e1bb08435556c5b4844a60de002e31
Gitweb: http://git.kernel.org/tip/925f83c085e1bb08435556c5b4844a60de002e31
Author: Frederic Weisbecker <fweisbec@gmail.com>
AuthorDate: Fri, 6 May 2011 01:53:18 +0200
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 6 May 2011 11:24:46 +0200
hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()
We make use of ptrace_get_breakpoints() / ptrace_put_breakpoints() to
protect ptrace_set_debugreg() even if CONFIG_HAVE_HW_BREAKPOINT if off.
However in this case, these APIs are not implemented.
To fix this, push the protection down inside the relevant ifdef.
Best would be to export the code inside
CONFIG_HAVE_HW_BREAKPOINT into a standalone function to cleanup
the ifdefury there and call the breakpoint ref API inside. But
as it is more invasive, this should be rather made in an -rc1.
Fixes this build error:
arch/powerpc/kernel/ptrace.c:1594: error: implicit declaration of function 'ptrace_get_breakpoints' make[2]: ***
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LPPC <linuxppc-dev@lists.ozlabs.org>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: v2.6.33.. <stable@kernel.org>
Link: http://lkml.kernel.org/r/1304639598-4707-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/kernel/ptrace.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 4edeeb3..a6ae1cf 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -933,12 +933,16 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
if (data && !(data & DABR_TRANSLATION))
return -EIO;
#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(task) < 0)
+ return -ESRCH;
+
bp = thread->ptrace_bps[0];
if ((!data) || !(data & (DABR_DATA_WRITE | DABR_DATA_READ))) {
if (bp) {
unregister_hw_breakpoint(bp);
thread->ptrace_bps[0] = NULL;
}
+ ptrace_put_breakpoints(task);
return 0;
}
if (bp) {
@@ -948,9 +952,12 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
(DABR_DATA_WRITE | DABR_DATA_READ),
&attr.bp_type);
ret = modify_user_hw_breakpoint(bp, &attr);
- if (ret)
+ if (ret) {
+ ptrace_put_breakpoints(task);
return ret;
+ }
thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(task);
thread->dabr = data;
return 0;
}
@@ -965,9 +972,12 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
ptrace_triggered, task);
if (IS_ERR(bp)) {
thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(task);
return PTR_ERR(bp);
}
+ ptrace_put_breakpoints(task);
+
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
/* Move contents to the DABR register */
@@ -1591,10 +1601,7 @@ long arch_ptrace(struct task_struct *child, long request,
}
case PTRACE_SET_DEBUGREG:
- if (ptrace_get_breakpoints(child) < 0)
- return -ESRCH;
ret = ptrace_set_debugreg(child, addr, data);
- ptrace_put_breakpoints(child);
break;
#ifdef CONFIG_PPC64
^ permalink raw reply related
* [RFC v2] virtio: add virtio-over-PCI driver
From: Kushwaha Prabhakar-B32579 @ 2011-05-06 12:00 UTC (permalink / raw)
To: iws@ovro.caltech.edu
Cc: Aggrwal Poonam-B10812, netdev@vger.kernel.org, Zang Roy-R61911,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Kalra Ashish-B00888, Gala Kumar-B11780, Gupta Maneesh-B18878
Hi,
I want to use this patch as base patch for "FSL 85xx platform" to support P=
CIe Agent.
The work looks to be little old now. So wanted to understand if any develop=
ment has happened further on it.
In case no, I would take this work forward for PCIe Agent.=20
Any help/suggestions are most appreciated in this regard.
Thanks,
Prabhakar
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.ke=
rnel.org] On Behalf Of Ira Snyder
Sent: Friday, 27 February, 2009 3:19 AM
To: Arnd Bergmann
Cc: linux-kernel@vger.kernel.org; Rusty Russell; Jan-Bernd Themann; linuxpp=
c-dev@ozlabs.org; netdev@vger.kernel.org
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> On Thursday 26 February 2009, Ira Snyder wrote:
> > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> >
> > I think so too. I was just getting something working, and thought it=20
> > would be better to have it "out there" rather than be working on it=20
> > forever. I'll try to break things up as I have time.
>=20
> Ok, perfect!
> =20
> > For the "libraries", would you suggest breaking things into seperate=20
> > code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar=20
> > with doing that, I've mostly been writing code within the existing=20
> > device driver frameworks. Or do I need export symbol at all? I'm not su=
re...
>=20
> You have both options. When you list each file as a separate module in=20
> the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that get=20
> called by dependent modules, but this will work only in one way.
>=20
> You can also link multiple files together into one module, although it=20
> is less common to link a single source file into multiple modules.
>=20
Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do that=
. If we decide it sucks later, we'll change it.
> > I always thought you were supposed to use packed for data structures=20
> > that are external to the system. I purposely designed the structures=20
> > so they wouldn't need padding.
>=20
> That would only make sense for structures that are explicitly=20
> unaligned, like a register layout using
>=20
> struct my_registers {
> __le16 first;
> __le32 second __attribute__((packed));
> __le16 third;
> };
>=20
> Even here, I'd recommend listing the individual members as packed=20
> rather than the entire struct. Obviously if you layout the members in=20
> a sane way, you don't need either.
>=20
Ok. I'll drop the __attribute__((packed)) and make sure there aren't proble=
ms. I don't suspect any, though.
> > I mostly don't need it. In fact, the only place I'm using registers=20
> > not specific to the messaging unit is in the probe routine, where I=20
> > setup the 1GB window into host memory and setting up access to the=20
> > guest memory on the PCI bus.
>=20
> You could add the registers you need for this to the "reg" property of=20
> your device, to be mapped with of_iomap.
>=20
> If the registers for setting up this window don't logically fit into=20
> the same device as the one you already use, the cleanest solution=20
> would be to have another device just for this and then make a function=20
> call into that driver to set up the window.
>=20
The registers are part of the board control registers. They don't fit at al=
l in the message unit. Doing this in the bootloader seems like a logical pl=
ace, but that would require any testers to flash a new U-Boot image into th=
eir mpc8349emds boards.
The first set of access is used to set up a 1GB region in the memory map th=
at accesses the host's memory. Any reads/writes to addresses 0x80000000-0xc=
0000000 actually hit the host's memory.
The last access sets up PCI BAR1 to hit the memory from dma_alloc_coherent(=
). The bootloader already sets up the window as 16K, it just doesn't point =
it anywhere. Maybe this /should/ go into the bootloader. Like above, it wou=
ld require testers to flash a new U-Boot image into their mpc8349emds board=
s.
> > Now, I wouldn't need to access these registers at all if the=20
> > bootloader could handle it. I just don't know if it is possible to=20
> > have Linux not use some memory that the bootloader allocated, other=20
> > than with the mem=3DXXX trick, which I'm sure wouldn't be acceptable.
> > I've just used regular RAM so this is portable to my custom board=20
> > (mpc8349emds based) and a regular mpc8349emds. I didn't want to=20
> > change anything board specific.
> >=20
> > I would love to have the bootloader allocate (or reserve somewhere=20
> > in the memory map) 16K of RAM, and not be required to allocate it=20
> > with dma_alloc_coherent(). It would save me plenty of headaches.
>=20
> I believe you can do that through the "memory" devices in the device=20
> tree, by leaving out a small part of the description of main memory,=20
> at putting it into the "reg" property of your own device.
>=20
I'll explore this option. I didn't even know you could do this. Is a drive=
r that requires the trick acceptable for mainline inclusion? Just like sett=
ing up the 16K PCI window, this is very platform specific.
This limits the guest driver to systems which are able to change Linux's vi=
ew of their memory somehow. Maybe this isn't a problem.
> > Code complexity only. Also, it was easier to write 80-char lines=20
> > with something like:
> >=20
> > vop_get_desc(vq, idx, &desc);
> > if (desc.flags & VOP_DESC_F_NEXT) {
> > /* do something */
> > }
> >=20
> > Instead of:
> > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > /* do something */
> > }
> >=20
> > Plus, I didn't have to remember how many bits were in each field. I=20
> > just thought it made everything simpler to understand. Suggestions?
>=20
> hmm, in this particular case, you could change the definition of=20
> VOP_DESC_F_NEXT to
>=20
> #define VOP_DESC_F_NEXT cpu_to_le16(1)
>=20
> and then do the code as the even simpler (source and object code wise)
>=20
> if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
>=20
> I'm not sure if you can do something along these lines for the other=20
> cases as well though.
>=20
That's a good idea. It wouldn't fix the addresses, lengths, and next fields=
, though. I'll make the change and see how bad it is, then report back. It =
may not be so bad after all.
> > I used 3 so they would would align to 1024 byte boundaries within a=20
> > 4K page. Then the layout was 16K on the bus, each 4K page is a=20
> > single virtio-device, and each 1K block is a single virtqueue. The=20
> > first 1K is for virtio-device status and feature bits, etc.
> >=20
> > Packing them differently isn't a problem. It was just easier to code=20
> > because setting up a window with the correct size is so platform=20
> > specific.
>=20
> Ok. I guess the important question is what part of the code makes this=20
> decision. Ideally, the virtio-net glue would instantiate the device=20
> with the right number of queues.
>=20
Yeah, virtio doesn't work that way.
The virtio drivers just call find_vq() with a different index for each queu=
e they want to use. You have no way of knowing how many queues each virtio =
driver will want, unless you go read their source code.
virtio-net currently uses 3 queues, but we only support the first two.
The third is optional (for now...), and non-symmetric.
Thanks again,
Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in =
the body of a message to majordomo@vger.kernel.org More majordomo info at =
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC v2] virtio: add virtio-over-PCI driver
From: Ira W. Snyder @ 2011-05-06 16:06 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Aggrwal Poonam-B10812, netdev@vger.kernel.org, Zang Roy-R61911,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Kalra Ashish-B00888, Gala Kumar-B11780, Gupta Maneesh-B18878
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F8741A54D4@039-SN1MPN1-004.039d.mgd.msft.net>
On Fri, May 06, 2011 at 12:00:34PM +0000, Kushwaha Prabhakar-B32579 wrote:
> Hi,
>
> I want to use this patch as base patch for "FSL 85xx platform" to support PCIe Agent.
> The work looks to be little old now. So wanted to understand if any development has happened further on it.
>
> In case no, I would take this work forward for PCIe Agent.
>
> Any help/suggestions are most appreciated in this regard.
>
Hi Prabhakar,
I use PCI agent mode on an mpc8349emds board. All of the important setup is
done very early in the boot process, by U-Boot. Search the U-Boot source
for CONFIG_PCISLAVE. I hunch that the setup needed for 85xx boards are
similar.
This virtio-over-PCI work is now very old. It was intended to provide a
communication mechanism between a PCI Master and many PCI Agents (slaves).
Dave Miller (networking maintainer) suggested to use virtio for this so
that many different devices could be used. Such as:
- network interface
- serial port (for serial console)
I am aware of other ongoing work in this area. Specifically, some ARM
developers are working on a virtio API using their message registers. This
work is much newer, and will be a much better starting place for you.
Search the virtualization mailing list for:
"[PATCH 00/02] virtio: Virtio platform driver"
Here is a link to some of their code:
http://www.spinics.net/lists/linux-sh/msg07188.html
I am currently using a custom driver to provide a network device on my PCI
agents. Searching the mailing list archives for "PCINet", you will find
early versions of the driver. I am happy to provide you a current copy. It
does not use virtio at all, and is unlikely to be accepted into mainline
Linux.
I am happy to provide any of my code if you think it would help you get
started. Specifically, the current version of "PCINet" show how to use the
DMA controller in order to get good network performance. I am also happy to
help port code to 83xx, as well as test on 83xx. Please ask any questions
you may have.
I have people ask about this code about once every two months. There is
plenty of interest in a mainline Linux solution to this problem. :) I
will be moving to 85xx someday, and I hope there is an accepted mainline
solution by then.
I hope it helps,
Ira
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Ira Snyder
> Sent: Friday, 27 February, 2009 3:19 AM
> To: Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org; Rusty Russell; Jan-Bernd Themann; linuxppc-dev@ozlabs.org; netdev@vger.kernel.org
> Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
>
> On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> > On Thursday 26 February 2009, Ira Snyder wrote:
> > > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> > >
> > > I think so too. I was just getting something working, and thought it
> > > would be better to have it "out there" rather than be working on it
> > > forever. I'll try to break things up as I have time.
> >
> > Ok, perfect!
> >
> > > For the "libraries", would you suggest breaking things into seperate
> > > code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar
> > > with doing that, I've mostly been writing code within the existing
> > > device driver frameworks. Or do I need export symbol at all? I'm not sure...
> >
> > You have both options. When you list each file as a separate module in
> > the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that get
> > called by dependent modules, but this will work only in one way.
> >
> > You can also link multiple files together into one module, although it
> > is less common to link a single source file into multiple modules.
> >
>
> Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do that. If we decide it sucks later, we'll change it.
>
> > > I always thought you were supposed to use packed for data structures
> > > that are external to the system. I purposely designed the structures
> > > so they wouldn't need padding.
> >
> > That would only make sense for structures that are explicitly
> > unaligned, like a register layout using
> >
> > struct my_registers {
> > __le16 first;
> > __le32 second __attribute__((packed));
> > __le16 third;
> > };
> >
> > Even here, I'd recommend listing the individual members as packed
> > rather than the entire struct. Obviously if you layout the members in
> > a sane way, you don't need either.
> >
>
> Ok. I'll drop the __attribute__((packed)) and make sure there aren't problems. I don't suspect any, though.
>
> > > I mostly don't need it. In fact, the only place I'm using registers
> > > not specific to the messaging unit is in the probe routine, where I
> > > setup the 1GB window into host memory and setting up access to the
> > > guest memory on the PCI bus.
> >
> > You could add the registers you need for this to the "reg" property of
> > your device, to be mapped with of_iomap.
> >
> > If the registers for setting up this window don't logically fit into
> > the same device as the one you already use, the cleanest solution
> > would be to have another device just for this and then make a function
> > call into that driver to set up the window.
> >
>
> The registers are part of the board control registers. They don't fit at all in the message unit. Doing this in the bootloader seems like a logical place, but that would require any testers to flash a new U-Boot image into their mpc8349emds boards.
>
> The first set of access is used to set up a 1GB region in the memory map that accesses the host's memory. Any reads/writes to addresses 0x80000000-0xc0000000 actually hit the host's memory.
>
> The last access sets up PCI BAR1 to hit the memory from dma_alloc_coherent(). The bootloader already sets up the window as 16K, it just doesn't point it anywhere. Maybe this /should/ go into the bootloader. Like above, it would require testers to flash a new U-Boot image into their mpc8349emds boards.
>
> > > Now, I wouldn't need to access these registers at all if the
> > > bootloader could handle it. I just don't know if it is possible to
> > > have Linux not use some memory that the bootloader allocated, other
> > > than with the mem=XXX trick, which I'm sure wouldn't be acceptable.
> > > I've just used regular RAM so this is portable to my custom board
> > > (mpc8349emds based) and a regular mpc8349emds. I didn't want to
> > > change anything board specific.
> > >
> > > I would love to have the bootloader allocate (or reserve somewhere
> > > in the memory map) 16K of RAM, and not be required to allocate it
> > > with dma_alloc_coherent(). It would save me plenty of headaches.
> >
> > I believe you can do that through the "memory" devices in the device
> > tree, by leaving out a small part of the description of main memory,
> > at putting it into the "reg" property of your own device.
> >
>
> I'll explore this option. I didn't even know you could do this. Is a driver that requires the trick acceptable for mainline inclusion? Just like setting up the 16K PCI window, this is very platform specific.
>
> This limits the guest driver to systems which are able to change Linux's view of their memory somehow. Maybe this isn't a problem.
>
> > > Code complexity only. Also, it was easier to write 80-char lines
> > > with something like:
> > >
> > > vop_get_desc(vq, idx, &desc);
> > > if (desc.flags & VOP_DESC_F_NEXT) {
> > > /* do something */
> > > }
> > >
> > > Instead of:
> > > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > > /* do something */
> > > }
> > >
> > > Plus, I didn't have to remember how many bits were in each field. I
> > > just thought it made everything simpler to understand. Suggestions?
> >
> > hmm, in this particular case, you could change the definition of
> > VOP_DESC_F_NEXT to
> >
> > #define VOP_DESC_F_NEXT cpu_to_le16(1)
> >
> > and then do the code as the even simpler (source and object code wise)
> >
> > if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
> >
> > I'm not sure if you can do something along these lines for the other
> > cases as well though.
> >
>
> That's a good idea. It wouldn't fix the addresses, lengths, and next fields, though. I'll make the change and see how bad it is, then report back. It may not be so bad after all.
>
> > > I used 3 so they would would align to 1024 byte boundaries within a
> > > 4K page. Then the layout was 16K on the bus, each 4K page is a
> > > single virtio-device, and each 1K block is a single virtqueue. The
> > > first 1K is for virtio-device status and feature bits, etc.
> > >
> > > Packing them differently isn't a problem. It was just easier to code
> > > because setting up a window with the correct size is so platform
> > > specific.
> >
> > Ok. I guess the important question is what part of the code makes this
> > decision. Ideally, the virtio-net glue would instantiate the device
> > with the right number of queues.
> >
>
> Yeah, virtio doesn't work that way.
>
> The virtio drivers just call find_vq() with a different index for each queue they want to use. You have no way of knowing how many queues each virtio driver will want, unless you go read their source code.
>
> virtio-net currently uses 3 queues, but we only support the first two.
> The third is optional (for now...), and non-symmetric.
>
> Thanks again,
> Ira
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Scott Wood @ 2011-05-06 19:29 UTC (permalink / raw)
To: Meador Inge
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
Hollis Blanchard, Kushwaha Prabhakar-B32579,
openmcapi-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4DC31989.8080703@mentor.com>
On Thu, 5 May 2011 16:41:29 -0500
Meador Inge <meador_inge@mentor.com> wrote:
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> mpic-msgr-send-mask = <0xa>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb6 2>;
> mpic-msgr-receive-mask = <0x5>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0xa>;
> mpic-msgr-send-mask = <0x5>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb6 2>;
> mpic-msgr-send-mask = <0x5>;
> };
>
> In block0 for both OSes, all registers are partitioned and are thus not
> available for allocation. In block1 for both OSes, registers 0 and 2 are
> reserved and registers 1 and 3 are available for general allocation.
How can both OSes independently own registers 1 and 3 for alloction? And
where are the interrupt specifiers for these registers?
> So any register mentioned in one of 'mpic-msgr-receive-mask' or
> 'mpic-msgr-send-mask' is out of the running for general allocation.
mpic-msgr-receive-mask has to match interrupts -- it's not intended to be
an indication of usage, just that this partition is granted those
interrupts.
Plus, a dynamically allocated message register must be owned for both
sending and receiving, so it doesn't make sense to separate it. I'd have
an "mpic-msgr-free-mask" property, which must be a subset of
"mpic-msgr-receive-mask". If the register is not in free-mask, it is
reserved for a fixed purpose. If free-mask is absent, all registers in the
receive-mask can be allocated.
So the above example would be:
/* OS 1 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb0 2 0xb2 2>;
mpic-msgr-receive-mask = <0x5>;
mpic-msgr-free-mask = <0>;
};
mpic_msgr_block1: mpic-msgr-block@42400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x42400 0x200>;
interrupts = <0xb4 2 0xb5 2>;
mpic-msgr-receive-mask = <0x3>;
mpic-msgr-free-mask = <0x2>;
};
/* OS 2 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb1 2 0xb3 2>;
mpic-msgr-receive-mask = <0xa>;
mpic-msgr-free-mask = <0>;
};
mpic_msgr_block1: mpic-msgr-block@42400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x42400 0x200>;
interrupts = <0xb6 2 0xb7 2>;
mpic-msgr-receive-mask = <0xc>;
mpic-msgr-free-mask = <0x8>;
};
mpic-msgr-send-mask could be added as well, as a permissions mechanism to
serve as extra protection against an improperly specified non-free message
register -- especially if the interface is exposed to a less-trusted realm
such as userspace, or if a hypervisor is reading the device tree to
determine what to allow guests to do. In this case, just like
mpic-msgr-receive-mask, it would list both free and non-free message
registers that the partition can send to, and mpic-msgr-free-mask would be
a subset of both the send and receive masks.
> You could get into trouble with this method with cases like:
>
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-send-mask = <0xa>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> };
>
> Now OS 1 has registers 0 and 2 available for general allocation, which
> OS 2 is receiving on. However, we already have that problem if someone
> botches the masks. So I am not very worried about that.
There's a big difference between "botching the masks" and having no way to
express the situation properly.
BTW, the above fragment has the two OSes inappropriately sharing
interrupts, and OS1 has only two interrupts but no receive mask
(and therefore owns all 4 message registers for receive). Only one OS
should be able to receive any given interrupt.
Consider this:
/* OS 1 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb0 2 0xb1 2>;
mpic-msgr-receive-mask = <0x3>;
mpic-msgr-send-mask = <0xc>;
};
/* OS 2 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb2 2>;
mpic-msgr-receive-mask = <0x4>;
mpic-msgr-send-mask = <0x1>;
};
/* OS 3 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb3 2>;
mpic-msgr-receive-mask = <0x8>;
mpic-msgr-send-mask = <0x2>;
};
None of the message registers are actually free for allocation, but with
your scheme OS 2 would think it could allocate 1 and 3, and OS 3 would
think it could allocate 0 and 2. Even if a register were actually free
from a reserved use, it would have to be owned by one partition.
-Scott
^ permalink raw reply
* [PATCH] powerpc: fix kexec with dynamic dma windows
From: Nishanth Aravamudan @ 2011-05-06 23:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, Milton Miller
When we kexec we look for a particular property added by the first
kernel, "linux,direct64-ddr-window-info", per-device where we already
have set up dynamic dma windows. The current code, though, wasn't
initializing the size of this property and thus when we kexec'd, we
would find the property but read uninitialized memory resulting in
garbage ddw values for the kexec'd kernel and panics. Fix this by
setting the size at enable_ddw() time and ensuring that the size of the
found property is valid at dupe_ddw_if_kexec() time.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Milton Miller <miltonm@bga.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/pseries/iommu.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 6d5412a..019009b 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -730,16 +730,20 @@ static u64 dupe_ddw_if_kexec(struct pci_dev *dev, struct device_node *pdn)
pcidn = PCI_DN(dn);
direct64 = of_get_property(pdn, DIRECT64_PROPNAME, &len);
if (direct64) {
- window = kzalloc(sizeof(*window), GFP_KERNEL);
- if (!window) {
+ if (len < sizeof(struct dynamic_dma_window_prop)) {
remove_ddw(pdn);
} else {
- window->device = pdn;
- window->prop = direct64;
- spin_lock(&direct_window_list_lock);
- list_add(&window->list, &direct_window_list);
- spin_unlock(&direct_window_list_lock);
- dma_addr = direct64->dma_base;
+ window = kzalloc(sizeof(*window), GFP_KERNEL);
+ if (!window) {
+ remove_ddw(pdn);
+ } else {
+ window->device = pdn;
+ window->prop = direct64;
+ spin_lock(&direct_window_list_lock);
+ list_add(&window->list, &direct_window_list);
+ spin_unlock(&direct_window_list_lock);
+ dma_addr = direct64->dma_base;
+ }
}
}
@@ -833,7 +837,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
struct device_node *dn;
const u32 *uninitialized_var(ddr_avail);
struct direct_window *window;
- struct property *uninitialized_var(win64);
+ struct property *win64;
struct dynamic_dma_window_prop *ddwprop;
mutex_lock(&direct_window_init_mutex);
@@ -907,6 +911,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
}
win64->name = kstrdup(DIRECT64_PROPNAME, GFP_KERNEL);
win64->value = ddwprop = kmalloc(sizeof(*ddwprop), GFP_KERNEL);
+ win64->length = sizeof(*ddwprop);
if (!win64->name || !win64->value) {
dev_info(&dev->dev,
"couldn't allocate property name and value\n");
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Meador Inge @ 2011-05-06 23:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
Hollis Blanchard, Kushwaha Prabhakar-B32579,
openmcapi-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110506142937.77e7a10f@schlenkerla.am.freescale.net>
On 05/06/2011 02:29 PM, Scott Wood wrote:
> On Thu, 5 May 2011 16:41:29 -0500
>
> How can both OSes independently own registers 1 and 3 for alloction?
They can't. I just choose a horrible example. It does point to a serious
flaw (which you allude to later) in inferring free registers from send/receive:
in some cases one will have to arbitrarily add registers to send/receive masks
just to keep registers out of the free allocation pool. Your free-mask
proposal is better.
>> So any register mentioned in one of 'mpic-msgr-receive-mask' or
>> 'mpic-msgr-send-mask' is out of the running for general allocation.
>
> mpic-msgr-receive-mask has to match interrupts -- it's not intended to be
> an indication of usage, just that this partition is granted those
> interrupts.
>
> Plus, a dynamically allocated message register must be owned for both
> sending and receiving, so it doesn't make sense to separate it. I'd have
> an "mpic-msgr-free-mask" property, which must be a subset of
> "mpic-msgr-receive-mask". If the register is not in free-mask, it is
> reserved for a fixed purpose. If free-mask is absent, all registers in the
> receive-mask can be allocated.
>
> So the above example would be:
>
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb5 2>;
> mpic-msgr-receive-mask = <0x3>;
> mpic-msgr-free-mask = <0x2>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb1 2 0xb3 2>;
> mpic-msgr-receive-mask = <0xa>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb6 2 0xb7 2>;
> mpic-msgr-receive-mask = <0xc>;
> mpic-msgr-free-mask = <0x8>;
> };
>
> mpic-msgr-send-mask could be added as well, as a permissions mechanism to
> serve as extra protection against an improperly specified non-free message
> register -- especially if the interface is exposed to a less-trusted realm
> such as userspace, or if a hypervisor is reading the device tree to
> determine what to allow guests to do. In this case, just like
> mpic-msgr-receive-mask, it would list both free and non-free message
> registers that the partition can send to, and mpic-msgr-free-mask would be
> a subset of both the send and receive masks.
free-mask seems reasonable. Although, all of these masks are starting to get
rather complicated :-)
Anyway, I am going to cut a v2 patch without the dynamic allocation. All
of this is getting complicated without a public use case. I agree with your
previous suggestion that the dynamic allocation can be added as a part of the
patch set that actually uses it.
Thanks Scott.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* ibm_newemac driver hangs while using 10Mbps full-duplex
From: Jignesh Patel @ 2011-05-07 1:18 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
Hi,
We are using denx kernel 2.6.31.4 on ppc405ex with national
semiconductor DP83640 Ethernet transceiver. The kernel driver
(ibm_newemac) seems to hang after setting the ethernet phy to use 10Mbps
Full-duplex settings. The time after which the driver hangs is random.
I am predicting that it's the driver issue because we cannot send or
receive any packets even though ethernet phy detects a good link and
interface is up (eth0). Bringing the interface down and back up using
ifconfig command fixes the hang and normal packet transfer continues.
Also, some times during 10Mbps operation we see following warning from
the kernel:
eth0: link is up, 10 FDX
NETDEV WATCHDOG: eth0 (emac): transmit queue 0 timed out
------------[ cut here ]------------
Badness at net/sched/sch_generic.c:246
NIP: c02094a4 LR: c02094a4 CTR: c0175af0
REGS: c03a9d00 TRAP: 0700 Not tainted (2.6.31.4)
MSR: 00029030 <EE,ME,CE,IR,DR> CR: 24000024 XER: 20000000
TASK = c037f440[0] 'swapper' THREAD: c03a8000
GPR00: c02094a4 c03a9db0 c037f440 0000003f 00002631 ffffffff c0175a5c
00000036
GPR08: c03b1d40 c0380000 00002631 00004000 24000082 fffffeef 0ffed700
00800000
GPR16: 00000000 007fff00 c038138c c03b0000 c0300000 c03b0000 0000000a
c03a9e18
GPR24: c0380000 c03a8000 00000000 c03b5ec8 c03b0000 c0380000 00000000
cf012000
NIP [c02094a4] dev_watchdog+0x290/0x2a0
LR [c02094a4] dev_watchdog+0x290/0x2a0
Call Trace:
[c03a9db0] [c02094a4] dev_watchdog+0x290/0x2a0 (unreliable)
[c03a9e10] [c002d60c] run_timer_softirq+0xfc/0x1b8
[c03a9e50] [c00284a8] __do_softirq+0xb0/0x130
[c03a9e90] [c0004900] do_softirq+0x58/0x5c
[c03a9ea0] [c00282bc] irq_exit+0x48/0x58
[c03a9eb0] [c000bd94] timer_interrupt+0xa4/0x108
[c03a9ed0] [c000f618] ret_from_except+0x0/0x18
[c03a9f90] [c0007eb0] cpu_idle+0xd0/0xe0
[c03a9fb0] [c0002928] rest_init+0x5c/0x6c
[c03a9fc0] [c0355738] start_kernel+0x230/0x2b8
[c03a9ff0] [c0002254] start_here+0x44/0xb0
Instruction dump:
7c0903a6 4bffff78 38810008 7fe3fb78 38a00040 4bfebc4d 7c651b78 3c60c033
7fc6f378 7fe4fb78 3863e668 4be1a415 <0fe00000> 38000001 901cfa00
4bffff14
eth0: link is down
Does anyone have an understanding of how ibm_newemac is supposed to
behave in 10Mbps Full-duplex operation? any help to solve this issue is
really appreciated
Thanks!
-Jignesh
^ permalink raw reply
* [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: Stephen Boyd @ 2011-05-07 5:57 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, Chris Metcalf, sparclinux,
uclinux-dist-devel, linuxppc-dev, linux-arm-kernel
Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
Move it to lib/Kconfig.debug so each arch doesn't have to define
it. This obviously makes the option generic, but that's fine
because the config is already used in generic code.
It's not obvious to me that sysrq-P actually does anything
different with this option enabled, but I erred on the side of
caution by keeping the most inclusive wording.
Cc: linux-arch@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: uclinux-dist-devel@blackfin.uclinux.org
Cc: linux-m32r@ml.linux-m32r.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: user-mode-linux-devel@lists.sourceforge.net
Cc: x86@kernel.org
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
This is on top of mmotm's lib-conslidate-debug_per_cpu_maps patch.
arch/arm/Kconfig.debug | 7 -------
arch/blackfin/Kconfig.debug | 9 ---------
arch/m32r/Kconfig.debug | 9 ---------
arch/mips/Kconfig.debug | 9 ---------
arch/powerpc/Kconfig.debug | 9 ---------
arch/score/Kconfig.debug | 9 ---------
arch/sh/Kconfig.debug | 9 ---------
arch/sparc/Kconfig.debug | 9 ---------
arch/tile/Kconfig.debug | 9 ---------
arch/um/Kconfig.debug | 9 ---------
arch/unicore32/Kconfig.debug | 7 -------
arch/x86/Kconfig.debug | 9 ---------
lib/Kconfig.debug | 9 +++++++++
13 files changed, 9 insertions(+), 104 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 03d01d7..81cbe40 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -63,13 +63,6 @@ config DEBUG_USER
8 - SIGSEGV faults
16 - SIGBUS faults
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T output.
-
# These options are only for real kernel hackers who want to get their hands dirty.
config DEBUG_LL
bool "Kernel low-level debugging functions"
diff --git a/arch/blackfin/Kconfig.debug b/arch/blackfin/Kconfig.debug
index 2641731..19ccfb3 100644
--- a/arch/blackfin/Kconfig.debug
+++ b/arch/blackfin/Kconfig.debug
@@ -9,15 +9,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_VERBOSE
bool "Verbose fault messages"
default y
diff --git a/arch/m32r/Kconfig.debug b/arch/m32r/Kconfig.debug
index 2e1019d..bb1afc1 100644
--- a/arch/m32r/Kconfig.debug
+++ b/arch/m32r/Kconfig.debug
@@ -9,15 +9,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
depends on DEBUG_KERNEL && BROKEN
diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 5358f90..83ed00a 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -76,15 +76,6 @@ config DEBUG_STACKOVERFLOW
provides another way to check stack overflow happened on kernel mode
stack usually caused by nested interruption.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config SMTC_IDLE_HOOK_DEBUG
bool "Enable additional debug checks before going into CPU idle loop"
depends on DEBUG_KERNEL && MIPS_MT_SMTC
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 12a8d18..f862fc0 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -35,15 +35,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config HCALL_STATS
bool "Hypervisor call instrumentation"
depends on PPC_PSERIES && DEBUG_FS && TRACEPOINTS
diff --git a/arch/score/Kconfig.debug b/arch/score/Kconfig.debug
index 451ed54..a1f346d 100644
--- a/arch/score/Kconfig.debug
+++ b/arch/score/Kconfig.debug
@@ -16,15 +16,6 @@ config CMDLINE
other cases you can specify kernel args so that you don't have
to set them up in board prom initialization routines.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config RUNTIME_DEBUG
bool "Enable run-time debugging"
depends on DEBUG_KERNEL
diff --git a/arch/sh/Kconfig.debug b/arch/sh/Kconfig.debug
index 1553d56..c1d5a82 100644
--- a/arch/sh/Kconfig.debug
+++ b/arch/sh/Kconfig.debug
@@ -28,15 +28,6 @@ config STACK_DEBUG
every function call and will therefore incur a major
performance hit. Most users should say N.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
depends on DEBUG_KERNEL && (MMU || BROKEN) && !PAGE_SIZE_64KB
diff --git a/arch/sparc/Kconfig.debug b/arch/sparc/Kconfig.debug
index d9a795e..6db35fb 100644
--- a/arch/sparc/Kconfig.debug
+++ b/arch/sparc/Kconfig.debug
@@ -6,15 +6,6 @@ config TRACE_IRQFLAGS_SUPPORT
source "lib/Kconfig.debug"
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_DCFLUSH
bool "D-cache flush debugging"
depends on SPARC64 && DEBUG_KERNEL
diff --git a/arch/tile/Kconfig.debug b/arch/tile/Kconfig.debug
index 9bc161a..ddbfc33 100644
--- a/arch/tile/Kconfig.debug
+++ b/arch/tile/Kconfig.debug
@@ -21,15 +21,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_EXTRA_FLAGS
string "Additional compiler arguments when building with '-g'"
depends on DEBUG_INFO
diff --git a/arch/um/Kconfig.debug b/arch/um/Kconfig.debug
index 8fce5e5..34ac57f 100644
--- a/arch/um/Kconfig.debug
+++ b/arch/um/Kconfig.debug
@@ -28,13 +28,4 @@ config GCOV
If you're involved in UML kernel development and want to use gcov,
say Y. If you're unsure, say N.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- default N
- help
- Track the maximum kernel stack usage - this will look at each
- kernel stack at process exit and log it if it's the deepest
- stack seen so far.
-
- This option will slow down process creation and destruction somewhat.
endmenu
diff --git a/arch/unicore32/Kconfig.debug b/arch/unicore32/Kconfig.debug
index 3140151..ae2ec33 100644
--- a/arch/unicore32/Kconfig.debug
+++ b/arch/unicore32/Kconfig.debug
@@ -27,13 +27,6 @@ config EARLY_PRINTK
with klogd/syslogd or the X server. You should normally N here,
unless you want to debug such a crash.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T output.
-
# These options are only for real kernel hackers who want to get their hands dirty.
config DEBUG_LL
bool "Kernel low-level debugging functions"
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 1bf8839..c0f8a5c 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -66,15 +66,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- ---help---
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config X86_PTDUMP
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c0872ee..37fae12 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -654,6 +654,15 @@ config STACKTRACE
bool
depends on STACKTRACE_SUPPORT
+config DEBUG_STACK_USAGE
+ bool "Stack utilization instrumentation"
+ depends on DEBUG_KERNEL
+ help
+ Enables the display of the minimum amount of free stack which each
+ task has ever had available in the sysrq-T and sysrq-P debug output.
+
+ This option will slow down process creation somewhat.
+
config DEBUG_KOBJECT
bool "kobject debugging"
depends on DEBUG_KERNEL
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* RE: [RFC v2] virtio: add virtio-over-PCI driver
From: Kushwaha Prabhakar-B32579 @ 2011-05-07 5:59 UTC (permalink / raw)
To: Ira W. Snyder
Cc: Aggrwal Poonam-B10812, netdev@vger.kernel.org, Zang Roy-R61911,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Kalra Ashish-B00888, Gala Kumar-B11780, Gupta Maneesh-B18878,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110506160627.GB14069@ovro.caltech.edu>
Thanks Ira for your kind reply.
I will look for the mentioned pointers :)=20
Prabhakar=20
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Friday, May 06, 2011 9:36 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Zang Roy-R61911; Gala Kumar-B11780; Gupta Maneesh-B18878; Aggrwal
> Poonam-B10812; Kalra Ashish-B00888; linux-kernel@vger.kernel.org;
> linuxppc-dev@ozlabs.org; netdev@vger.kernel.org
> Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
>=20
> On Fri, May 06, 2011 at 12:00:34PM +0000, Kushwaha Prabhakar-B32579
> wrote:
> > Hi,
> >
> > I want to use this patch as base patch for "FSL 85xx platform" to
> support PCIe Agent.
> > The work looks to be little old now. So wanted to understand if any
> development has happened further on it.
> >
> > In case no, I would take this work forward for PCIe Agent.
> >
> > Any help/suggestions are most appreciated in this regard.
> >
>=20
> Hi Prabhakar,
>=20
> I use PCI agent mode on an mpc8349emds board. All of the important setup
> is done very early in the boot process, by U-Boot. Search the U-Boot
> source for CONFIG_PCISLAVE. I hunch that the setup needed for 85xx boards
> are similar.
>=20
> This virtio-over-PCI work is now very old. It was intended to provide a
> communication mechanism between a PCI Master and many PCI Agents
> (slaves).
> Dave Miller (networking maintainer) suggested to use virtio for this so
> that many different devices could be used. Such as:
> - network interface
> - serial port (for serial console)
>=20
> I am aware of other ongoing work in this area. Specifically, some ARM
> developers are working on a virtio API using their message registers.
> This work is much newer, and will be a much better starting place for
> you.
>=20
> Search the virtualization mailing list for:
> "[PATCH 00/02] virtio: Virtio platform driver"
>=20
> Here is a link to some of their code:
> http://www.spinics.net/lists/linux-sh/msg07188.html
>=20
> I am currently using a custom driver to provide a network device on my
> PCI agents. Searching the mailing list archives for "PCINet", you will
> find early versions of the driver. I am happy to provide you a current
> copy. It does not use virtio at all, and is unlikely to be accepted into
> mainline Linux.
>=20
> I am happy to provide any of my code if you think it would help you get
> started. Specifically, the current version of "PCINet" show how to use
> the DMA controller in order to get good network performance. I am also
> happy to help port code to 83xx, as well as test on 83xx. Please ask any
> questions you may have.
>=20
> I have people ask about this code about once every two months. There is
> plenty of interest in a mainline Linux solution to this problem. :) I
> will be moving to 85xx someday, and I hope there is an accepted mainline
> solution by then.
>=20
> I hope it helps,
> Ira
>=20
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Ira Snyder
> > Sent: Friday, 27 February, 2009 3:19 AM
> > To: Arnd Bergmann
> > Cc: linux-kernel@vger.kernel.org; Rusty Russell; Jan-Bernd Themann;
> > linuxppc-dev@ozlabs.org; netdev@vger.kernel.org
> > Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
> >
> > On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> > > On Thursday 26 February 2009, Ira Snyder wrote:
> > > > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> > > >
> > > > I think so too. I was just getting something working, and thought
> > > > it would be better to have it "out there" rather than be working
> > > > on it forever. I'll try to break things up as I have time.
> > >
> > > Ok, perfect!
> > >
> > > > For the "libraries", would you suggest breaking things into
> > > > seperate code files, and using EXPORT_SYMBOL_GPL()? I'm not very
> > > > familiar with doing that, I've mostly been writing code within the
> > > > existing device driver frameworks. Or do I need export symbol at
> all? I'm not sure...
> > >
> > > You have both options. When you list each file as a separate module
> > > in the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that
> > > get called by dependent modules, but this will work only in one way.
> > >
> > > You can also link multiple files together into one module, although
> > > it is less common to link a single source file into multiple modules.
> > >
> >
> > Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do
> that. If we decide it sucks later, we'll change it.
> >
> > > > I always thought you were supposed to use packed for data
> > > > structures that are external to the system. I purposely designed
> > > > the structures so they wouldn't need padding.
> > >
> > > That would only make sense for structures that are explicitly
> > > unaligned, like a register layout using
> > >
> > > struct my_registers {
> > > __le16 first;
> > > __le32 second __attribute__((packed));
> > > __le16 third;
> > > };
> > >
> > > Even here, I'd recommend listing the individual members as packed
> > > rather than the entire struct. Obviously if you layout the members
> > > in a sane way, you don't need either.
> > >
> >
> > Ok. I'll drop the __attribute__((packed)) and make sure there aren't
> problems. I don't suspect any, though.
> >
> > > > I mostly don't need it. In fact, the only place I'm using
> > > > registers not specific to the messaging unit is in the probe
> > > > routine, where I setup the 1GB window into host memory and setting
> > > > up access to the guest memory on the PCI bus.
> > >
> > > You could add the registers you need for this to the "reg" property
> > > of your device, to be mapped with of_iomap.
> > >
> > > If the registers for setting up this window don't logically fit into
> > > the same device as the one you already use, the cleanest solution
> > > would be to have another device just for this and then make a
> > > function call into that driver to set up the window.
> > >
> >
> > The registers are part of the board control registers. They don't fit
> at all in the message unit. Doing this in the bootloader seems like a
> logical place, but that would require any testers to flash a new U-Boot
> image into their mpc8349emds boards.
> >
> > The first set of access is used to set up a 1GB region in the memory
> map that accesses the host's memory. Any reads/writes to addresses
> 0x80000000-0xc0000000 actually hit the host's memory.
> >
> > The last access sets up PCI BAR1 to hit the memory from
> dma_alloc_coherent(). The bootloader already sets up the window as 16K,
> it just doesn't point it anywhere. Maybe this /should/ go into the
> bootloader. Like above, it would require testers to flash a new U-Boot
> image into their mpc8349emds boards.
> >
> > > > Now, I wouldn't need to access these registers at all if the
> > > > bootloader could handle it. I just don't know if it is possible to
> > > > have Linux not use some memory that the bootloader allocated,
> > > > other than with the mem=3DXXX trick, which I'm sure wouldn't be
> acceptable.
> > > > I've just used regular RAM so this is portable to my custom board
> > > > (mpc8349emds based) and a regular mpc8349emds. I didn't want to
> > > > change anything board specific.
> > > >
> > > > I would love to have the bootloader allocate (or reserve somewhere
> > > > in the memory map) 16K of RAM, and not be required to allocate it
> > > > with dma_alloc_coherent(). It would save me plenty of headaches.
> > >
> > > I believe you can do that through the "memory" devices in the device
> > > tree, by leaving out a small part of the description of main memory,
> > > at putting it into the "reg" property of your own device.
> > >
> >
> > I'll explore this option. I didn't even know you could do this. Is a
> driver that requires the trick acceptable for mainline inclusion? Just
> like setting up the 16K PCI window, this is very platform specific.
> >
> > This limits the guest driver to systems which are able to change
> Linux's view of their memory somehow. Maybe this isn't a problem.
> >
> > > > Code complexity only. Also, it was easier to write 80-char lines
> > > > with something like:
> > > >
> > > > vop_get_desc(vq, idx, &desc);
> > > > if (desc.flags & VOP_DESC_F_NEXT) {
> > > > /* do something */
> > > > }
> > > >
> > > > Instead of:
> > > > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > > > /* do something */
> > > > }
> > > >
> > > > Plus, I didn't have to remember how many bits were in each field.
> > > > I just thought it made everything simpler to understand.
> Suggestions?
> > >
> > > hmm, in this particular case, you could change the definition of
> > > VOP_DESC_F_NEXT to
> > >
> > > #define VOP_DESC_F_NEXT cpu_to_le16(1)
> > >
> > > and then do the code as the even simpler (source and object code
> > > wise)
> > >
> > > if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
> > >
> > > I'm not sure if you can do something along these lines for the other
> > > cases as well though.
> > >
> >
> > That's a good idea. It wouldn't fix the addresses, lengths, and next
> fields, though. I'll make the change and see how bad it is, then report
> back. It may not be so bad after all.
> >
> > > > I used 3 so they would would align to 1024 byte boundaries within
> > > > a 4K page. Then the layout was 16K on the bus, each 4K page is a
> > > > single virtio-device, and each 1K block is a single virtqueue. The
> > > > first 1K is for virtio-device status and feature bits, etc.
> > > >
> > > > Packing them differently isn't a problem. It was just easier to
> > > > code because setting up a window with the correct size is so
> > > > platform specific.
> > >
> > > Ok. I guess the important question is what part of the code makes
> > > this decision. Ideally, the virtio-net glue would instantiate the
> > > device with the right number of queues.
> > >
> >
> > Yeah, virtio doesn't work that way.
> >
> > The virtio drivers just call find_vq() with a different index for each
> queue they want to use. You have no way of knowing how many queues each
> virtio driver will want, unless you go read their source code.
> >
> > virtio-net currently uses 3 queues, but we only support the first two.
> > The third is optional (for now...), and non-symmetric.
> >
> > Thanks again,
> > Ira
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> >
> >
^ permalink raw reply
* Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: David Miller @ 2011-05-07 7:58 UTC (permalink / raw)
To: sboyd
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, cmetcalf, sparclinux,
uclinux-dist-devel, akpm, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304747831-2098-1-git-send-email-sboyd@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri, 6 May 2011 22:57:11 -0700
> Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
> Move it to lib/Kconfig.debug so each arch doesn't have to define
> it. This obviously makes the option generic, but that's fine
> because the config is already used in generic code.
>
> It's not obvious to me that sysrq-P actually does anything
> different with this option enabled, but I erred on the side of
> caution by keeping the most inclusive wording.
>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> Cc: linux-m32r@ml.linux-m32r.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Cc: user-mode-linux-devel@lists.sourceforge.net
> Cc: x86@kernel.org
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: richard -rw- weinberger @ 2011-05-07 9:34 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, Chris Metcalf, sparclinux,
uclinux-dist-devel, Andrew Morton, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304747831-2098-1-git-send-email-sboyd@codeaurora.org>
On Sat, May 7, 2011 at 7:57 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
> Move it to lib/Kconfig.debug so each arch doesn't have to define
> it. This obviously makes the option generic, but that's fine
> because the config is already used in generic code.
>
> It's not obvious to me that sysrq-P actually does anything
> different with this option enabled, but I erred on the side of
> caution by keeping the most inclusive wording.
>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> Cc: linux-m32r@ml.linux-m32r.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Cc: user-mode-linux-devel@lists.sourceforge.net
> Cc: x86@kernel.org
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
Acked-by: Richard Weinberger <richard@nod.at>
--
Thanks,
//richard
^ permalink raw reply
* Regarding P2020 in AMP mode
From: Prasanna Khanapur @ 2011-05-07 12:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
Hi,
I'm running P2020 in AMP mode, each core running its linux os.
Ethernet 1(@25000) and Ethernet 2(@26000) assigned to Core0 are working
fine.
I'm facing problems with Ethernet interface(@24000) assigned to Core1, its
not working.
I'm using dts file which were added by :
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/075594.html
Looks either there is some mistake in the dts file or my understanding is
wrong.
MDIO @24000 is defined in core0 dts file though the Ethernet is assigned to
Core 1.
DTS files :
http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <3 1>;
reg = <0x0>;
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <3 1>;
reg = <0x1>;
};
};
Also, MDIO for 25520 has wrong register value:
mdio@25520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
reg = <0x26520 0x20>;
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
Please correct me if I'm wrong. Has freescale released a working dts files
for P2020 in AMP mode ? as this seems to be not working.
Best Regards
Prasanna Khanapur.
[-- Attachment #2: Type: text/html, Size: 3019 bytes --]
^ permalink raw reply
* Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: Mike Frysinger @ 2011-05-07 13:57 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, Chris Metcalf, sparclinux,
uclinux-dist-devel, Andrew Morton, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304747831-2098-1-git-send-email-sboyd@codeaurora.org>
On Sat, May 7, 2011 at 01:57, Stephen Boyd wrote:
> Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
> Move it to lib/Kconfig.debug so each arch doesn't have to define
> it. This obviously makes the option generic, but that's fine
> because the config is already used in generic code.
>
> It's not obvious to me that sysrq-P actually does anything
> different with this option enabled, but I erred on the side of
> caution by keeping the most inclusive wording.
>
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> =C2=A0arch/blackfin/Kconfig.debug =C2=A0| =C2=A0 =C2=A09 ---------
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
* [PATCH 2/2] ppc64: Fix compiler warning in pgtable-ppc64.h [-Wunused-but-set-variable]
From: Stratos Psomadakis @ 2011-05-07 14:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1304777491-7947-1-git-send-email-psomas@cslab.ece.ntua.gr>
The variable 'old' is set but not used in the wrprotect functions in
arch/powerpc/include/asm/pgtable-ppc64.h, which can trigger a compiler warning.
Remove the variable, since it's not used anyway.
Signed-off-by: Stratos Psomadakis <psomas@ece.ntua.gr>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index 2b09cd5..0b27dba 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -257,21 +257,20 @@ static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- unsigned long old;
- if ((pte_val(*ptep) & _PAGE_RW) == 0)
- return;
- old = pte_update(mm, addr, ptep, _PAGE_RW, 0);
+ if ((pte_val(*ptep) & _PAGE_RW) == 0)
+ return;
+
+ pte_update(mm, addr, ptep, _PAGE_RW, 0);
}
static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
{
- unsigned long old;
-
if ((pte_val(*ptep) & _PAGE_RW) == 0)
return;
- old = pte_update(mm, addr, ptep, _PAGE_RW, 1);
+
+ pte_update(mm, addr, ptep, _PAGE_RW, 1);
}
/*
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] ppc/cleaup: Fix compiler warnings
From: Stratos Psomadakis @ 2011-05-07 14:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stratos Psomadakis, linux-kernel
Fix compiler warnings in ppc code, which can lead to build failure, if
CONFIG_PPC_WERROR is set (default).
arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++++++-------
arch/powerpc/kernel/Makefile | 2 +-
2 files changed, 7 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Stratos Psomadakis @ 2011-05-07 14:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1304777491-7947-1-git-send-email-psomas@cslab.ece.ntua.gr>
The trick used to bypass the thread_struct fpr array in order to access the
struct fpscr, in arch/powerpc/kernel/ptrace.c, can trigger an "array subscript
is above array bounds [-Werror=array-bounds]" warning.
Add -Wno-array-bounds to CFLAGS_ptrace.o, in arch/powerpc/kernel/Makefile to
slience this warning.
Signed-off-by: Stratos Psomadakis <psomas@ece.ntua.gr>
---
arch/powerpc/kernel/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3bb2a3e..92b1002 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
+CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' -Wno-array-bounds
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Andreas Schwab @ 2011-05-07 15:18 UTC (permalink / raw)
To: Stratos Psomadakis; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1304777491-7947-2-git-send-email-psomas@cslab.ece.ntua.gr>
Stratos Psomadakis <psomas@cslab.ece.ntua.gr> writes:
> +CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' -Wno-array-bounds
You need to check first whether the option is valid.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [RESEND PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Stratos Psomadakis @ 2011-05-07 15:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: schwab, linux-kernel
In-Reply-To: <m2oc3eh744.fsf@igel.home>
The trick used to bypass the thread_struct fpr array in order to access the
struct fpscr, in arch/powerpc/kernel/ptrace.c, can trigger an "array subscript
is above array bounds [-Werror=array-bounds]" warning.
Add -Wno-array-bounds to CFLAGS_ptrace.o, in arch/powerpc/kernel/Makefile to
slience this warning.
Signed-off-by: Stratos Psomadakis <psomas@ece.ntua.gr>
---
arch/powerpc/kernel/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3bb2a3e..92b1002 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
+CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' $(call cc-option, -Wno-array-bounds)
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
--
1.5.6.5
^ 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