[PATCH 2/3] dts: Add sdhci-auto-cmd12 field for p4080 device tree
Signed-off-by: Roy Zang
---
arch/powerpc/boot/dts/p4080ds.dts |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p4080ds.dts
b/arch/powerpc/boot/dts/p4080ds.dts
index 6b29eab..11c8884 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -280,6 +280,7 @@
reg = <0x114000 0x1000>;
interrupts = <48 2>;
interrupt-parent = <&mpic>;
+ fsl,sdhci-auto-cmd12;
};
i...@118000 {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] mmc: Auto CMD12 support for eSDHC driver
From: Jerry Huang
Add auto CMD12 command support for eSDHC driver.
This is needed by P4080 and P1022 for block read/write.
Manual asynchronous CMD12 abort operation causes protocol violations on
these silicons.
Signed-off-by: Jerry Huang
Signed-off-by: Roy Zang
---
drivers/mmc/host/sdhci-of-core.c |4
drivers/mmc/host/sdhci.c | 14 --
drivers/mmc/host/sdhci.h |3 +++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index a2e9820..0c30242 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -154,6 +154,10 @@ static int __devinit sdhci_of_probe(struct of_device
*ofdev,
host->ops = &sdhci_of_data->ops;
}
+ if (of_get_property(np, "fsl,sdhci-auto-cmd12", NULL))
+ host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
+
+
if (of_get_property(np, "sdhci,1-bit-only", NULL))
host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c6d1bd8..1424d08 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2,6 +2,7 @@
* linux/drivers/mmc/host/sdhci.c - Secure Digital Host Controller Interface
driver
*
* Copyright (C) 2005-2008 Pierre Ossman, All Rights Reserved.
+ * Copyright 2010 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -817,8 +818,12 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host->data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data->blocks > 1)
- mode |= SDHCI_TRNS_MULTI;
+ if (data->blocks > 1) {
+ if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
+ else
+ mode |= SDHCI_TRNS_MULTI;
+ }
if (data->flags & MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
if (host->flags & SDHCI_REQ_USE_DMA)
@@ -1108,6 +1113,11 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
#ifndef SDHCI_USE_LEDS_CLASS
sdhci_activate_led(host);
#endif
+ if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ if (mrq->stop) {
+ mrq->data->stop = NULL;
+ mrq->stop = NULL;
+ }
host->mrq = mrq;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c846813..aa112aa 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -2,6 +2,7 @@
* linux/drivers/mmc/host/sdhci.h - Secure Digital Host Controller Interface
driver
*
* Copyright (C) 2005-2008 Pierre Ossman, All Rights Reserved.
+ * Copyright 2010 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -240,6 +241,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (1<<25)
/* Controller cannot support End Attribute in NOP ADMA descriptor */
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
+/* Controller uses Auto CMD12 command to stop the transfer */
+#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] mmc: Add ESDHC weird register workaround
P4080 ESDHC controller induces weird register setting.
This patch adds the workaround to correct the weird register setting.
Signed-off-by: Roy Zang
---
drivers/mmc/host/sdhci-of-core.c |5 +
drivers/mmc/host/sdhci.c | 13 +
drivers/mmc/host/sdhci.h |2 ++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index 0c30242..1b6945a 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -164,6 +164,11 @@ static int __devinit sdhci_of_probe(struct of_device
*ofdev,
if (sdhci_of_wp_inverted(np))
host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
+ if (of_device_is_compatible(np, "fsl,p4080-esdhc")) {
+ host->quirks |= SDHCI_QUIRK_QORIQ_REG_WEIRD;
+ host->quirks &= ~SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
+ }
+
clk = of_get_property(np, "clock-frequency", &size);
if (clk && size == sizeof(*clk) && *clk)
of_host->clock = *clk;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1424d08..b5b3627 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -788,6 +788,15 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
}
+ /* The default value of DMAS bits of Protocol Control Register is not
+* correct. clear these two bits to use simple DMA */
+#define ESDHCI_CTRL_DMAS_MASK 0xFCFF
+ if (host->quirks & SDHCI_QUIRK_QORIQ_REG_WEIRD) {
+ ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
+ ctrl = ctrl & ESDHCI_CTRL_DMAS_MASK;
+ sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
+ }
+
if (!(host->flags & SDHCI_REQ_USE_DMA)) {
int flags;
@@ -1699,6 +1708,10 @@ int sdhci_add_host(struct sdhci_host *host)
caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+/* Workaround for P4080 host controller capabilities */
+ if (host->quirks & SDHCI_QUIRK_QORIQ_REG_WEIRD)
+ caps &= ~(SDHCI_CAN_VDD_180 | SDHCI_CAN_VDD_330);
+
if (host->quirks & SDHCI_QUIRK_FORCE_DMA)
host->flags |= SDHCI_USE_SDMA;
else if (!(caps & SDHCI_CAN_DO_SDMA))
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index aa112aa..33d5613 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -243,6 +243,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
/* Controller uses Auto CMD12 command to stop the transfer */
#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
+/* Controller has weird bit setting for some registers due to errata */
+#define SDHCI_QUIRK_QORIQ_REG_WEIRD(1<<28)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] mmc: Add mmc support for P4080 chip
This serial patch adds some workarounds to enable mmc card support for P4080 chip. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull my perf.git urgent branch
On Tue, Jul 27, 2010 at 11:28:54AM -0500, Scott Wood wrote: > Doesn't the setting of .period need to be maintained (it is in the other > powerpc perf_event implementation that this is derived from)? Gah, yes it does. > I don't see how this is a security fix -- the existing initializer above > should zero-fill the fields that are not explicitly initialized. In fact, > it's taking other fields that were previously initialized to zero and is > making them uninitialized, since perf_sample_data_init only sets addr and > raw. So I misunderstood how an initializer for an automatic struct works. Brown paper bag time for me... :( Regarding the other fields, I assume Peter et al. have checked that they don't need to be cleared, so it's a microoptimization to not clear them. > CCing linuxppc-dev on the original patch would have been nice... True, but at least I can blame Peter Z. for that. :) Kumar and Ben, how do you want to proceed on this one? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: print decimal values in prom_init.c
Currently we look pretty stupid when printing out a bunch of things in
prom_init.c. eg.
Max number of cores passed to firmware: 0x0080
So I've change this to print in decimal:
Max number of cores passed to firmware: 128 (NR_CPUS = 256)
This required adding a prom_print_dec() function and changing some
prom_printk() calls from %x to %lu.
Signed-off-by: Michael Neuling
---
Bike shed colour status: Mauve.
Thanks to a suggestion from paulus, we are now 3 lines shorter.
arch/powerpc/kernel/prom_init.c | 44 +++
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 3b6f8ae..941ff4d 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -311,6 +311,24 @@ static void __init prom_print_hex(unsigned long val)
call_prom("write", 3, 1, _prom->stdout, buf, nibbles);
}
+/* max number of decimal digits in an unsigned long */
+#define UL_DIGITS 21
+static void __init prom_print_dec(unsigned long val)
+{
+ int i, size;
+ char buf[UL_DIGITS+1];
+ struct prom_t *_prom = &RELOC(prom);
+
+ for (i = UL_DIGITS-1; i >= 0; i--) {
+ buf[i] = (val % 10) + '0';
+ val = val/10;
+ if (val == 0)
+ break;
+ }
+ /* shift stuff down */
+ size = UL_DIGITS - i;
+ call_prom("write", 3, 1, _prom->stdout, buf+i, size);
+}
static void __init prom_printf(const char *format, ...)
{
@@ -350,6 +368,14 @@ static void __init prom_printf(const char *format, ...)
v = va_arg(args, unsigned long);
prom_print_hex(v);
break;
+ case 'l':
+ ++q;
+ if (*q == 'u') { /* '%lu' */
+ ++q;
+ v = va_arg(args, unsigned long);
+ prom_print_dec(v);
+ }
+ break;
}
}
}
@@ -835,11 +861,11 @@ static int __init prom_count_smt_threads(void)
if (plen == PROM_ERROR)
break;
plen >>= 2;
- prom_debug("Found 0x%x smt threads per core\n", (unsigned
long)plen);
+ prom_debug("Found %lu smt threads per core\n", (unsigned
long)plen);
/* Sanity check */
if (plen < 1 || plen > 64) {
- prom_printf("Threads per core 0x%x out of bounds,
assuming 1\n",
+ prom_printf("Threads per core %lu out of bounds,
assuming 1\n",
(unsigned long)plen);
return 1;
}
@@ -869,12 +895,12 @@ static void __init prom_send_capabilities(void)
cores = (u32
*)PTRRELOC(&ibm_architecture_vec[IBM_ARCH_VEC_NRCORES_OFFSET]);
if (*cores != NR_CPUS) {
prom_printf("WARNING ! "
- "ibm_architecture_vec structure
inconsistent: 0x%x !\n",
+ "ibm_architecture_vec structure
inconsistent: %lu!\n",
*cores);
} else {
*cores = DIV_ROUND_UP(NR_CPUS,
prom_count_smt_threads());
- prom_printf("Max number of cores passed to firmware:
0x%x\n",
- (unsigned long)*cores);
+ prom_printf("Max number of cores passed to firmware:
%lu (NR_CPUS = %lu)\n",
+ *cores, NR_CPUS);
}
/* try calling the ibm,client-architecture-support method */
@@ -1482,7 +1508,7 @@ static void __init prom_hold_cpus(void)
reg = -1;
prom_getprop(node, "reg", ®, sizeof(reg));
- prom_debug("cpu hw idx = 0x%x\n", reg);
+ prom_debug("cpu hw idx = %lu\n", reg);
/* Init the acknowledge var which will be reset by
* the secondary cpu when it awakens from its OF
@@ -1492,7 +1518,7 @@ static void __init prom_hold_cpus(void)
if (reg != _prom->cpu) {
/* Primary Thread of non-boot cpu */
- prom_printf("starting cpu hw idx %x... ", reg);
+ prom_printf("starting cpu hw idx %lu... ", reg);
call_prom("start-cpu", 3, 0, node,
secondary_hold, reg);
@@ -1507,7 +1533,7 @@ static void __init prom_hold_cpus(void)
}
#ifdef CONFIG_SMP
else
- prom_printf("boot cpu hw idx %x\n", reg);
+ prom_printf("boot cpu hw idx %lu\n", reg);
#endif /* CONFIG_SMP */
}
@@ -2420,7 +2446,7 @@ static void __init prom_find_boot
Re: [PATCH 04/11] powerpc: Simplify update_vsyscall
On Wed, 2010-07-28 at 09:41 +1000, Paul Mackerras wrote:
> On Tue, Jul 13, 2010 at 05:56:21PM -0700, John Stultz wrote:
>
> > Currently powerpc's update_vsyscall calls an inline update_gtod.
> > However, both are straightforward, and there are no other users,
> > so this patch merges update_gtod into update_vsyscall.
> >
> > Compiles, but otherwise untested.
>
> This and the following two patches will cause interesting conflicts
> with two commits in Ben Herrenschmidt's powerpc.git next branch,
> specifically 8fd63a9e ("powerpc: Rework VDSO gettimeofday to prevent
> time going backwards") and c1aa687d ("powerpc: Clean up obsolete code
> relating to decrementer and timebase") from me. In fact the first of
> those two commits includes changes equivalent to those in your 5/11
> patch ("powerpc: Cleanup xtime usage"), as far as I can see.
Ahh.. Right.. I guess I should have remembered you were working on those
changes (even though I don't think I saw the final results sent to lkml
or anything).
Sorry about that.
> BTW, BenH's tree is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
So I've cherry picked the two changes from the ppc tree, applied them
onto linus' git tree and then rebased my changes ontop of them.
The net of the change to the patch set:
Added to the head of the patch queue:
powerpc: Rework VDSO gettimeofday to prevent time going backwards
powerpc: Clean up obsolete code relating to decrementer and timebase
Modified to resolve collision:
powerpc: Simplify update_vsyscall
Dropped (as earlier patches already made equivalent changes):
powerpc: Cleanup xtime usage
The full set is in the attached tarball.
Thomas, would you consider re-adding these? Hopefully that will avoid
any -next collisions.
thanks
-john
patches.tar.bz2
Description: application/bzip-compressed-tar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: print decimal values in prom_init.c
Currently we look pretty stupid when printing out a bunch of things in
prom_init.c. eg.
Max number of cores passed to firmware: 0x0080
So I've change this to print in decimal:
Max number of cores passed to firmware: 128 (NR_CPUS = 256)
This required adding a prom_print_dec() function and changing some
prom_printk() calls from %x to %lu.
Signed-off-by: Michael Neuling
---
This version changes more things over to decimal.
arch/powerpc/kernel/prom_init.c | 47 +++---
1 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 3b6f8ae..7bc5ae8 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -311,6 +311,27 @@ static void __init prom_print_hex(unsigned long val)
call_prom("write", 3, 1, _prom->stdout, buf, nibbles);
}
+/* max number of decimal digits in an unsigned long */
+#define UL_DIGITS 21
+static void __init prom_print_dec(unsigned long val)
+{
+ int i, size;
+ char buf[UL_DIGITS+1];
+ struct prom_t *_prom = &RELOC(prom);
+
+ for (i = UL_DIGITS-1; i >= 0; i--) {
+ buf[i] = (val % 10) + '0';
+ val = val/10;
+ if (val == 0)
+ break;
+ }
+ /* shift stuff down */
+ size = UL_DIGITS - i;
+ for (i = 0 ; i < size ; i++)
+ buf[i] = buf[i + UL_DIGITS - size];
+ buf[size+1] = '\0';
+ call_prom("write", 3, 1, _prom->stdout, buf, size);
+}
static void __init prom_printf(const char *format, ...)
{
@@ -350,6 +371,14 @@ static void __init prom_printf(const char *format, ...)
v = va_arg(args, unsigned long);
prom_print_hex(v);
break;
+ case 'l':
+ ++q;
+ if (*q == 'u') { /* '%lu' */
+ ++q;
+ v = va_arg(args, unsigned long);
+ prom_print_dec(v);
+ }
+ break;
}
}
}
@@ -835,11 +864,11 @@ static int __init prom_count_smt_threads(void)
if (plen == PROM_ERROR)
break;
plen >>= 2;
- prom_debug("Found 0x%x smt threads per core\n", (unsigned
long)plen);
+ prom_debug("Found %lu smt threads per core\n", (unsigned
long)plen);
/* Sanity check */
if (plen < 1 || plen > 64) {
- prom_printf("Threads per core 0x%x out of bounds,
assuming 1\n",
+ prom_printf("Threads per core %lu out of bounds,
assuming 1\n",
(unsigned long)plen);
return 1;
}
@@ -869,12 +898,12 @@ static void __init prom_send_capabilities(void)
cores = (u32
*)PTRRELOC(&ibm_architecture_vec[IBM_ARCH_VEC_NRCORES_OFFSET]);
if (*cores != NR_CPUS) {
prom_printf("WARNING ! "
- "ibm_architecture_vec structure
inconsistent: 0x%x !\n",
+ "ibm_architecture_vec structure
inconsistent: %lu!\n",
*cores);
} else {
*cores = DIV_ROUND_UP(NR_CPUS,
prom_count_smt_threads());
- prom_printf("Max number of cores passed to firmware:
0x%x\n",
- (unsigned long)*cores);
+ prom_printf("Max number of cores passed to firmware:
%lu (NR_CPUS = %lu)\n",
+ *cores, NR_CPUS);
}
/* try calling the ibm,client-architecture-support method */
@@ -1482,7 +1511,7 @@ static void __init prom_hold_cpus(void)
reg = -1;
prom_getprop(node, "reg", ®, sizeof(reg));
- prom_debug("cpu hw idx = 0x%x\n", reg);
+ prom_debug("cpu hw idx = %lu\n", reg);
/* Init the acknowledge var which will be reset by
* the secondary cpu when it awakens from its OF
@@ -1492,7 +1521,7 @@ static void __init prom_hold_cpus(void)
if (reg != _prom->cpu) {
/* Primary Thread of non-boot cpu */
- prom_printf("starting cpu hw idx %x... ", reg);
+ prom_printf("starting cpu hw idx %lu... ", reg);
call_prom("start-cpu", 3, 0, node,
secondary_hold, reg);
@@ -1507,7 +1536,7 @@ static void __init prom_hold_cpus(void)
}
#ifdef CONFIG_SMP
else
- prom_printf("boot cpu hw idx %x\n", reg);
+ prom_printf("boot cpu hw idx %lu\n", reg);
#endif /* CONFIG_SMP */
Patch "genirq: Deal with desc->set_type() changing desc->chip" has been added to the 2.6.32-stable tree
This is a note to let you know that I've just added the patch titled genirq: Deal with desc->set_type() changing desc->chip to the 2.6.32-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: genirq-deal-with-desc-set_type-changing-desc-chip.patch and it can be found in the queue-2.6.32 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From 4673247562e39a17e09440fa1400819522ccd446 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Mon, 7 Jun 2010 17:53:51 +0200 Subject: genirq: Deal with desc->set_type() changing desc->chip From: Thomas Gleixner commit 4673247562e39a17e09440fa1400819522ccd446 upstream. The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc->lock against all users of desc->chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc->chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc->set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by: Esben Haabendal Signed-off-by: Thomas Gleixner Cc: Benjamin Herrenschmidt Cc: linuxppc-dev Signed-off-by: Greg Kroah-Hartman --- kernel/irq/manage.c |3 +++ 1 file changed, 3 insertions(+) --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -436,6 +436,9 @@ int __irq_set_trigger(struct irq_desc *d /* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */ desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK); desc->status |= flags; + + if (chip != desc->chip) + irq_chip_set_defaults(desc->chip); } return ret; Patches currently in stable-queue which might be from t...@linutronix.de are queue-2.6.32/genirq-deal-with-desc-set_type-changing-desc-chip.patch ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch "genirq: Deal with desc->set_type() changing desc->chip" has been added to the 2.6.33-stable tree
This is a note to let you know that I've just added the patch titled genirq: Deal with desc->set_type() changing desc->chip to the 2.6.33-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: genirq-deal-with-desc-set_type-changing-desc-chip.patch and it can be found in the queue-2.6.33 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From 4673247562e39a17e09440fa1400819522ccd446 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Mon, 7 Jun 2010 17:53:51 +0200 Subject: genirq: Deal with desc->set_type() changing desc->chip From: Thomas Gleixner commit 4673247562e39a17e09440fa1400819522ccd446 upstream. The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc->lock against all users of desc->chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc->chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc->set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by: Esben Haabendal Signed-off-by: Thomas Gleixner Cc: Benjamin Herrenschmidt Cc: linuxppc-dev Signed-off-by: Greg Kroah-Hartman --- kernel/irq/manage.c |3 +++ 1 file changed, 3 insertions(+) --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -436,6 +436,9 @@ int __irq_set_trigger(struct irq_desc *d /* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */ desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK); desc->status |= flags; + + if (chip != desc->chip) + irq_chip_set_defaults(desc->chip); } return ret; Patches currently in stable-queue which might be from t...@linutronix.de are queue-2.6.33/genirq-deal-with-desc-set_type-changing-desc-chip.patch queue-2.6.33/x86-send-a-sigtrap-for-user-icebp-traps.patch ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch "genirq: Deal with desc->set_type() changing desc->chip" has been added to the 2.6.34-stable tree
This is a note to let you know that I've just added the patch titled genirq: Deal with desc->set_type() changing desc->chip to the 2.6.34-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: genirq-deal-with-desc-set_type-changing-desc-chip.patch and it can be found in the queue-2.6.34 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From 4673247562e39a17e09440fa1400819522ccd446 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Mon, 7 Jun 2010 17:53:51 +0200 Subject: genirq: Deal with desc->set_type() changing desc->chip From: Thomas Gleixner commit 4673247562e39a17e09440fa1400819522ccd446 upstream. The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc->lock against all users of desc->chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc->chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc->set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by: Esben Haabendal Signed-off-by: Thomas Gleixner Cc: Benjamin Herrenschmidt Cc: linuxppc-dev Signed-off-by: Greg Kroah-Hartman --- kernel/irq/manage.c |3 +++ 1 file changed, 3 insertions(+) --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -440,6 +440,9 @@ int __irq_set_trigger(struct irq_desc *d /* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */ desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK); desc->status |= flags; + + if (chip != desc->chip) + irq_chip_set_defaults(desc->chip); } return ret; Patches currently in stable-queue which might be from t...@linutronix.de are queue-2.6.34/genirq-deal-with-desc-set_type-changing-desc-chip.patch queue-2.6.34/x86-send-a-sigtrap-for-user-icebp-traps.patch ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] powerpc: Simplify update_vsyscall
On Tue, Jul 13, 2010 at 05:56:21PM -0700, John Stultz wrote:
> Currently powerpc's update_vsyscall calls an inline update_gtod.
> However, both are straightforward, and there are no other users,
> so this patch merges update_gtod into update_vsyscall.
>
> Compiles, but otherwise untested.
This and the following two patches will cause interesting conflicts
with two commits in Ben Herrenschmidt's powerpc.git next branch,
specifically 8fd63a9e ("powerpc: Rework VDSO gettimeofday to prevent
time going backwards") and c1aa687d ("powerpc: Clean up obsolete code
relating to decrementer and timebase") from me. In fact the first of
those two commits includes changes equivalent to those in your 5/11
patch ("powerpc: Cleanup xtime usage"), as far as I can see.
BTW, BenH's tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc512x_dma hangs when used from multiple threads
Hello Piotr, everybody, I've found that mpc512x_dma channels hang sometimes while accessed from more than one thread simultaneously. The easiest way to reproduce this error I've managed to found is using dmatest module with rather high threads_per_chan value (20 should be enough): -bash-3.2# insmod dmatest.ko max_channels=1 iterations=1 threads_per_chan=20 [ 32.559568] dma0chan0-copy0: terminating after 1 tests, 0 failures (status 0) -bash-3.2# [ 35.553688] dma0chan0-copy1: #0: test timed out [ 35.558207] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.565458] dma0chan0-copy1: #0: test timed out [ 35.569968] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.577219] dma0chan0-copy1: #0: test timed out [ 35.581735] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.588953] dma0chan0-copy2: #0: test timed out [ 35.593502] dma0chan0-copy2: terminating after 1 tests, 1 failures (status 0) [ 35.600720] dma0chan0-copy3: #0: test timed out [ 35.605284] dma0chan0-copy3: terminating after 1 tests, 1 failures (status 0) [ 35.612472] dma0chan0-copy4: #0: test timed out [ 35.617052] dma0chan0-copy4: terminating after 1 tests, 1 failures (status 0) [ 35.624381] dma0chan0-copy5: #0: test timed out [ 35.628895] dma0chan0-copy5: terminating after 1 tests, 1 failures (status 0) [ 35.636126] dma0chan0-copy6: #0: test timed out [ 35.640657] dma0chan0-copy6: terminating after 1 tests, 1 failures (status 0) [ 35.647876] dma0chan0-copy7: #0: test timed out [ 35.652425] dma0chan0-copy7: terminating after 1 tests, 1 failures (status 0) [ 35.659643] dma0chan0-copy8: #0: test timed out [ 35.664209] dma0chan0-copy8: terminating after 1 tests, 1 failures (status 0) [ 35.671395] dma0chan0-copy9: #0: test timed out [ 35.675976] dma0chan0-copy9: terminating after 1 tests, 1 failures (status 0) [ 35.683164] dma0chan0-copy1: #0: test timed out [ 35.687743] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.694942] dma0chan0-copy1: #0: test timed out [ 35.699495] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.706714] dma0chan0-copy1: #0: test timed out [ 35.711264] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.719826] dma0chan0-copy1: #0: test timed out [ 35.724404] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.731549] dma0chan0-copy1: #0: test timed out [ 35.736131] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.744247] dma0chan0-copy1: #0: test timed out [ 35.748778] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.756768] dma0chan0-copy1: #0: test timed out [ 35.761301] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) [ 35.769306] dma0chan0-copy1: #0: test timed out [ 35.773883] dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0) Also, this can be reproduced using more than one channel at once (in this case some of channels eventually hang). With max_channels=1 and threads_per_chan=1 dmatest works fine so I think this should be a synchronization issue. After the hang, channel becomes unusable and cannot be even freed... Is it a known problem? Maybe there exists some fix or workaround for it? Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 2/2] powerpc/mpc5121: add initial support for PDM360NG board
Adds IFM PDM360NG device tree and platform code.
Currently following is supported:
- Spansion S29GL512P 256 MB NOR flash
- ST Micro NAND 1 GiB flash
- DIU, please use "fbcon=map:5 video=fslfb:800x480...@60"
at the kernel command line to enable PrimeView PM070WL3
Display support.
- FEC
- I2C
- RTC, EEPROM
- MSCAN
- PSC UART, please pass "console=tty0 console=ttyPSC5,115200"
on the kernel command line.
- SPI, ADS7845 Touchscreen
- USB0/1 Host
- USB0 OTG Host/Device
- VIU, Overlay/Capture support
Signed-off-by: Markus Fischer
Signed-off-by: Wolfgang Grandegger
Signed-off-by: Michael Weiss
Signed-off-by: Detlev Zundel
Signed-off-by: Anatolij Gustschin
Cc: devicetree-disc...@lists.ozlabs.org
Cc: Grant Likely
---
v4:
- set interrupt-parent in root node only, less verbose DT
- add compatible property to phy node
- update touch screen controller node (add reg and
spi-max-frequency properties)
- drop unnecessary (u32 *) casts
- change return statement in pdm360ng_get_pendown_state()
as suggested
- use correct error codes (-ENODEV) when returning on errors
- use of_iomap() to eliminate some code
- rework pdm360ng_touchscreen_init() to only use bus notifier
for addition of platform data for touch screen driver
- eliminate machine_device_initcall(), code moved to init
callback
v3:
- uncomment and correct .irq_flags field of touchscreen
platform data struct as proposed extension to this
data struct has been accepted and merged via input tree
a short while ago
v1 -> v2:
- fix interrupt-parent property in nfc node
- drop #address-cells in ipic node
- remove device_type from ethernet-phy sub-node
- remove device_type from ethernet node
- add aliases node for eth0, needed for MAC address
update by U-Boot
- removed spaces around &ipic
arch/powerpc/boot/dts/pdm360ng.dts | 410
arch/powerpc/platforms/512x/Kconfig|7 +
arch/powerpc/platforms/512x/Makefile |1 +
arch/powerpc/platforms/512x/pdm360ng.c | 129 ++
4 files changed, 547 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/pdm360ng.dts
create mode 100644 arch/powerpc/platforms/512x/pdm360ng.c
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts
b/arch/powerpc/boot/dts/pdm360ng.dts
new file mode 100644
index 000..94dfa5c
--- /dev/null
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -0,0 +1,410 @@
+/*
+ * Device Tree Source for IFM PDM360NG.
+ *
+ * Copyright 2009 - 2010 DENX Software Engineering.
+ * Anatolij Gustschin
+ *
+ * Based on MPC5121E ADS dts.
+ * Copyright 2008 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "pdm360ng";
+ compatible = "ifm,pdm360ng";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&ipic>;
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5...@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <4950>;// 49.5 MHz (csb/4)
+ bus-frequency = <19800>;// 198 MHz csb bus
+ clock-frequency = <39600>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>; // 512MB at 0
+ };
+
+ n...@4000 {
+ compatible = "fsl,mpc5121-nfc";
+ reg = <0x4000 0x10>;
+ interrupts = <0x6 0x8>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ bank-width = <0x1>;
+ chips = <0x1>;
+
+ partit...@0 {
+ label = "nand0";
+ reg = <0x0 0x4000>;
+ };
+ };
+
+ s...@5000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x5000 0x2>; // 128K at 0x5000
+ };
+
+ local...@8020 {
+ compatible = "fsl,mpc5121-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x8020 0x40>;
+
+ ranges = <0x0 0x0 0xf000 0x1000 /* Flash */
+ 0x2 0x0 0x5004 0x0002>; /* CS2: MRAM */
+
+ fl...@0,0 {
+
[PATCH] xilinxfb: update tft comp versions
* Add tft display module compatibility for new
hardware modules
Signed-off-by: Adrian Alonso
---
drivers/video/xilinxfb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 574dc54..29b5daa 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -485,6 +485,8 @@ static int __devexit xilinxfb_of_remove(struct of_device
*op)
/* Match table for of_platform binding */
static struct of_device_id xilinxfb_of_match[] __devinitdata = {
{ .compatible = "xlnx,xps-tft-1.00.a", },
+ { .compatible = "xlnx,xps-tft-2.00.a", },
+ { .compatible = "xlnx,xps-tft-2.01.a", },
{ .compatible = "xlnx,plb-tft-cntlr-ref-1.00.a", },
{ .compatible = "xlnx,plb-dvi-cntlr-ref-1.00.c", },
{},
--
1.7.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch v2] kexec: increase max of kexec segments and use dynamic allocation
Milton Miller writes:
> [ Added kexec at lists.infradead.org and linuxppc-dev@lists.ozlabs.org ]
>
>>
>> Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine with
>> many memory ranges. When hibernate on a machine with disjoint memory we do
>> need one segment for each memory region. Increase this hard limit to 16K
>> which is reasonably large.
>>
>> And change ->segment from a static array to a dynamically allocated memory.
>>
>> Cc: Neil Horman
>> Cc: huang ying
>> Cc: Eric W. Biederman
>> Signed-off-by: WANG Cong
>>
>> ---
>> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
>> b/arch/powerpc/kernel/machine_kexec_64.c
>> index ed31a29..f115585 100644
>> --- a/arch/powerpc/kernel/machine_kexec_64.c
>> +++ b/arch/powerpc/kernel/machine_kexec_64.c
>> @@ -131,10 +131,7 @@ static void copy_segments(unsigned long ind)
>> void kexec_copy_flush(struct kimage *image)
>> {
>> long i, nr_segments = image->nr_segments;
>> -struct kexec_segment ranges[KEXEC_SEGMENT_MAX];
>> -
>> -/* save the ranges on the stack to efficiently flush the icache */
>> -memcpy(ranges, image->segment, sizeof(ranges));
>> +struct kexec_segment range;
>
> I'm glad you found our copy on the stack and removed the stack overflow
> that comes with this bump, but ...
>
>>
>> /*
>> * After this call we may not use anything allocated in dynamic
>> @@ -148,9 +145,11 @@ void kexec_copy_flush(struct kimage *image)
>> * we need to clear the icache for all dest pages sometime,
>> * including ones that were in place on the original copy
>> */
>> -for (i = 0; i < nr_segments; i++)
>> -flush_icache_range((unsigned long)__va(ranges[i].mem),
>> -(unsigned long)__va(ranges[i].mem + ranges[i].memsz));
>> +for (i = 0; i < nr_segments; i++) {
>> +memcpy(&range, &image->segment[i], sizeof(range));
>> +flush_icache_range((unsigned long)__va(range.mem),
>> +(unsigned long)__va(range.mem + range.memsz));
>> +}
>> }
>
> This is executed after the copy, so as it says,
> "we may not use anything allocated in dynamic memory".
>
> We could allocate control pages to copy the segment list into.
> Actually ppc64 doesn't use the existing control page, but that
> is only 4kB today.
>
> We need the list to icache flush all the pages in all the segments.
> The as the indirect list doesn't have pages that were allocated at
> their destination.
An interesting point.
> Or maybe the icache flush should be done in the generic code
> like it does for crash load segments?
Please. I don't quite understand the icache flush requirement.
But we really should not be looking at the segments in the
architecture specific code.
Ideally we would only keep the segment information around for
the duration of the kexec_load syscall and not have it when
it comes time to start the second kernel.
I am puzzled. We should be completely replacing the page tables so
can't we just do a global flush? Perhaps I am being naive about what
is required for a ppc flush.
Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] of/spi: add support to parse the SPI flash's partitions
[cc'ing spi-devel-general]
On Mon, Jul 26, 2010 at 2:20 AM, Hu Mingkai-B21284 wrote:
>
>
>> -Original Message-
>> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On
>> Behalf Of Grant Likely
>> Sent: Monday, July 26, 2010 3:53 PM
>> To: Hu Mingkai-B21284
>> Cc: linuxppc-...@ozlabs.org; ga...@kernel.crashing.org; Zang
>> Roy-R61911
>> Subject: Re: [PATCH 3/6] of/spi: add support to parse the SPI
>> flash's partitions
>>
>> On Mon, Jul 26, 2010 at 1:25 AM, Hu Mingkai-B21284
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Grant Likely [mailto:glik...@secretlab.ca] On Behalf
>> Of Grant
>> >> Likely
>> >> Sent: Monday, July 26, 2010 8:28 AM
>> >> To: Hu Mingkai-B21284
>> >> Cc: linuxppc-...@ozlabs.org; ga...@kernel.crashing.org; Zang
>> >> Roy-R61911
>> >> Subject: Re: [PATCH 3/6] of/spi: add support to parse the
>> SPI flash's
>> >> partitions
>> >>
>> >> On Tue, Jul 20, 2010 at 10:08:22AM +0800, Mingkai Hu wrote:
>> >> > Signed-off-by: Mingkai Hu
>> >> > ---
>> >> > drivers/of/of_spi.c | 11 +++
>> >> > drivers/spi/spi_mpc8xxx.c | 1 +
>> >> > 2 files changed, 12 insertions(+), 0 deletions(-)
>> >> >
>> >> > diff --git a/drivers/of/of_spi.c b/drivers/of/of_spi.c index
>> >> > 5fed7e3..284ca0e 100644
>> >> > --- a/drivers/of/of_spi.c
>> >> > +++ b/drivers/of/of_spi.c
>> >> > @@ -10,6 +10,8 @@
>> >> > #include
>> >> > #include
>> >> > #include
>> >> > +#include
>> >> > +#include
>> >> >
>> >> > /**
>> >> > * of_register_spi_devices - Register child devices onto
>> >> the SPI bus
>> >> > @@ -26,6 +28,7 @@ void of_register_spi_devices(struct
>> >> spi_master *master, struct device_node *np)
>> >> > const __be32 *prop;
>> >> > int rc;
>> >> > int len;
>> >> > + struct flash_platform_data *pdata;
>> >> >
>> >> > for_each_child_of_node(np, nc) {
>> >> > /* Alloc an spi_device */ @@ -81,6 +84,14 @@ void
>> >> > of_register_spi_devices(struct
>> >> spi_master *master, struct device_node *np)
>> >> > of_node_get(nc);
>> >> > spi->dev.of_node = nc;
>> >> >
>> >> > + /* Parse the mtd partitions */
>> >> > + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
>> >> > + if (!pdata)
>> >> > + return;
>> >> > + pdata->nr_parts =
>> of_mtd_parse_partitions(&master->dev,
>> >> > + nc, &pdata->parts);
>> >> > + spi->dev.platform_data = pdata;
>> >> > +
>> >>
>> >> Nack. Not all spi devices are mtd devices. In fact, most are not.
>> >>
>> >> The spi driver itself should call the
>> of_mtd_parse_partitions code to
>> >> get the partition map. Do not use pdata in this case.
>> >>
>> >
>> > Yes, we can call of_mtd_parse_partitions to get the
>> partiton map, but
>> > how can we pass this map to spi device to register to MTD layer?
>> >
>> > The spi device is created and registered when call
>> > of_register_spi_device in the spi controller probe
>> function, then the
>> > spi device will traverse the spi device driver list to find
>> the proper
>> > driver, if matched, then call the spi device driver probe
>> code where
>> > the mtd partition info is registered to the mtd layer.
>> >
>> > so where is the proper place to put the
>> of_mtd_parse_partitions code?
>>
>> In the device driver probe code.
>>
>
> This is the way that I did at first, thus we need to add the same code
> in all the spi flash driver to get partition map info.
>
> or we add the get partition map code to of_spi.c?
No, it really does not belong in of_spi.c because the spi code has no
knowledge about MTD devices.
I only see two valid options, to either:
a) add it to each MTD driver, or
b) add a hook to the core MTD code so that if an of_node pointer is
provided, and no partition data is provided, then it will parse the
partitions when the MTD device is registered. You'd also need to code
it in a way that becomes a no-op when CONFIG_OF is not set.
>
> +/*
> + * of_parse_flash_partition - Parse the flash partition on the SPI bus
> + * @spi: Pointer to spi_device device
> + */
> +void of_parse_flash_partition(struct spi_device *spi)
> +{
> + struct mtd_partition *parts;
> + struct flash_platform_data *spi_pdata;
> + int nr_parts = 0;
> + static int num_flash;
> + struct device_node *np = spi->dev.archdata.of_node;
> +
> + nr_parts = of_mtd_parse_partitions(&spi->dev, np, &parts);
> + if (!nr_parts)
> + goto end;
> +
> + spi_pdata = kzalloc(sizeof(*spi_pdata), GFP_KERNEL);
> + if (!spi_pdata)
> + goto end;
> + spi_pdata->name = kzalloc(10, GFP_KERNEL);
> + if (!spi_pdata->name)
> + goto free_flash;
> + snprintf(spi_pdata->name, 10, "SPIFLASH%d", num_flash++);
> +
> + spi_pdata->parts = parts;
> + spi_pdata->nr_parts = nr_parts;
> +
> + spi->dev.platform_data = spi_pdata;
> +
> + return;
> +
> +free_flash:
> +
Re: [PATCH v3 2/2] powerpc/mpc5121: add initial support for PDM360NG board
On Tue, Jul 27, 2010 at 11:28 AM, Anatolij Gustschin wrote:
> On Tue, 27 Jul 2010 10:58:33 -0600
> Grant Likely wrote:
> ...
>> >> > + s...@11900 {
>> >> > + compatible = "fsl,mpc5121-psc-spi",
>> >> > "fsl,mpc5121-psc";
>> >> > + cell-index = <9>;
>> >>
>> >> Try to drop the cell-index properties. They are almost always misused.
>> >
>> > Removing cell-index would require changing the spi driver's probe.
>> > Currently cell-index is used to set spi bus number. What could be used
>> > for bus enumeration instead? Is it okay to use part of the spi node
>> > address? e.g. obtaining the offset 0x11900, masking out the unrelated
>> > bits and shifting by 8 would deliver unique index 9 for PSC9 in SPI
>> > mode. This would work for all 12 PSC SPI controllers of mpc5121.
>>
>> Does the spi bus number really matter? The device tree context gives
>> you a firm association between spi masters and devices which doesn't
>> require assigning a specific bus number. The core spi code can
>> dynamically assign a bus number for the bus by setting bus_num to -1.
>
> The bus number is used in the mpc5121 psc spi driver to obtain correct
> clock for PSC in question (0 to 11) and to enable the PSC clock at probe
> time. Therefore using dynamically assigned bus number would require another
> change to the spi driver.
That's unrelated to the bus number. Use cell-index value directly for
obtaining the clock if you need to; but limit its exposure. Once
Jeremy gets his common clock architecture merged, then we could
probably migrate to that for obtaining the correct clock without
cell-index.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc/mpc5121: add initial support for PDM360NG board
On Tue, 27 Jul 2010 10:58:33 -0600
Grant Likely wrote:
...
> >> > + s...@11900 {
> >> > + compatible = "fsl,mpc5121-psc-spi",
> >> > "fsl,mpc5121-psc";
> >> > + cell-index = <9>;
> >>
> >> Try to drop the cell-index properties. They are almost always misused.
> >
> > Removing cell-index would require changing the spi driver's probe.
> > Currently cell-index is used to set spi bus number. What could be used
> > for bus enumeration instead? Is it okay to use part of the spi node
> > address? e.g. obtaining the offset 0x11900, masking out the unrelated
> > bits and shifting by 8 would deliver unique index 9 for PSC9 in SPI
> > mode. This would work for all 12 PSC SPI controllers of mpc5121.
>
> Does the spi bus number really matter? The device tree context gives
> you a firm association between spi masters and devices which doesn't
> require assigning a specific bus number. The core spi code can
> dynamically assign a bus number for the bus by setting bus_num to -1.
The bus number is used in the mpc5121 psc spi driver to obtain correct
clock for PSC in question (0 to 11) and to enable the PSC clock at probe
time. Therefore using dynamically assigned bus number would require another
change to the spi driver.
...
> > This requires fixing the mpc5121 psc spi driver to create spi child
> > nodes of the spi master node. I have already send the appropriate
> > patch to spi-devel list, but it is not the right approach to call
> > of_register_spi_devices() in each driver.
>
> It's not wrong; but it isn't ideal either.
>
> > Do you plan to fix it in
> > core spi code in v2.6.36?
>
> Apparently I no longer have to because you've gone ahead and done it
> for me anyway. :-) I'll take a look at that patch and send you my
> comments.
Okay, thanks,
Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc/mpc5121: add initial support for PDM360NG board
On Tue, Jul 27, 2010 at 4:36 AM, Anatolij Gustschin wrote:
> Hi Grant,
>
> On Sun, 25 Jul 2010 01:42:23 -0600
> Grant Likely wrote:
> ...
>> Hi Anatolij,
>>
>> Finally got some time tonight to properly dig into this patch. Comments
>> below.
>
> Thanks for review and comments! My reply below.
Thanks Anatolij, replies below.
>> > + s...@11900 {
>> > + compatible = "fsl,mpc5121-psc-spi",
>> > "fsl,mpc5121-psc";
>> > + cell-index = <9>;
>>
>> Try to drop the cell-index properties. They are almost always misused.
>
> Removing cell-index would require changing the spi driver's probe.
> Currently cell-index is used to set spi bus number. What could be used
> for bus enumeration instead? Is it okay to use part of the spi node
> address? e.g. obtaining the offset 0x11900, masking out the unrelated
> bits and shifting by 8 would deliver unique index 9 for PSC9 in SPI
> mode. This would work for all 12 PSC SPI controllers of mpc5121.
Does the spi bus number really matter? The device tree context gives
you a firm association between spi masters and devices which doesn't
require assigning a specific bus number. The core spi code can
dynamically assign a bus number for the bus by setting bus_num to -1.
>> > +
>> > + if (bus_num < 0 || bus_num > 11)
>> > + return -ENODEV;
>> > +
>> > + info.bus_num = bus_num;
>> > +
>> > + of_dev = of_find_device_by_node(np);
>> > + of_node_put(np);
>> > + if (of_dev) {
>> > + struct fsl_spi_platform_data *pdata;
>> > +
>> > + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
>> > + if (pdata) {
>> > + pdata->bus_num = bus_num;
>> > + pdata->max_chipselect = 1;
>> > + of_dev->dev.platform_data = pdata;
>> > + }
>> > + }
>> > +
>> > + if (pdm360ng_penirq_init())
>> > + return -ENODEV;
>> > +
>> > + return spi_register_board_info(&info, 1);
>>
>> This ends up being a lot of code simply to attach a pdata structure to
>> an spi device. I've been thinking about this problem, and I think
>> there is a better way. Instead, use a bus notifier attached to the
>> SPI bus to wait for the spi_device to get registered, but before it
>> gets bound to a driver. Then you can attach the pdata structure very
>> simply. Something like this I think (completely untested, or even
>> compiled. Details are left as an exercise to the developer):
>>
>> static int pdm360ng_touchscreen_notifier_call(struct notifier_block *nb,
>> unsigned long event, void *__dev)
>> {
>> struct device *dev = __dev;
>>
>> if ((event == BUS_NOTIFIY_ADD_DEVICE) && (dev->of_node == [FOO]))
>> dev->platform_data = [BAR];
>> }
>>
>> static struct notifier_block pdm360ng_touchscreen_nb = {
>> notifier_call = pdm360ng_touchscreen_notifier_call;
>> };
>>
>> static int __init pdm360ng_touchscreen_init(void)
>> {
>> bus_register_notifier(&spi_bus_type, pdm360ng_touchscreen_nb);
>> }
>
> Thanks! Bus notifier is now used for setting platform data in v4.
Cool!
> This requires fixing the mpc5121 psc spi driver to create spi child
> nodes of the spi master node. I have already send the appropriate
> patch to spi-devel list, but it is not the right approach to call
> of_register_spi_devices() in each driver.
It's not wrong; but it isn't ideal either.
> Do you plan to fix it in
> core spi code in v2.6.36?
Apparently I no longer have to because you've gone ahead and done it
for me anyway. :-) I'll take a look at that patch and send you my
comments.
Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
On Tue, Jul 27, 2010 at 03:34:01PM +0200, Arnd Bergmann wrote: > On Tuesday 27 July 2010, Grant Likely wrote: > > > I suggest to go back to v2 of your patch where you use asm-generic/of.h. > > > > Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way. > > I don't mind adding stuff to asm-generic, but I think in this case it would > be easier to keep this in linux/of.h because there is nothing wrong with > all architectures including it. > > Most files in asm-generic are there only for historical reasons, where some > architectures use them but others don't. IMHO we should use the include/linux > headers preferred for new stuff though. Hi Arnd. Thanks for this explanation. Obviously my previous post about asm-generic was wrong (as Grant already indicated). Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull my perf.git urgent branch
On Tue, 27 Jul 2010 22:40:19 +1000
Paul Mackerras wrote:
> Please do a pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git urgent
>
> to get one commit that fixes a problem where, on some Freescale
> embedded PowerPC machines, unprivileged userspace could oops the
> kernel using the perf_event subsystem. I know it's late, but it is a
> potential security hole (but only on Freescale embedded systems), the
> fix is small (3 lines) and only affects Freescale embedded processors,
> and I was on vacation for the past two weeks. :)
[snip]
> diff --git a/arch/powerpc/kernel/perf_event_fsl_emb.c
> b/arch/powerpc/kernel/perf_event_fsl_emb.c
> index 369872f..babccee 100644
> --- a/arch/powerpc/kernel/perf_event_fsl_emb.c
> +++ b/arch/powerpc/kernel/perf_event_fsl_emb.c
> @@ -566,9 +566,9 @@ static void record_and_restart(struct perf_event *event,
> unsigned long val,
>* Finally record data if requested.
>*/
> if (record) {
> - struct perf_sample_data data = {
> - .period = event->hw.last_period,
> - };
> + struct perf_sample_data data;
> +
> + perf_sample_data_init(&data, 0);
>
> if (perf_event_overflow(event, nmi, &data, regs)) {
> /*
Doesn't the setting of .period need to be maintained (it is in the other
powerpc perf_event implementation that this is derived from)?
I don't see how this is a security fix -- the existing initializer above
should zero-fill the fields that are not explicitly initialized. In fact,
it's taking other fields that were previously initialized to zero and is
making them uninitialized, since perf_sample_data_init only sets addr and
raw.
CCing linuxppc-dev on the original patch would have been nice...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
On Tuesday 27 July 2010, Grant Likely wrote: > > I suggest to go back to v2 of your patch where you use asm-generic/of.h. > > Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way. I don't mind adding stuff to asm-generic, but I think in this case it would be easier to keep this in linux/of.h because there is nothing wrong with all architectures including it. Most files in asm-generic are there only for historical reasons, where some architectures use them but others don't. IMHO we should use the include/linux headers preferred for new stuff though. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull my perf.git urgent branch
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git urgent
to get one commit that fixes a problem where, on some Freescale
embedded PowerPC machines, unprivileged userspace could oops the
kernel using the perf_event subsystem. I know it's late, but it is a
potential security hole (but only on Freescale embedded systems), the
fix is small (3 lines) and only affects Freescale embedded processors,
and I was on vacation for the past two weeks. :)
Thanks,
Paul.
Peter Zijlstra (1):
perf, powerpc: Use perf_sample_data_init() for the FSL code
arch/powerpc/kernel/perf_event_fsl_emb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
commit 6b95ed345b9faa4ab3598a82991968f2e9f851bb
Author: Peter Zijlstra
Date: Fri Jul 9 10:21:21 2010 +0200
perf, powerpc: Use perf_sample_data_init() for the FSL code
We should use perf_sample_data_init() to initialize struct
perf_sample_data. As explained in the description of commit dc1d628a
("perf: Provide generic perf_sample_data initialization"), it is
possible for userspace to get the kernel to dereference data.raw,
so if it is not initialized, that means that unprivileged userspace
can possibly oops the kernel. Using perf_sample_data_init makes sure
it gets initialized to NULL.
This conversion should have been included in commit dc1d628a, but it
got missed.
Signed-off-by: Peter Zijlstra
Acked-by: Kumar Gala
Signed-off-by: Paul Mackerras
diff --git a/arch/powerpc/kernel/perf_event_fsl_emb.c
b/arch/powerpc/kernel/perf_event_fsl_emb.c
index 369872f..babccee 100644
--- a/arch/powerpc/kernel/perf_event_fsl_emb.c
+++ b/arch/powerpc/kernel/perf_event_fsl_emb.c
@@ -566,9 +566,9 @@ static void record_and_restart(struct perf_event *event,
unsigned long val,
* Finally record data if requested.
*/
if (record) {
- struct perf_sample_data data = {
- .period = event->hw.last_period,
- };
+ struct perf_sample_data data;
+
+ perf_sample_data_init(&data, 0);
if (perf_event_overflow(event, nmi, &data, regs)) {
/*
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc/mpc5121: add initial support for PDM360NG board
Hi Grant,
On Sun, 25 Jul 2010 01:42:23 -0600
Grant Likely wrote:
...
> Hi Anatolij,
>
> Finally got some time tonight to properly dig into this patch. Comments
> below.
Thanks for review and comments! My reply below.
...
> > + n...@4000 {
> > + compatible = "fsl,mpc5121-nfc";
> > + reg = <0x4000 0x10>;
> > + interrupts = <0x6 0x8>;
> > + interrupt-parent = <&ipic>;
>
> This device tree can be less verbose if you remove the
> interrupt-parent property from all the nodes, and have a single
> interrupt-parent = <&ipic>; in the root node. Nodes inherit the
> interrupt-parent from their (grand-)parents.
Fixed in next patch version to use interrupt-parent in root node only.
...
> > + m...@2800 {
> > + compatible = "fsl,mpc5121-fec-mdio";
> > + reg = <0x2800 0x200>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + phy: ethernet-...@0 {
> > + reg = <0x1f>;
>
> For completeness, phy should have a compatible property.
Added in next patch version.
...
> > + s...@11900 {
> > + compatible = "fsl,mpc5121-psc-spi",
> > "fsl,mpc5121-psc";
> > + cell-index = <9>;
>
> Try to drop the cell-index properties. They are almost always misused.
Removing cell-index would require changing the spi driver's probe.
Currently cell-index is used to set spi bus number. What could be used
for bus enumeration instead? Is it okay to use part of the spi node
address? e.g. obtaining the offset 0x11900, masking out the unrelated
bits and shifting by 8 would deliver unique index 9 for PSC9 in SPI
mode. This would work for all 12 PSC SPI controllers of mpc5121.
...
> > +static int pdm360ng_get_pendown_state(void)
> > +{
> > + u32 reg;
> > +
> > + reg = in_be32((u32 *)(pdm360ng_gpio_base + 0xc));
> > + if (reg & 0x40)
> > + setbits32((u32 *)(pdm360ng_gpio_base + 0xc), 0x40);
> > +
> > + reg = in_be32((u32 *)(pdm360ng_gpio_base + 0x8));
>
> (u32*) casts are unnecessary and can be removed.
Fixed.
> > +
> > + /* return 1 if pen is down */
> > + return reg & 0x40 ? 0 : 1;
>
> return reg & 0x40 == 0;
Fixed.
...
> > +static int __init pdm360ng_penirq_init(void)
> > +{
> > + struct device_node *np;
> > + struct resource r;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-gpio");
> > + if (!np) {
> > + pr_err("%s: Can't find 'mpc5121-gpio' node\n", __func__);
> > + return -1;
> > + }
>
> return -ENODEV;
Ok, fixed also.
...
> > + pdm360ng_gpio_base = ioremap(r.start, resource_size(&r));
>
> Or you could have simply used of_iomap() to eliminate some code.
of_iomap() is used in next patch version.
...
> > +static int __init pdm360ng_touchscreen_init(void)
> > +{
> > + struct device_node *np;
> > + struct of_device *of_dev;
> > + struct spi_board_info info;
> > + const u32 *prop;
> > + int bus_num = -1;
> > + int len;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "ti,ads7845");
> > + if (!np)
> > + return -ENODEV;
> > +
> > + memset(&info, 0, sizeof(info));
> > + info.irq = irq_of_parse_and_map(np, 0);
> > + if (info.irq == NO_IRQ)
> > + return -ENODEV;
> > +
> > + info.platform_data = &pdm360ng_ads7846_pdata;
> > + if (strlcpy(info.modalias, "ads7846",
> > + SPI_NAME_SIZE) >= SPI_NAME_SIZE)
> > + return -ENOMEM;
> > +
> > + np = of_get_next_parent(np);
> > + if (!np)
> > + return -ENODEV;
> > +
> > + prop = of_get_property(np, "cell-index", &len);
> > + if (prop && len == 4)
> > + bus_num = *prop;
>
> Blech. Don't use cell-index for bus enumeration. In fact, none of
> this should be necessary at all (see below).
I dropped this code entirely in the next patch version.
> > +
> > + if (bus_num < 0 || bus_num > 11)
> > + return -ENODEV;
> > +
> > + info.bus_num = bus_num;
> > +
> > + of_dev = of_find_device_by_node(np);
> > + of_node_put(np);
> > + if (of_dev) {
> > + struct fsl_spi_platform_data *pdata;
> > +
> > + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> > + if (pdata) {
> > + pdata->bus_num = bus_num;
> > + pdata->max_chipselect = 1;
> > + of_dev->dev.platform_data = pdata;
> > + }
> > + }
> > +
> > + if (pdm360ng_penirq_init())
> > + return -ENODEV;
> > +
> > + return spi_register_board_info(&info, 1);
>
> This ends up being a lot of code simply to attach a pdata structure to
> an spi device. I've been thinki
Re: [Patch v2] kexec: increase max of kexec segments and use dynamic allocation
[ Added kexec at lists.infradead.org and linuxppc-dev@lists.ozlabs.org ]
>
> Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine with
> many memory ranges. When hibernate on a machine with disjoint memory we do
> need one segment for each memory region. Increase this hard limit to 16K
> which is reasonably large.
>
> And change ->segment from a static array to a dynamically allocated memory.
>
> Cc: Neil Horman
> Cc: huang ying
> Cc: Eric W. Biederman
> Signed-off-by: WANG Cong
>
> ---
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> b/arch/powerpc/kernel/machine_kexec_64.c
> index ed31a29..f115585 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -131,10 +131,7 @@ static void copy_segments(unsigned long ind)
> void kexec_copy_flush(struct kimage *image)
> {
> long i, nr_segments = image->nr_segments;
> - struct kexec_segment ranges[KEXEC_SEGMENT_MAX];
> -
> - /* save the ranges on the stack to efficiently flush the icache */
> - memcpy(ranges, image->segment, sizeof(ranges));
> + struct kexec_segment range;
I'm glad you found our copy on the stack and removed the stack overflow
that comes with this bump, but ...
>
> /*
>* After this call we may not use anything allocated in dynamic
> @@ -148,9 +145,11 @@ void kexec_copy_flush(struct kimage *image)
>* we need to clear the icache for all dest pages sometime,
>* including ones that were in place on the original copy
>*/
> - for (i = 0; i < nr_segments; i++)
> - flush_icache_range((unsigned long)__va(ranges[i].mem),
> - (unsigned long)__va(ranges[i].mem + ranges[i].memsz));
> + for (i = 0; i < nr_segments; i++) {
> + memcpy(&range, &image->segment[i], sizeof(range));
> + flush_icache_range((unsigned long)__va(range.mem),
> + (unsigned long)__va(range.mem + range.memsz));
> + }
> }
This is executed after the copy, so as it says,
"we may not use anything allocated in dynamic memory".
We could allocate control pages to copy the segment list into.
Actually ppc64 doesn't use the existing control page, but that
is only 4kB today.
We need the list to icache flush all the pages in all the segments.
The as the indirect list doesn't have pages that were allocated at
their destination.
Or maybe the icache flush should be done in the generic code
like it does for crash load segments?
>
> #ifdef CONFIG_SMP
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 03e8e8d..26b70ff 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -57,7 +57,7 @@ typedef unsigned long kimage_entry_t;
> #define IND_DONE 0x4
> #define IND_SOURCE 0x8
>
> -#define KEXEC_SEGMENT_MAX 16
> +#define KEXEC_SEGMENT_MAX (1024*16)
> struct kexec_segment {
> void __user *buf;
> size_t bufsz;
> @@ -86,7 +86,7 @@ struct kimage {
> struct page *swap_page;
>
> unsigned long nr_segments;
> - struct kexec_segment segment[KEXEC_SEGMENT_MAX];
> + struct kexec_segment *segment;
>
> struct list_head control_pages;
> struct list_head dest_pages;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 131b170..3f97309 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -131,6 +131,11 @@ static int do_kimage_alloc(struct kimage **rimage,
> unsigned long entry,
> if (!image)
> goto out;
>
> + image->segment = kzalloc(nr_segments * sizeof(struct kexec_segment),
> + GFP_KERNEL);
> + if (!image->segment)
> + goto out;
> +
> image->head = 0;
> image->entry = &image->head;
> image->last_entry = &image->head;
> @@ -216,8 +221,10 @@ static int do_kimage_alloc(struct kimage **rimage,
> unsigned long entry,
> out:
> if (result == 0)
> *rimage = image;
> - else
> + else if (image) {
> + kfree(image->segment);
> kfree(image);
> + }
>
> return result;
>
> @@ -261,8 +268,10 @@ static int kimage_normal_alloc(struct kimage **rimage,
> unsigned long entry,
> out:
> if (result == 0)
> *rimage = image;
> - else
> + else if (image) {
> + kfree(image->segment);
> kfree(image);
> + }
>
> return result;
> }
> @@ -330,8 +339,10 @@ static int kimage_crash_alloc(struct kimage **rimage,
> unsigned long entry,
> out:
> if (result == 0)
> *rimage = image;
> - else
> + else if (image) {
> + kfree(image->segment);
> kfree(image);
> + }
>
> return result;
> }
> @@ -656,6 +667,7 @@ static void kimage_free(struct kimage *image)
>
> /* Free the kexec control pages... */
> kimage_free_page_list(&image->control_pages);
> + kfree(image->segment);
> kfree(image);
> }
>
milton
__
Re: Where are logical memory block regions setup?
On Mon, 2010-07-26 at 22:52 -0400, Rick Ramstetter wrote: > Hi all, > > Where can I find the code that sets values in lmb.reserved.region[i]? > This is in reference to 2.6.27's arch/powerpc/mm/mem.c and > include/linux/lmb.h > > I'm looking specifically for code that sets lmb_region's region.size > and region.base. They come from the reserve map in the device-tree, plus possible additional calls to lmb_reserve. Do a grep -r lmb_reserve arch/powerpc and you should find it all. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
On Mon, Jul 26, 2010 at 11:23 PM, Neil Horman wrote: > On Tue, Jul 13, 2010 at 09:46:09AM -0400, Neil Horman wrote: >> Hey all- >> About 2 years ago now, I sent this patch upstream to allow makedumpfile >> to properly filter cores on ppc64: >> http://www.mail-archive.com/ke...@lists.infradead.org/msg02426.html >> It got acks from the kexec folks so I pulled it into RHEL, but I never >> checked >> back here to make sure it ever made it in, which apparently it didn't. It >> still >> needs to be included, so I'm reposting it here, making sure to copy all the >> ppc >> folks this time. I've retested it on the latest linus kernel and it works >> fine, >> allowing makedumpfile to find all the symbols it needs to properly strip a >> vmcore on ppc64. >> >> Neil >> >> Signed-off-by: Neil Horman >> > Ping, anyone want to chime in on this, its needed for dump filtering to work > properly on ppc64 This patch looks good for me. Reviewed-by: WANG Cong Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/kexec: Fix orphaned offline CPUs across kexec
When CPU hotplug is used, some CPUs may be offline at the time a kexec is
performed. The subsequent kernel may expect these CPUs to be already running,
and will declare them stuck. On pseries, there's also a soft-offline (cede)
state that CPUs may be in; this can also cause problems as the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
This patch kicks each present offline CPU awake before the kexec, so that
none are lost to these assumptions in the subsequent kernel.
Signed-off-by: Matt Evans
---
arch/powerpc/kernel/machine_kexec_64.c | 42 +++
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 4fbb3be..c2fd914 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -181,7 +183,7 @@ static void kexec_prepare_cpus_wait(int wait_state)
int my_cpu, i, notified=-1;
my_cpu = get_cpu();
- /* Make sure each CPU has atleast made it to the state we need */
+ /* Make sure each CPU has at least made it to the state we need. */
for_each_online_cpu(i) {
if (i == my_cpu)
continue;
@@ -189,9 +191,9 @@ static void kexec_prepare_cpus_wait(int wait_state)
while (paca[i].kexec_state < wait_state) {
barrier();
if (i != notified) {
- printk( "kexec: waiting for cpu %d (physical"
- " %d) to enter %i state\n",
- i, paca[i].hw_cpu_id, wait_state);
+ printk(KERN_INFO "kexec: waiting for cpu %d "
+ "(physical %d) to enter %i state\n",
+ i, paca[i].hw_cpu_id, wait_state);
notified = i;
}
}
@@ -199,9 +201,32 @@ static void kexec_prepare_cpus_wait(int wait_state)
mb();
}
-static void kexec_prepare_cpus(void)
+/*
+ * We need to make sure each present CPU is online. The next kernel will scan
+ * the device tree and assume primary threads are online and query secondary
+ * threads via RTAS to online them if required. If we don't online primary
+ * threads, they will be stuck. However, we also online secondary threads as
we
+ * may be using 'cede offline'. In this case RTAS doesn't see the secondary
+ * threads as offline -- and again, these CPUs will be stuck.
+ *
+ * So, we online all CPUs that should be running, including secondary threads.
+ */
+static void wake_offline_cpus(void)
{
+ int cpu = 0;
+ for_each_present_cpu(cpu) {
+ if (!cpu_online(cpu)) {
+ printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
+ cpu);
+ cpu_up(cpu);
+ }
+ }
+}
+
+static void kexec_prepare_cpus(void)
+{
+ wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
local_irq_disable();
mb(); /* make sure IRQs are disabled before we say they are */
@@ -215,7 +240,10 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
- /* Before removing MMU mapings make sure all CPUs have entered real
mode */
+ /*
+* Before removing MMU mappings make sure all CPUs have entered real
+* mode:
+*/
kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
put_cpu();
@@ -284,6 +312,8 @@ void default_machine_kexec(struct kimage *image)
if (crashing_cpu == -1)
kexec_prepare_cpus();
+ pr_debug("kexec: Starting switchover sequence.\n");
+
/* switch to a staticly allocated stack. Based on irq stack code.
* XXX: the task struct will likely be invalid once we do the copy!
*/
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Memory Mapping a char array in User Space
Hi David, Thanks for the quick reply. One more thing, in the end I have to memory map a DMA buffer allocated using pci_alloc_consisten() function to user space. *> I think you should be leaving the mapping to the core VM routines.* *> Furthermore, I don't think *you* should be calling remap_pfn_range().* Let say I have allocated a page using __get_free_pages(). But how would the core VM routines knows that which page I want to memory map? If possible, please explain with example. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Memory Mapping DMA Buffers in User Space
Hi, I am new to linux device driver development and I'm trying to learn the memory mapping. Currently I am trying to memory map a dma buffer allocated using pci_alloc_consistent() function. Now what exactly I want is that whenever I map a char device from user space program, let say /dev/test, internally that DMA buffer gets memory mapped to the user space? Also what should I pass as the length parameter in the mmap() function? Thanks in advance Ravi Gupta ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
