* Re: [PATCH] cpm_uart: Initialize port.dev before it's used.
From: Kumar Gala @ 2009-04-06 14:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090403204844.GA20017@loki.buserror.net>
On Apr 3, 2009, at 3:48 PM, Scott Wood wrote:
> Previously, this caused NULL to sometimes be passed as a device
> to the DMA code. With recent DMA changes, that now causes a BUG().
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> This is a regression triggered by DMA changes; please apply for
> 2.6.30.
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/oprofile: dump_pmcs() is not used
From: Kumar Gala @ 2009-04-06 14:03 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, afleming
In-Reply-To: <95c5ebd63992c64ad0b644f1204362aaf5e35eeb.1239025478.git.michael@ellerman.id.au>
On Apr 6, 2009, at 8:45 AM, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/oprofile/op_model_fsl_emb.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> Or should we just remove it?
I'm for removing it if Andy doesn't have any issues. Someone can
always add it back as debugfs code in the future if they want it.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Print information about mapping hw irqs to virtual irqs
From: Wolfram Sang @ 2009-04-06 13:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <b804a7950247ceb99706be8cadb9bf5da5f73b09.1238983497.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
On Mon, Apr 06, 2009 at 12:05:02PM +1000, Michael Ellerman wrote:
> The irq remapping layer seems to cause some confusion when people
> see a different irq number in /proc/interrupts vs the one they
> request in their driver or DTS.
>
> So have the irq remapping layer print out a message when we map an
> irq. The message is only printed the first time the irq is mapped,
> and it's KERN_DEBUG so most people won't see it.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> arch/powerpc/kernel/irq.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5576147..8c1a496 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -672,11 +672,13 @@ unsigned int irq_create_mapping(struct irq_host *host,
> return NO_IRQ;
> }
> }
> - pr_debug("irq: -> obtained virq %d\n", virq);
>
> if (irq_setup_virq(host, virq, hwirq))
> return NO_IRQ;
>
> + printk(KERN_DEBUG "irq: irq %lu on host %s mapped to virtual irq %u\n",
> + hwirq, host->of_node ? host->of_node->full_name : "null", virq);
> +
> return virq;
> }
> EXPORT_SYMBOL_GPL(irq_create_mapping);
> --
> 1.6.1.2
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc/oprofile: dump_pmcs() is not used
From: Michael Ellerman @ 2009-04-06 13:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Kumar Gala, afleming
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/oprofile/op_model_fsl_emb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Or should we just remove it?
diff --git a/arch/powerpc/oprofile/op_model_fsl_emb.c b/arch/powerpc/oprofile/op_model_fsl_emb.c
index 91596f6..4abd466 100644
--- a/arch/powerpc/oprofile/op_model_fsl_emb.c
+++ b/arch/powerpc/oprofile/op_model_fsl_emb.c
@@ -228,6 +228,7 @@ static void pmc_stop_ctrs(void)
mtpmr(PMRN_PMGC0, pmgc0);
}
+#if 0
static void dump_pmcs(void)
{
printk("pmgc0: %x\n", mfpmr(PMRN_PMGC0));
@@ -241,6 +242,7 @@ static void dump_pmcs(void)
printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC3),
mfpmr(PMRN_PMLCA3), mfpmr(PMRN_PMLCB3));
}
+#endif
static int fsl_emb_cpu_setup(struct op_counter_config *ctr)
{
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Print information about mapping hw irqs to virtual irqs
From: Grant Likely @ 2009-04-06 13:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <b804a7950247ceb99706be8cadb9bf5da5f73b09.1238983497.git.michael@ellerman.id.au>
On Sun, Apr 5, 2009 at 8:05 PM, Michael Ellerman <michael@ellerman.id.au> w=
rote:
> The irq remapping layer seems to cause some confusion when people
> see a different irq number in /proc/interrupts vs the one they
> request in their driver or DTS.
>
> So have the irq remapping layer print out a message when we map an
> irq. The message is only printed the first time the irq is mapped,
> and it's KERN_DEBUG so most people won't see it.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0arch/powerpc/kernel/irq.c | =A0 =A04 +++-
> =A01 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5576147..8c1a496 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -672,11 +672,13 @@ unsigned int irq_create_mapping(struct irq_host *ho=
st,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NO_IRQ;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 pr_debug("irq: -> obtained virq %d\n", virq);
>
> =A0 =A0 =A0 =A0if (irq_setup_virq(host, virq, hwirq))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NO_IRQ;
>
> + =A0 =A0 =A0 printk(KERN_DEBUG "irq: irq %lu on host %s mapped to virtua=
l irq %u\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 hwirq, host->of_node ? host->of_node->full_=
name : "null", virq);
> +
> =A0 =A0 =A0 =A0return virq;
> =A0}
> =A0EXPORT_SYMBOL_GPL(irq_create_mapping);
> --
> 1.6.1.2
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: Print information about mapping hw irqs to virtual irqs
From: Michael Ellerman @ 2009-04-06 12:57 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20090406123001.GA3044@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]
On Mon, 2009-04-06 at 14:30 +0200, Wolfram Sang wrote:
> On Mon, Apr 06, 2009 at 12:05:02PM +1000, Michael Ellerman wrote:
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index 5576147..8c1a496 100644
> > --- a/arch/powerpc/kernel/irq.c
> > +++ b/arch/powerpc/kernel/irq.c
> > @@ -672,11 +672,13 @@ unsigned int irq_create_mapping(struct irq_host *host,
> > return NO_IRQ;
> > }
> > }
> > - pr_debug("irq: -> obtained virq %d\n", virq);
> >
> > if (irq_setup_virq(host, virq, hwirq))
> > return NO_IRQ;
> >
> > + printk(KERN_DEBUG "irq: irq %lu on host %s mapped to virtual irq %u\n",
> > + hwirq, host->of_node ? host->of_node->full_name : "null", virq);
> > +
>
> Are you replacing the pr_debug because you want to drop the
> DEBUG-dependency?
Yes. Several people have been confused by the value in /proc/interrupts
not matching what they expected - so I want there to be something in
dmesg by default that will hopefully make it clear to people what's
going on.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add configurable -Werror for arch/powerpc
From: Kumar Gala @ 2009-04-06 12:55 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <b5c96a65499b27f0505523fb5b9dfae98a585ed1.1238991483.git.michael@ellerman.id.au>
On Apr 5, 2009, at 11:18 PM, Michael Ellerman wrote:
> diff --git a/arch/powerpc/math-emu/Makefile b/arch/powerpc/math-emu/
> Makefile
> index 0c16ab9..dcb2148 100644
> --- a/arch/powerpc/math-emu/Makefile
> +++ b/arch/powerpc/math-emu/Makefile
> @@ -1,4 +1,8 @@
>
> +ifeq ($(CONFIG_PPC_WERROR),y)
> +EXTRA_CFLAGS += -Werror
> +endif
> +
> obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o fadds.o fcmpo.o
> fcmpu.o \
> fctiw.o fctiwz.o fdiv.o fdivs.o \
> fmadd.o fmadds.o fmsub.o fmsubs.o \
We explicitly build math-emu with -w to not see the warnings from it.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Keep track of emulated instructions
From: Geert Uytterhoeven @ 2009-04-06 12:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux/PPC Development
In-Reply-To: <3DA386C6-F26A-4929-8609-FE468DF01572@kernel.crashing.org>
On Fri, 3 Apr 2009, Kumar Gala wrote:
> On Apr 3, 2009, at 7:08 AM, Geert Uytterhoeven wrote:
> >Finally (after ca. 1.5 years), he're an updated version of my patch to keep
> >track of emulated instructions. In the light of Kumar's `Emulate enough of
> >SPE
> >instructions to make gcc happy' patch, he probably also wants to keep track
> >of
> >the actual runtime overhead.
> >
> >Changes since last version:
> > - arch/powerpc/kernel/sysfs.c is now compiled on ppc32, so we can provide
> > counters in sysfs on ppc32, too,
> > - WARN_EMULATED() is a no-op if CONFIG_SYSCTL is disabled,
> > - Add warnings for altivec,
> > - Add warnings for recently introduced emulation of vsx and isel
> > instructions.
>
> pretty cool. Do we think counters should be sysfs or debugfs?
What do you prefer?
On MIPS, unaligned exception handling control is in debugfs.
> Also it would be nice to be able to zero out the counters.
By writing to the individual counters, or by writing to a global `clear' file?
BTW, should the individual counters be readable by everybody? Currently they're
readable by root only.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] powerpc: Keep track of emulated instructions
From: Geert Uytterhoeven @ 2009-04-06 12:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux/PPC Development
In-Reply-To: <1238819848.9595.25.camel@localhost>
On Sat, 4 Apr 2009, Michael Ellerman wrote:
> On Fri, 2009-04-03 at 14:08 +0200, Geert Uytterhoeven wrote:
> > Finally (after ca. 1.5 years), he're an updated version of my patch to keep
> > track of emulated instructions. In the light of Kumar's `Emulate enough of SPE
> > instructions to make gcc happy' patch, he probably also wants to keep track of
> > the actual runtime overhead.
> >
> > Changes since last version:
> > - arch/powerpc/kernel/sysfs.c is now compiled on ppc32, so we can provide
> > counters in sysfs on ppc32, too,
> > - WARN_EMULATED() is a no-op if CONFIG_SYSCTL is disabled,
> > - Add warnings for altivec,
> > - Add warnings for recently introduced emulation of vsx and isel
> > instructions.
>
> You don't count instructions that fall through to the bottom of
> fix_alignment()?
Thanks! I add a generic unaligned counter for the fall through case.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] powerpc: Print information about mapping hw irqs to virtual irqs
From: Wolfram Sang @ 2009-04-06 12:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <b804a7950247ceb99706be8cadb9bf5da5f73b09.1238983497.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On Mon, Apr 06, 2009 at 12:05:02PM +1000, Michael Ellerman wrote:
> The irq remapping layer seems to cause some confusion when people
> see a different irq number in /proc/interrupts vs the one they
> request in their driver or DTS.
>
> So have the irq remapping layer print out a message when we map an
> irq. The message is only printed the first time the irq is mapped,
> and it's KERN_DEBUG so most people won't see it.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
I like the patch in general...
> ---
> arch/powerpc/kernel/irq.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5576147..8c1a496 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -672,11 +672,13 @@ unsigned int irq_create_mapping(struct irq_host *host,
> return NO_IRQ;
> }
> }
> - pr_debug("irq: -> obtained virq %d\n", virq);
>
> if (irq_setup_virq(host, virq, hwirq))
> return NO_IRQ;
>
> + printk(KERN_DEBUG "irq: irq %lu on host %s mapped to virtual irq %u\n",
> + hwirq, host->of_node ? host->of_node->full_name : "null", virq);
> +
Are you replacing the pr_debug because you want to drop the
DEBUG-dependency?
> return virq;
> }
> EXPORT_SYMBOL_GPL(irq_create_mapping);
> --
> 1.6.1.2
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* making cuImage with ELDK 4.2
From: Yigal Goldberger @ 2009-04-06 11:14 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm trying to make cuImage using kernel 2.6.24.2 .
The problem is I can't find a match between a dtc version and a dts file that will compile . I took dtc-v1.2.0 from several sources and tried to make them . They all fail with the same error :
CC dtc-lexer.lex.o
dtc-lexer.lex.c: In function `yylex':
dtc-lexer.lex.c:762: warning: label `find_rule' defined but not used
dtc-lexer.l: At top level:
dtc-lexer.lex.c:1870: warning: 'yy_flex_realloc' defined but not used
CC dtc-parser.tab.o
dtc-parser.tab.c: In function `yyparse':
dtc-parser.tab.c:1105: warning: implicit declaration of function `YYRHSLOC'
dtc-parser.tab.c:1105: error: request for member `first_line' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `first_column' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `last_line' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `last_column' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `file' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `last_line' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `last_column' in something not a structure or union
dtc-parser.tab.c:1105: error: request for member `file' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `first_line' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `first_column' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `last_line' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `last_column' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `file' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `last_line' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `last_column' in something not a structure or union
dtc-parser.tab.c:1625: error: request for member `file' in something not a structure or union
make: *** [dtc-parser.tab.o] Error 1
Does anyone have an Idea how to build the cuImage ?
If not , how to build the dtc ?
Thanks,
Yigal Goldberger.
^ permalink raw reply
* Re: [PATCH] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-04-06 7:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <fa686aa40904030704t5bd1debfk5a23aeed3ccae2ed@mail.gmail.com>
On Friday 03 April 2009, Grant Likely wrote:
> > =A0 =A0 =A0 =A0flash@f0000000,0 {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "cfi-flash";
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x00000000 0x02000000
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 0x02000000 0x02000000>;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bank-width =3D <2>;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0partition@0 {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0label =3D "test-part1";
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x04000000>;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> > =A0 =A0 =A0 =A0};
>
> Binding looks good to me. Add a variant of this blurb to
> Documentation/powerpc/booting-without-of.txt. For extra credit,
> factor out the MTD stuff and move it to
> Documentation/powerpc/dts-bindings/. Remember to cc: the
> devicetree-discuss@ozlabs.org list when you post the binding
> documentation.
OK, will do.
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > CC: Grant Likely <grant.likely@secretlab.ca>
> > ---
> > =A0drivers/mtd/maps/physmap_of.c | =A0174
> > ++++++++++++++++++++++++++++------------- 1 files changed, 120
> > insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/mtd/maps/physmap_of.c
> > b/drivers/mtd/maps/physmap_of.c index 5fcfec0..c1c2d08 100644
> > --- a/drivers/mtd/maps/physmap_of.c
> > +++ b/drivers/mtd/maps/physmap_of.c
> > @@ -20,13 +20,17 @@
> > =A0#include <linux/mtd/mtd.h>
> > =A0#include <linux/mtd/map.h>
> > =A0#include <linux/mtd/partitions.h>
> > +#include <linux/mtd/concat.h>
> > =A0#include <linux/of.h>
> > =A0#include <linux/of_platform.h>
> >
> > +#define MAX_RESOURCES =A0 =A0 =A0 =A0 =A04
> > +
>
> Why is this static?
Because I cloned it from physmap.c.
> Instead you could define:=20
>
> struct of_flash_list {
> struct mtd_info *mtd;
> struct map_info map;
> struct resource *res;
> };
>
> struct of_flash {
> struct mtd_info *cmtd;
> #ifdef CONFIG_MTD_PARTITIONS
> struct mtd_partition *parts;
> #endif
> int list_size; /* number of elements in of_flash_list */
> struct of_flash_list list[0];
> };
>
> Using a zero length array at the end of the structure allows you to do
> this after counting the number of reg tuples:
>
> f =3D kzalloc(sizeof(struct of_flash) + sizeof(struct
> of_flash_list)*num_chips);
>
> That eliminates a needless hard limit to the number of flash chips.
Good idea. Will update. Thanks.
> > =A0struct of_flash {
> > - =A0 =A0 =A0 struct mtd_info =A0 =A0 =A0 =A0 *mtd;
> > - =A0 =A0 =A0 struct map_info =A0 =A0 =A0 =A0 map;
> > - =A0 =A0 =A0 struct resource =A0 =A0 =A0 =A0 *res;
> > + =A0 =A0 =A0 struct mtd_info =A0 =A0 =A0 =A0 *mtd[MAX_RESOURCES];
> > + =A0 =A0 =A0 struct mtd_info =A0 =A0 =A0 =A0 *cmtd;
> > + =A0 =A0 =A0 struct map_info =A0 =A0 =A0 =A0 map[MAX_RESOURCES];
> > + =A0 =A0 =A0 struct resource =A0 =A0 =A0 =A0 *res[MAX_RESOURCES];
> > =A0#ifdef CONFIG_MTD_PARTITIONS
> > =A0 =A0 =A0 =A0struct mtd_partition =A0 =A0*parts;
> > =A0#endif
> > @@ -88,28 +92,40 @@ static int parse_obsolete_partitions(struct of_devi=
ce
> > *dev, static int of_flash_remove(struct of_device *dev)
> > =A0{
> > =A0 =A0 =A0 =A0struct of_flash *info;
> > + =A0 =A0 =A0 int i;
> >
> > =A0 =A0 =A0 =A0info =3D dev_get_drvdata(&dev->dev);
> > =A0 =A0 =A0 =A0if (!info)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;
> > =A0 =A0 =A0 =A0dev_set_drvdata(&dev->dev, NULL);
> >
> > - =A0 =A0 =A0 if (info->mtd) {
> > +#ifdef CONFIG_MTD_CONCAT
> > + =A0 =A0 =A0 if (info->cmtd !=3D info->mtd[0]) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_device(info->cmtd);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtd_concat_destroy(info->cmtd);
> > + =A0 =A0 =A0 }
> > +#endif
> > +
> > + =A0 =A0 =A0 if (info->cmtd) {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (OF_FLASH_PARTS(info)) {
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_partitions(info->=
mtd);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_partitions(info->=
cmtd);
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kfree(OF_FLASH_PARTS(inf=
o));
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else {
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_device(info->mtd);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_device(info->cmtd=
);
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 map_destroy(info->mtd);
> > =A0 =A0 =A0 =A0}
> >
> > - =A0 =A0 =A0 if (info->map.virt)
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 iounmap(info->map.virt);
> > + =A0 =A0 =A0 for (i =3D 0; i < MAX_RESOURCES; i++) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->mtd[i])
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 map_destroy(info->mtd[i]);
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->map[i].virt)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iounmap(info->map[i].virt=
);
> >
> > - =A0 =A0 =A0 if (info->res) {
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 release_resource(info->res);
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 kfree(info->res);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->res[i]) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 release_resource(info->re=
s[i]);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kfree(info->res[i]);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> > =A0 =A0 =A0 =A0}
> >
> > =A0 =A0 =A0 =A0return 0;
> > @@ -164,15 +180,25 @@ static int __devinit of_flash_probe(struct
> > of_device *dev, const char *probe_type =3D match->data;
> > =A0 =A0 =A0 =A0const u32 *width;
> > =A0 =A0 =A0 =A0int err;
> > -
> > - =A0 =A0 =A0 err =3D -ENXIO;
> > - =A0 =A0 =A0 if (of_address_to_resource(dp, 0, &res)) {
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Can't get IO address =
from device
> > tree\n"); + =A0 =A0 =A0 int i;
> > + =A0 =A0 =A0 int count;
> > + =A0 =A0 =A0 const u32 *p;
> > + =A0 =A0 =A0 int devices_found =3D 0;
> > +
> > + =A0 =A0 =A0 /*
> > + =A0 =A0 =A0 =A0* Get number of "reg" tuples. Scan for MTD devices on =
area's
> > + =A0 =A0 =A0 =A0* described by each "reg" region. This makes it possib=
le
> > (including + =A0 =A0 =A0 =A0* the concat support) to support the Intel =
P30
> > 48F4400 chips which + =A0 =A0 =A0 =A0* consists internally of 2 non-ide=
ntical NOR
> > chips on one die. + =A0 =A0 =A0 =A0*/
> > + =A0 =A0 =A0 p =3D of_get_property(dp, "reg", &count);
> > + =A0 =A0 =A0 if (count % 12 !=3D 0) {
>
> This doesn't work. You cannot know the size of each reg tuple until
> #address-cells/#size-cells is parsed for the parent node. It won't
> always be 12. Use of_n_addr_cells() + of_n_size_cells() to determine
> size of each tuple.
OK, I'll change it in the next patch version.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Geert Uytterhoeven @ 2009-04-06 7:34 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Cell Broadband Engine OSS Development,
Arnd Bergmann
In-Reply-To: <18905.40197.939239.295279@drongo.ozlabs.ibm.com>
On Mon, 6 Apr 2009, Paul Mackerras wrote:
> Arnd Bergmann writes:
> > On Thursday 02 April 2009, Geert Uytterhoeven wrote:
> > > | arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to `pci_io_base'
> > >
> > > due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
> > > shouldn't be built when CONFIG_PCI=n?
> >
> > Right, the I/O workarounds are specific to the spider PCI implementation,
> > so there is no point in having them without PCI support.
> >
> > > As I don't have the hardware to test anyway, I'll give up.
> >
> > BenK, can you try Geert's patch on QPACE?
>
> So is that patch good or not? If it's good, could someone please
> repost it with a proper patch description etc.?
It's not good, as it still causes the link error above.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] Fix ptrace compat wrapper for fpu register access
From: Michael Neuling @ 2009-04-06 6:59 UTC (permalink / raw)
To: Andreas Schwab, linuxppc-dev; +Cc: paulus
In-Reply-To: <8394.1239000531@neuling.org>
In message <8394.1239000531@neuling.org> you wrote:
> > > >> @@ -263,7 +263,9 @@ long compat_arch_ptrace(struct task_stru
> > > >> ret = ptrace_put_reg(child, numReg, freg);
> > > >> } else {
> > > >> flush_fp_to_thread(child);
> > > >> - ((unsigned int *)child->thread.regs)[index] = d
> ata;
> > > >> + ((unsigned int *)child->thread.fpr)
> > > >> + [TS_FPRWIDTH * (numReg - PT_FPR0) * 2 +
> > > >> + index % 2] = data;
> > > >
> > > > I think the indexing here should be the same as PEEKUSR_3264. This
> > > > looks better but all this magic indexing makes me want to vomit.
> > >
> > > How about this instead:
> > >
> > > @@ -241,6 +241,7 @@ long compat_arch_ptrace(struct task_stru
> > > case PPC_PTRACE_POKEUSR_3264: {
> > > u32 index;
> > > u32 numReg;
> > > + u32 *tmp;
> > >
> > > ret = -EIO;
> > > /* Determine which register the user wants */
> > > @@ -263,7 +264,8 @@ long compat_arch_ptrace(struct task_stru
> > > ret = ptrace_put_reg(child, numReg, freg);
> > > } else {
> > > flush_fp_to_thread(child);
> > > - ((unsigned int *)child->thread.regs)[index] = data;
> > > + tmp = (u32 *)child->thread.fpr[numReg - PT_FPR0];
> > > + tmp[index % 2] = data;
> >
> > I do like this approach better (two arrays) but there is no accounting
> > for TS_WIDTH, so I'm not sure it works.
>
> Ok, here's another stab at trying to fix this and clean it up.
... and now without the c++ style comments...
Mikey
powerpc: Fix ptrace compat wrapper for fpu register access
The ptrace compat wrapper mishandles access to the fpu registers. The
PTRACE_PEEKUSR and PTRACE_POKEUSR requests miscalculate the index into
the fpr array due to the broken FPINDEX macro. The
PPC_PTRACE_PEEKUSR_3264 request needs to use the same formula that the
native ptrace interface uses when operating on the register number (as
opposed to the 4-byte offset). The PPC_PTRACE_POKEUSR_3264 request
didn't take TS_FPRWIDTH into account.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/ptrace32.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
@@ -67,7 +67,8 @@ static long compat_ptrace_old(struct tas
/* Macros to workout the correct index for the FPR in the thread struct */
#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
#define FPRHALF(i) (((i) - PT_FPR0) & 1)
-#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) + FPRHALF(i)
+#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i)
+#define FPRINDEX_3264(i) (TS_FPRWIDTH * ((i) - PT_FPR0))
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
@@ -168,8 +169,9 @@ long compat_arch_ptrace(struct task_stru
CHECK_FULL_REGS(child->thread.regs);
if (numReg >= PT_FPR0) {
flush_fp_to_thread(child);
- tmp = ((unsigned long int *)child->thread.fpr)
- [FPRINDEX(numReg)];
+ /* get 64 bit FPR */
+ tmp = ((u64 *)child->thread.fpr)
+ [FPRINDEX_3264(numReg)];
} else { /* register within PT_REGS struct */
tmp = ptrace_get_reg(child, numReg);
}
@@ -262,8 +264,13 @@ long compat_arch_ptrace(struct task_stru
freg = (freg & 0xfffffffful) | (data << 32);
ret = ptrace_put_reg(child, numReg, freg);
} else {
+ u64 *tmp;
flush_fp_to_thread(child);
- ((unsigned int *)child->thread.regs)[index] = data;
+ /* get 64 bit FPR ... */
+ tmp = &(((u64 *)child->thread.fpr)
+ [FPRINDEX_3264(numReg)]);
+ /* ... write the 32 bit part we want */
+ ((u32 *)tmp)[index % 2] = data;
ret = 0;
}
break;
^ permalink raw reply
* Re: [PATCH] Fix ptrace compat wrapper for fpu register access
From: Michael Neuling @ 2009-04-06 6:48 UTC (permalink / raw)
To: Andreas Schwab, linuxppc-dev; +Cc: paulus
In-Reply-To: <12572.1238453639@neuling.org>
> > >> @@ -263,7 +263,9 @@ long compat_arch_ptrace(struct task_stru
> > >> ret = ptrace_put_reg(child, numReg, freg);
> > >> } else {
> > >> flush_fp_to_thread(child);
> > >> - ((unsigned int *)child->thread.regs)[index] = d
ata;
> > >> + ((unsigned int *)child->thread.fpr)
> > >> + [TS_FPRWIDTH * (numReg - PT_FPR0) * 2 +
> > >> + index % 2] = data;
> > >
> > > I think the indexing here should be the same as PEEKUSR_3264. This
> > > looks better but all this magic indexing makes me want to vomit.
> >
> > How about this instead:
> >
> > @@ -241,6 +241,7 @@ long compat_arch_ptrace(struct task_stru
> > case PPC_PTRACE_POKEUSR_3264: {
> > u32 index;
> > u32 numReg;
> > + u32 *tmp;
> >
> > ret = -EIO;
> > /* Determine which register the user wants */
> > @@ -263,7 +264,8 @@ long compat_arch_ptrace(struct task_stru
> > ret = ptrace_put_reg(child, numReg, freg);
> > } else {
> > flush_fp_to_thread(child);
> > - ((unsigned int *)child->thread.regs)[index] = data;
> > + tmp = (u32 *)child->thread.fpr[numReg - PT_FPR0];
> > + tmp[index % 2] = data;
>
> I do like this approach better (two arrays) but there is no accounting
> for TS_WIDTH, so I'm not sure it works.
Ok, here's another stab at trying to fix this and clean it up.
Mikey
powerpc: Fix ptrace compat wrapper for fpu register access
The ptrace compat wrapper mishandles access to the fpu registers. The
PTRACE_PEEKUSR and PTRACE_POKEUSR requests miscalculate the index into
the fpr array due to the broken FPINDEX macro. The
PPC_PTRACE_PEEKUSR_3264 request needs to use the same formula that the
native ptrace interface uses when operating on the register number (as
opposed to the 4-byte offset). The PPC_PTRACE_POKEUSR_3264 request
didn't take TS_FPRWIDTH into account.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/ptrace32.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c
@@ -67,7 +67,8 @@ static long compat_ptrace_old(struct tas
/* Macros to workout the correct index for the FPR in the thread struct */
#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
#define FPRHALF(i) (((i) - PT_FPR0) & 1)
-#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) + FPRHALF(i)
+#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i)
+#define FPRINDEX_3264(i) (TS_FPRWIDTH * ((i) - PT_FPR0))
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
@@ -168,8 +169,9 @@ long compat_arch_ptrace(struct task_stru
CHECK_FULL_REGS(child->thread.regs);
if (numReg >= PT_FPR0) {
flush_fp_to_thread(child);
- tmp = ((unsigned long int *)child->thread.fpr)
- [FPRINDEX(numReg)];
+ // get 64 bit FPR
+ tmp = ((u64 *)child->thread.fpr)
+ [FPRINDEX_3264(numReg)];
} else { /* register within PT_REGS struct */
tmp = ptrace_get_reg(child, numReg);
}
@@ -262,8 +264,13 @@ long compat_arch_ptrace(struct task_stru
freg = (freg & 0xfffffffful) | (data << 32);
ret = ptrace_put_reg(child, numReg, freg);
} else {
+ u64 *tmp;
flush_fp_to_thread(child);
- ((unsigned int *)child->thread.regs)[index] = data;
+ // get 64 bit FPR ...
+ tmp = &(((u64 *)child->thread.fpr)
+ [FPRINDEX_3264(numReg)]);
+ // ... write the 32 bit part we want
+ ((u32 *)tmp)[index % 2] = data;
ret = 0;
}
break;
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Paul Mackerras @ 2009-04-06 6:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, linuxppc-dev,
Cell Broadband Engine OSS Development
In-Reply-To: <200904021515.12082.arnd@arndb.de>
Arnd Bergmann writes:
> On Thursday 02 April 2009, Geert Uytterhoeven wrote:
> > | arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to `pci_io_base'
> >
> > due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
> > shouldn't be built when CONFIG_PCI=n?
>
> Right, the I/O workarounds are specific to the spider PCI implementation,
> so there is no point in having them without PCI support.
>
> > As I don't have the hardware to test anyway, I'll give up.
>
> BenK, can you try Geert's patch on QPACE?
So is that patch good or not? If it's good, could someone please
repost it with a proper patch description etc.?
Thanks,
Paul.
^ permalink raw reply
* [PATCH] powerpc: Add configurable -Werror for arch/powerpc
From: Michael Ellerman @ 2009-04-06 4:18 UTC (permalink / raw)
To: linuxppc-dev
Add an option, on by default, to build all code under arch/powerpc with
-Werror, which causes gcc to treat warnings as errors.
The intention is to make it harder for people to inadvertantly introduce
errors in the arch/powerpc code. It needs to be configurable so that
if a warning is introduced, people can easily work around it while it's
being fixed.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig.debug | 8 ++++++++
arch/powerpc/kernel/Makefile | 4 ++++
arch/powerpc/kvm/Makefile | 4 ++++
arch/powerpc/lib/Makefile | 4 ++++
arch/powerpc/math-emu/Makefile | 4 ++++
arch/powerpc/mm/Makefile | 4 ++++
arch/powerpc/oprofile/Makefile | 4 ++++
arch/powerpc/platforms/Makefile | 4 ++++
arch/powerpc/sysdev/Makefile | 4 ++++
arch/powerpc/xmon/Makefile | 4 ++++
10 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index a1098e2..58d5c22 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -2,6 +2,14 @@ menu "Kernel hacking"
source "lib/Kconfig.debug"
+config PPC_WERROR
+ bool "Build arch/powerpc code with -Werror"
+ default y
+ help
+ This option tells the compiler to build all of the code under
+ arch/powerpc with the -Werror flag, which means all warnings
+ are treated as errors.
+
config PRINT_STACK_DEPTH
int "Stack depth to print" if DEBUG_KERNEL
default 64
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 71901fb..b11ef4e 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -12,6 +12,10 @@ CFLAGS_prom_init.o += -fPIC
CFLAGS_btext.o += -fPIC
endif
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
ifdef CONFIG_FUNCTION_TRACER
# Do not trace early boot code
CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 4b2df66..51d2337 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -2,6 +2,10 @@
# Makefile for Kernel-based Virtual Machine module
#
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
EXTRA_CFLAGS += -Ivirt/kvm -Iarch/powerpc/kvm
common-objs-y = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 8db3527..536db60 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -2,6 +2,10 @@
# Makefile for ppc-specific library files..
#
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
diff --git a/arch/powerpc/math-emu/Makefile b/arch/powerpc/math-emu/Makefile
index 0c16ab9..dcb2148 100644
--- a/arch/powerpc/math-emu/Makefile
+++ b/arch/powerpc/math-emu/Makefile
@@ -1,4 +1,8 @@
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o fadds.o fcmpo.o fcmpu.o \
fctiw.o fctiwz.o fdiv.o fdivs.o \
fmadd.o fmadds.o fmsub.o fmsubs.o \
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 17290bc..4880a16 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -2,6 +2,10 @@
# Makefile for the linux ppc-specific parts of the memory manager.
#
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
diff --git a/arch/powerpc/oprofile/Makefile b/arch/powerpc/oprofile/Makefile
index 2ef6b0d..e607c74 100644
--- a/arch/powerpc/oprofile/Makefile
+++ b/arch/powerpc/oprofile/Makefile
@@ -1,3 +1,7 @@
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
diff --git a/arch/powerpc/platforms/Makefile b/arch/powerpc/platforms/Makefile
index f741919..b18b921 100644
--- a/arch/powerpc/platforms/Makefile
+++ b/arch/powerpc/platforms/Makefile
@@ -1,4 +1,8 @@
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
obj-$(CONFIG_FSL_ULI1575) += fsl_uli1575.o
obj-$(CONFIG_PPC_PMAC) += powermac/
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..508c305 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -1,3 +1,7 @@
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index 9cb03b7..3348822 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -1,5 +1,9 @@
# Makefile for xmon
+ifeq ($(CONFIG_PPC_WERROR),y)
+EXTRA_CFLAGS += -Werror
+endif
+
ifdef CONFIG_PPC64
EXTRA_CFLAGS += -mno-minimal-toc
endif
--
1.6.1.2
^ permalink raw reply related
* [PATCH] powerpc: Print information about mapping hw irqs to virtual irqs
From: Michael Ellerman @ 2009-04-06 2:05 UTC (permalink / raw)
To: linuxppc-dev
The irq remapping layer seems to cause some confusion when people
see a different irq number in /proc/interrupts vs the one they
request in their driver or DTS.
So have the irq remapping layer print out a message when we map an
irq. The message is only printed the first time the irq is mapped,
and it's KERN_DEBUG so most people won't see it.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5576147..8c1a496 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -672,11 +672,13 @@ unsigned int irq_create_mapping(struct irq_host *host,
return NO_IRQ;
}
}
- pr_debug("irq: -> obtained virq %d\n", virq);
if (irq_setup_virq(host, virq, hwirq))
return NO_IRQ;
+ printk(KERN_DEBUG "irq: irq %lu on host %s mapped to virtual irq %u\n",
+ hwirq, host->of_node ? host->of_node->full_name : "null", virq);
+
return virq;
}
EXPORT_SYMBOL_GPL(irq_create_mapping);
--
1.6.1.2
^ permalink raw reply related
* Re: CONFIG_PREEMPT and High Resolution Timers problem
From: Tony Breeds @ 2009-04-06 0:24 UTC (permalink / raw)
To: Vijay Nikam; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <f234e2140904040516w7db57a5fsfaa6a8674d707bdd@mail.gmail.com>
On Sat, Apr 04, 2009 at 05:46:38PM +0530, Vijay Nikam wrote:
Hello Vijay.
> Because while searching some information regarding this I learned
> about High-Res Timers. In linux-2.6.20 x86 has this feature enabled
> rather you can enable it but not for powerpc arch, Right ? ? ? If yes
> then is there any way to add CONFIG_HIGH_RES_TIMERS feature to
> linux-2.6.20, any patch available ? ? ? otherwise what could be the
> option ? ? ?
Getting high res times wrkign in 2.6.20 will be painful, the easyest option to
get HR timers wouyld be to grab 2.6.24 (or newer). Of course that may cause
other pain for you.
Yours Tony
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Sam Ravnborg @ 2009-04-05 21:07 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Ingo Molnar
In-Reply-To: <20090320164429.GA28037@oksana.dev.rtsoft.ru>
On Fri, Mar 20, 2009 at 07:44:29PM +0300, Anton Vorontsov wrote:
> This patch introduces ARCH_HAS_NORMAL_FRAME_POINTERS Kconfig symbol.
> When defined, the top level Makefile won't add -fno-omit-frame-pointer
> cflag (the flag is useless in PowerPC kernels, and also makes gcc
> generate wrong code).
>
> Also move ARCH_WANT_FRAME_POINTERS's help text.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Hi Anton - sorry for the late feedback.
1) The preferred naming for variables that are supposed to be selcted
are "HAVE_xxxx".
So in this case it would be:
HAVE_NORMAL_FRAME_POINTER
2) I do not really understand the interpretation of normal in this case,
can it be more specific?
Looking at your patch then if specified we use "-fomit-frame-pointer"
in the case where it is set.
So I read it like:
If arch has normal framepointer then we omit them - strange?
3) Indent in top-level MAkefile for new stuff is generally 8 spaces.
Do NOT use tabs as this would confuse make and rener assignmnet non-functional.
4) The individual "HAVE_* members should be sorted alphabetically in the arch
Kconfig file (which they seldomly are :-( )
Sam
> ---
> Makefile | 7 +++++--
> arch/powerpc/Kconfig | 1 +
> lib/Kconfig.debug | 16 ++++++++++------
> 3 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 46c04c5..bf41b05 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -538,9 +538,12 @@ KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
> endif
>
> ifdef CONFIG_FRAME_POINTER
> -KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
> + KBUILD_CFLAGS += -fno-optimize-sibling-calls
> + ifndef ARCH_HAS_NORMAL_FRAME_POINTERS
> + KBUILD_CFLAGS += -fno-omit-frame-pointer
> + endif
> else
> -KBUILD_CFLAGS += -fomit-frame-pointer
> + KBUILD_CFLAGS += -fomit-frame-pointer
> endif
>
> ifdef CONFIG_DEBUG_INFO
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 97f9a64..4587e66 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -113,6 +113,7 @@ config PPC
> select HAVE_FUNCTION_TRACER
> select HAVE_FUNCTION_GRAPH_TRACER
> select ARCH_WANT_OPTIONAL_GPIOLIB
> + select ARCH_HAS_NORMAL_FRAME_POINTERS
> select HAVE_IDE
> select HAVE_IOREMAP_PROT
> select HAVE_EFFICIENT_UNALIGNED_ACCESS
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 4b63b6b..fc8cd1f 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -661,20 +661,24 @@ config DEBUG_NOTIFIERS
> This is a relatively cheap check but if you care about maximum
> performance, say N.
>
> -#
> -# Select this config option from the architecture Kconfig, if it
> -# it is preferred to always offer frame pointers as a config
> -# option on the architecture (regardless of KERNEL_DEBUG):
> -#
> config ARCH_WANT_FRAME_POINTERS
> bool
> help
> + Select this config option from the architecture Kconfig, if it
> + it is preferred to always offer frame pointers as a config
> + option on the architecture (regardless of KERNEL_DEBUG).
> +
> +config ARCH_HAS_NORMAL_FRAME_POINTERS
> + bool
> + help
> + Architectures should select this symbol if their ABI implies
> + having a frame pointer.
>
> config FRAME_POINTER
> bool "Compile the kernel with frame pointers"
> depends on DEBUG_KERNEL && \
> (CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \
> - AVR32 || SUPERH || BLACKFIN || MN10300) || \
> + AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \
> ARCH_WANT_FRAME_POINTERS
> default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
> help
> --
> 1.5.6.5
>
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines
From: Timur Tabi @ 2009-04-05 19:18 UTC (permalink / raw)
To: Kumar Gala
Cc: Becky Bruce, alsa-devel, Mark Brown, linuxppc-dev, Liam Girdwood
In-Reply-To: <85829FCA-D181-4992-9889-640B3329D023@kernel.crashing.org>
On Sun, Apr 5, 2009 at 9:59 AM, Kumar Gala <galak@kernel.crashing.org> wrot=
e:
> No, I think we should just fix drivers. =A0There aren't that many SoC dri=
vers
> and once they are fixed this will resolve itself.
I agree. The only reason I passed NULL when I wrote the drivers was
because I was too lazy to figure out what the right dev pointer was.
ASoC is kinda screwy in that many fields are not initialized when you
think they should be. More than once I passed a pointer to a wrong
object without realizing it, even though the code worked.
I'll check out these two patches on Monday.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Hugh Dickins @ 2009-04-05 18:51 UTC (permalink / raw)
To: Chris Friesen; +Cc: peterz, linux-kernel, linuxppc-dev, akpm, KAMEZAWA Hiroyuki
In-Reply-To: <49D523FB.2020504@nortel.com>
On Thu, 2 Apr 2009, Chris Friesen wrote:
> Hugh Dickins wrote:
>
> > This is a cosmetic matter, not worth more than a couple of lines of
> > code: I suggested masking off the high bits in the display, but when
> > KAMEZAWA-san suggested just showing 0, it was hard to argue against
> > his brutal simplicity.
>
> <snip>
>
> > Consider this change a fix: it used to show 00000000 before 2.6.7.
> >
> > See http://lkml.org/lkml/2009/1/13/331 for one of the threads
> > on the subject - but you've not tempted me to reopen it!
>
> Okay, fair enough. I'll change my code to deal with it. Thanks for the
> explanation.
Oh, I thought you were arguing hypotheticals. This is more serious,
that you have some userspace code which depended on the 2.6.8-2.6.29
way of filling that field, and now we're about to break it.
Please, would you share what you were doing with the vm_pgoff of an
anonymous area? I won't pretend: I am indeed hoping to show that
what you were doing before was already broken, so that we can safely
go ahead and break it some more!
Hugh
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines
From: Kumar Gala @ 2009-04-05 14:59 UTC (permalink / raw)
To: Grant Likely
Cc: Becky Bruce, alsa-devel, Mark Brown, linuxppc-dev, Timur Tabi,
Liam Girdwood
In-Reply-To: <fa686aa40904050739g219a9143v7bbc8cd673e52f4e@mail.gmail.com>
On Apr 5, 2009, at 9:39 AM, Grant Likely wrote:
> On Sun, Apr 5, 2009 at 2:52 AM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
>> On Sat, Apr 04, 2009 at 11:59:39PM -0600, Grant Likely wrote:
>>> Becky & Kumar,
>>>
>>> Considering these fixups, would it be advisable for the dma
>>> functions
>>> to climb up the dev->parent linkage when dma_ops are NULL?
>>
>> pcm->dev->parent doesn't point to the proper device, so
>> this won't work.
>
> What does it point to then? IIUC, following the ->parent links should
> eventually get to a struct device that represents the platform or
> of_platform device for purposes of power management.
>
> BTW, I'm not NAKing your patch. The patch looks fine to me.
>
> g.
No, I think we should just fix drivers. There aren't that many SoC
drivers and once they are fixed this will resolve itself.
- k
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines
From: Grant Likely @ 2009-04-05 14:39 UTC (permalink / raw)
To: avorontsov
Cc: Becky Bruce, alsa-devel, Mark Brown, linuxppc-dev, Timur Tabi,
Liam Girdwood
In-Reply-To: <20090405085243.GA16005@oksana.dev.rtsoft.ru>
On Sun, Apr 5, 2009 at 2:52 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Sat, Apr 04, 2009 at 11:59:39PM -0600, Grant Likely wrote:
>> Becky & Kumar,
>>
>> Considering these fixups, would it be advisable for the dma functions
>> to climb up the dev->parent linkage when dma_ops are NULL?
>
> pcm->dev->parent doesn't point to the proper device, so
> this won't work.
What does it point to then? IIUC, following the ->parent links should
eventually get to a struct device that represents the platform or
of_platform device for purposes of power management.
BTW, I'm not NAKing your patch. The patch looks fine to me.
g.
>
>> On Sat, Apr 4, 2009 at 12:33 PM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>> > The driver should pass a device that specifies internal DMA ops, but
>> > substream->pcm is just a logical device, and thus doesn't have arch-
>> > specific dma callbacks, therefore following bug appears:
>> >
>> > =A0Freescale Synchronous Serial Interface (SSI) ASoC Driver
>> > =A0------------[ cut here ]------------
>> > =A0kernel BUG at arch/powerpc/include/asm/dma-mapping.h:237!
>> > =A0Oops: Exception in kernel mode, sig: 5 [#1]
>> > =A0...
>> > =A0NIP [c02259c4] snd_malloc_dev_pages+0x58/0xac
>> > =A0LR [c0225c74] snd_dma_alloc_pages+0xf8/0x108
>> > =A0Call Trace:
>> > =A0[df02bde0] [df02be2c] 0xdf02be2c (unreliable)
>> > =A0[df02bdf0] [c0225c74] snd_dma_alloc_pages+0xf8/0x108
>> > =A0[df02be10] [c023a100] fsl_dma_new+0x68/0x124
>> > =A0[df02be20] [c02342ac] soc_new_pcm+0x1bc/0x234
>> > =A0[df02bea0] [c02343dc] snd_soc_new_pcms+0xb8/0x148
>> > =A0[df02bed0] [c023824c] cs4270_probe+0x34/0x124
>> > =A0[df02bef0] [c0232fe8] snd_soc_instantiate_card+0x1a4/0x2f4
>> > =A0[df02bf20] [c0233164] snd_soc_instantiate_cards+0x2c/0x68
>> > =A0[df02bf30] [c0234704] snd_soc_register_platform+0x60/0x80
>> > =A0[df02bf50] [c03d5664] fsl_soc_platform_init+0x18/0x28
>> > =A0...
>> >
>> > This patch fixes the issue by using card's device instead.
>> >
>> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> > ---
>> > =A0sound/soc/fsl/fsl_dma.c | =A0 12 ++++++------
>> > =A01 files changed, 6 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
>> > index b3eb857..835e43c 100644
>> > --- a/sound/soc/fsl/fsl_dma.c
>> > +++ b/sound/soc/fsl/fsl_dma.c
>> > @@ -300,7 +300,7 @@ static int fsl_dma_new(struct snd_card *card, stru=
ct snd_soc_dai *dai,
>> > =A0 =A0 =A0 =A0if (!card->dev->coherent_dma_mask)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0card->dev->coherent_dma_mask =3D fsl_dm=
a_dmamask;
>> >
>> > - =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev=
,
>> > + =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->de=
v,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl_dma_hardware.buffer_bytes_max,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&pcm->streams[0].substream->dma_buffer)=
;
>> > =A0 =A0 =A0 =A0if (ret) {
>> > @@ -310,7 +310,7 @@ static int fsl_dma_new(struct snd_card *card, stru=
ct snd_soc_dai *dai,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENOMEM;
>> > =A0 =A0 =A0 =A0}
>> >
>> > - =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev=
,
>> > + =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->de=
v,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl_dma_hardware.buffer_bytes_max,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&pcm->streams[1].substream->dma_buffer)=
;
>> > =A0 =A0 =A0 =A0if (ret) {
>> > @@ -418,7 +418,7 @@ static int fsl_dma_open(struct snd_pcm_substream *=
substream)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EBUSY;
>> > =A0 =A0 =A0 =A0}
>> >
>> > - =A0 =A0 =A0 dma_private =3D dma_alloc_coherent(substream->pcm->dev,
>> > + =A0 =A0 =A0 dma_private =3D dma_alloc_coherent(substream->pcm->card-=
>dev,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct fsl_dma_private), &ld_buf=
_phys, GFP_KERNEL);
>> > =A0 =A0 =A0 =A0if (!dma_private) {
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_err(substream->pcm->card->dev,
>> > @@ -445,7 +445,7 @@ static int fsl_dma_open(struct snd_pcm_substream *=
substream)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_err(substream->pcm->card->dev,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"can't register ISR for=
IRQ %u (ret=3D%i)\n",
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_private->irq, ret);
>> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->dev,
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->card->=
dev,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct fsl_dma_p=
rivate),
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_private, dma_privat=
e->ld_buf_phys);
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return ret;
>> > @@ -761,13 +761,13 @@ static int fsl_dma_close(struct snd_pcm_substrea=
m *substream)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0free_irq(dma_private->i=
rq, dma_private);
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dma_private->ld_buf_phys) {
>> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(substre=
am->pcm->dev,
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(substre=
am->pcm->card->dev,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_pri=
vate->ld_buf_phys,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(=
dma_private->link), DMA_TO_DEVICE);
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Deallocate the fsl_dma_private struc=
ture */
>> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->dev,
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->card->=
dev,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct fsl_dma_p=
rivate),
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_private, dma_privat=
e->ld_buf_phys);
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substream->runtime->private_data =3D NU=
LL;
>> > --
>> > 1.5.6.5
>> > _______________________________________________
>> > Linuxppc-dev mailing list
>> > Linuxppc-dev@ozlabs.org
>> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >
>>
>>
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* 2.6.29-git12 : lockdep warning
From: Sachin Sant @ 2009-04-05 12:25 UTC (permalink / raw)
To: linux-kernel; +Cc: peterz, linuxppc-dev, mingo
With 2.6.29-git12 on a powerpc box i observed the following
warning
=================================
2.6.29-git12 #1
inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
yum-updatesd-he/6947 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&inode->inotify_mutex){+.+.?.}, at: [<c000000000154a04>] .inotify_inode_queue_event+0x6c/0x160
[<c000000000098198>] .lock_acquire+0x54/0x80
[<c000000000154bb0>] .inotify_inode_is_dead+0x38/0xcc
[<c0000000001319f0>] .d_kill+0x68/0xac
[<c0000000001320b4>] .shrink_dcache_memory+0x134/0x214
[<c0000000000e82fc>] .shrink_slab+0x144/0x20c
[<c0000000000e936c>] .kswapd+0x43c/0x628
[<c0000000000850e0>] .kthread+0x78/0xc4
[<c00000000002bd6c>] .kernel_thread+0x54/0x70
irq event stamp: 223781
hardirqs last enabled at (223781): [<c0000000001101c8>] .kmem_cache_alloc+0x184/0x200
hardirqs last disabled at (223780): [<c00000000010f204>] .cache_grow+0x3b0/0x48c
softirqs last enabled at (222934): [<c00000000002ba64>] .call_do_softirq+0x14/0x24
softirqs last disabled at (222923): [<c00000000002ba64>] .call_do_softirq+0x14/0x24
other info that might help us debug this:
4 locks held by yum-updatesd-he/6947:
#0: (&type->i_mutex_dir_key#4){+.+.+.}, at: [<c00000000012c53c>] .do_filp_open+0x188/0x874
#1: (&inode->inotify_mutex){+.+.?.}, at: [<c000000000154a04>] .inotify_inode_queue_event+0x6c/0x160
#2: (&ih->mutex){+.+...}, at: [<c000000000154a34>] .inotify_inode_queue_event+0x9c/0x160
#3: (&dev->ev_mutex){+.+...}, at: [<c000000000156330>] .inotify_dev_queue_event+0x50/0x1d8
stack backtrace:
Call Trace:
[c0000000541ff4f0] [c0000000000115cc] .show_stack+0x70/0x184 (unreliable)
[c0000000541ff5a0] [c000000000093a00] .print_usage_bug+0x1bc/0x1ec
[c0000000541ff650] [c000000000093dac] .mark_lock+0x37c/0x6c0
[c0000000541ff700] [c000000000094148] .mark_held_locks+0x58/0xac
[c0000000541ff790] [c000000000097f54] .lockdep_trace_alloc+0xc4/0xf4
[c0000000541ff810] [c00000000010fc24] .__kmalloc+0x98/0x25c
[c0000000541ff8b0] [c000000000156244] .kernel_event+0xbc/0x158
[c0000000541ff950] [c000000000156400] .inotify_dev_queue_event+0x120/0x1d8
[c0000000541ffa00] [c000000000154a84] .inotify_inode_queue_event+0xec/0x160
[c0000000541ffad0] [c0000000001292cc] .vfs_create+0x168/0x1e4
[c0000000541ffb70] [c00000000012c5f0] .do_filp_open+0x23c/0x874
[c0000000541ffd10] [c00000000011aecc] .do_sys_open+0x80/0x140
[c0000000541ffdc0] [c000000000161748] .compat_sys_open+0x24/0x38
[c0000000541ffe30] [c000000000008554] syscall_exit+0x0/0x40
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox