* Re: [PATCH 0/2 v1.04] Add support for DWC OTG driver.
From: Fushen Chen @ 2010-07-29 16:26 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20100729030559.GA16667@suse.de>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
> [PATCH 1/2 v1.04]
> 1. License information is under clarification.
I meant that APM is still working with Synopys to resolve the GPL License.
There is no result yet.
I'll change this line to "License issue is resolved." if that happens.
I modified other part of the patch according to other reviewer's comment.
Thanks,
Fushen
On Wed, Jul 28, 2010 at 8:05 PM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Jul 28, 2010 at 05:28:41PM -0700, Fushen Chen wrote:
> > [PATCH 1/2 v1.04]
> > 1. License information is under clarification.
>
> What do you mean by this? I fail to see a change here, why just repost
> the same code again?
>
> What is being done to resolve the issues I outlined previously?
>
> greg k-h
>
[-- Attachment #2: Type: text/html, Size: 1084 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] regulator: Remove owner field from attribute initialization in regulator core driver
From: Mark Brown @ 2010-07-29 17:15 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nick Cheng, Jani Nikula, Linus Walleij, James Smart, linuxppc-dev,
Eric W. Biederman, Greg Kroah-Hartman, linux-kernel, Chris Wright,
Tejun Heo, James E.J. Bottomley, Richard Purdie, Alex Iannicelli,
Dmitry Torokhov, Jean Delvare, Paul Mackerras, Benjamin Thery,
linux-scsi, Liam Girdwood
In-Reply-To: <1280380166-29196-5-git-send-email-guenter.roeck@ericsson.com>
On Wed, Jul 28, 2010 at 10:09:24PM -0700, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* Re: [PATCH 0/2 v1.04] Add support for DWC OTG driver.
From: Greg KH @ 2010-07-29 17:22 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <AANLkTik35G2Th-1jN3jtx3Mn-rPNNfe3CDQgCdijHG8z@mail.gmail.com>
On Thu, Jul 29, 2010 at 09:26:12AM -0700, Fushen Chen wrote:
> > [PATCH 1/2 v1.04]
> > 1. License information is under clarification.
>
> I meant that APM is still working with Synopys to resolve the GPL License.
> There is no result yet.
Then I would be very careful in posting the code like you have done. As
it is, the code is not something that can be legally posted or used in
any device, and you might be held liable for it :(
good luck,
greg k-h
^ permalink raw reply
* [PATCH] of: Provide default of_node_to_nid() implementation.
From: Grant Likely @ 2010-07-29 19:04 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
of_node_to_nid() is only relevant in a few architectures. Don't force
everyone to implement it anyway.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
v3: make -1 the default return value and let powerpc override it to 0 when
CONFIG_NUMA not set.
arch/microblaze/include/asm/topology.h | 10 ----------
arch/powerpc/include/asm/prom.h | 7 +++++++
arch/powerpc/include/asm/topology.h | 7 -------
arch/sparc/include/asm/prom.h | 3 +--
include/linux/of.h | 5 +++++
5 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/microblaze/include/asm/topology.h b/arch/microblaze/include/asm/topology.h
index 96bcea5..5428f33 100644
--- a/arch/microblaze/include/asm/topology.h
+++ b/arch/microblaze/include/asm/topology.h
@@ -1,11 +1 @@
#include <asm-generic/topology.h>
-
-#ifndef _ASM_MICROBLAZE_TOPOLOGY_H
-#define _ASM_MICROBLAZE_TOPOLOGY_H
-
-struct device_node;
-static inline int of_node_to_nid(struct device_node *device)
-{
- return 0;
-}
-#endif /* _ASM_MICROBLAZE_TOPOLOGY_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index da7dd63..55bccc0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -103,6 +103,13 @@ struct device_node *of_find_next_cache_node(struct device_node *np);
/* Get the MAC address */
extern const void *of_get_mac_address(struct device_node *np);
+#ifdef CONFIG_NUMA
+extern int of_node_to_nid(struct device_node *device);
+#else
+static inline int of_node_to_nid(struct device_node *device) { return 0; }
+#endif
+#define of_node_to_nid of_node_to_nid
+
/**
* of_irq_map_pci - Resolve the interrupt for a PCI device
* @pdev: the device whose interrupt is to be resolved
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 32adf72..09dd38c 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -41,8 +41,6 @@ static inline int cpu_to_node(int cpu)
cpu_all_mask : \
node_to_cpumask_map[node])
-int of_node_to_nid(struct device_node *device);
-
struct pci_bus;
#ifdef CONFIG_PCI
extern int pcibus_to_node(struct pci_bus *bus);
@@ -94,11 +92,6 @@ extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
#else
-static inline int of_node_to_nid(struct device_node *device)
-{
- return 0;
-}
-
static inline void dump_numa_cpu_topology(void) {}
static inline int sysfs_add_device_to_node(struct sys_device *dev, int nid)
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index c82a7da..291f125 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -43,8 +43,7 @@ extern int of_getintprop_default(struct device_node *np,
extern int of_find_in_proplist(const char *list, const char *match, int len);
#ifdef CONFIG_NUMA
extern int of_node_to_nid(struct device_node *dp);
-#else
-#define of_node_to_nid(dp) (-1)
+#define of_node_to_nid of_node_to_nid
#endif
extern void prom_build_devicetree(void);
diff --git a/include/linux/of.h b/include/linux/of.h
index b0756f3..cad7cf0 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -146,6 +146,11 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
#define OF_BAD_ADDR ((u64)-1)
+#ifndef of_node_to_nid
+static inline int of_node_to_nid(struct device_node *np) { return -1; }
+#define of_node_to_nid of_node_to_nid
+#endif
+
extern struct device_node *of_find_node_by_name(struct device_node *from,
const char *name);
#define for_each_node_by_name(dn, name) \
^ permalink raw reply related
* [PATCH] of/address: Clean up function declarations
From: Grant Likely @ 2010-07-29 19:04 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
This patch moves the declaration of of_get_address(), of_get_pci_address(),
and of_pci_address_to_resource() out of arch code and into the common
linux/of_address header file.
This patch also fixes some of the asm/prom.h ordering issues. It still
includes some header files that it ideally shouldn't be, but at least the
ordering is consistent now so that of_* overrides work.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/microblaze/include/asm/prom.h | 33 +++++++-------------
arch/powerpc/include/asm/prom.h | 49 +++++++----------------------
arch/powerpc/kernel/legacy_serial.c | 1 +
arch/powerpc/kernel/pci-common.c | 1 +
arch/powerpc/platforms/52xx/lite5200.c | 1 +
arch/powerpc/platforms/amigaone/setup.c | 3 +-
arch/powerpc/platforms/iseries/mf.c | 1 +
arch/powerpc/platforms/powermac/feature.c | 2 +
drivers/char/bsr.c | 1 +
drivers/net/fsl_pq_mdio.c | 1 +
drivers/net/xilinx_emaclite.c | 2 +
drivers/serial/uartlite.c | 1 +
drivers/spi/mpc512x_psc_spi.c | 1 +
drivers/spi/mpc52xx_psc_spi.c | 1 +
drivers/spi/xilinx_spi_of.c | 1 +
drivers/usb/gadget/fsl_qe_udc.c | 1 +
drivers/video/controlfb.c | 2 +
drivers/video/offb.c | 3 +-
include/linux/of_address.h | 32 +++++++++++++++++++
19 files changed, 74 insertions(+), 63 deletions(-)
diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h
index cb9c3dd..101fa09 100644
--- a/arch/microblaze/include/asm/prom.h
+++ b/arch/microblaze/include/asm/prom.h
@@ -20,11 +20,6 @@
#ifndef __ASSEMBLY__
#include <linux/types.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/of_fdt.h>
-#include <linux/proc_fs.h>
-#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/atomic.h>
@@ -52,25 +47,9 @@ extern void pci_create_OF_bus_map(void);
* OF address retreival & translation
*/
-/* Extract an address from a device, returns the region size and
- * the address space flags too. The PCI version uses a BAR number
- * instead of an absolute index
- */
-extern const u32 *of_get_address(struct device_node *dev, int index,
- u64 *size, unsigned int *flags);
-extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
- u64 *size, unsigned int *flags);
-
-extern int of_pci_address_to_resource(struct device_node *dev, int bar,
- struct resource *r);
-
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
-#else
-static inline unsigned long pci_address_to_pio(phys_addr_t address)
-{
- return (unsigned long)-1;
-}
+#define pci_address_to_pio pci_address_to_pio
#endif /* CONFIG_PCI */
/* Parse the ibm,dma-window property of an OF node into the busno, phys and
@@ -99,8 +78,18 @@ extern const void *of_get_mac_address(struct device_node *np);
* resolving using the OF tree walking.
*/
struct pci_dev;
+struct of_irq;
extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
+
+/* These includes are put at the bottom because they may contain things
+ * that are overridden by this file. Ideally they shouldn't be included
+ * by this file, but there are a bunch of .c files that currently depend
+ * on it. Eventually they will be cleaned up. */
+#include <linux/of_fdt.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
#endif /* _ASM_MICROBLAZE_PROM_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index 55bccc0..ae26f2e 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -17,11 +17,6 @@
* 2 of the License, or (at your option) any later version.
*/
#include <linux/types.h>
-#include <linux/of_fdt.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/proc_fs.h>
-#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/atomic.h>
@@ -49,41 +44,9 @@ extern void pci_create_OF_bus_map(void);
extern u64 of_translate_dma_address(struct device_node *dev,
const u32 *in_addr);
-/* Extract an address from a device, returns the region size and
- * the address space flags too. The PCI version uses a BAR number
- * instead of an absolute index
- */
-extern const u32 *of_get_address(struct device_node *dev, int index,
- u64 *size, unsigned int *flags);
-#ifdef CONFIG_PCI
-extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
- u64 *size, unsigned int *flags);
-#else
-static inline const u32 *of_get_pci_address(struct device_node *dev,
- int bar_no, u64 *size, unsigned int *flags)
-{
- return NULL;
-}
-#endif /* CONFIG_PCI */
-
-#ifdef CONFIG_PCI
-extern int of_pci_address_to_resource(struct device_node *dev, int bar,
- struct resource *r);
-#else
-static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
- struct resource *r)
-{
- return -ENOSYS;
-}
-#endif /* CONFIG_PCI */
-
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
-#else
-static inline unsigned long pci_address_to_pio(phys_addr_t address)
-{
- return (unsigned long)-1;
-}
+#define pci_address_to_pio pci_address_to_pio
#endif /* CONFIG_PCI */
/* Parse the ibm,dma-window property of an OF node into the busno, phys and
@@ -122,9 +85,19 @@ static inline int of_node_to_nid(struct device_node *device) { return 0; }
* resolving using the OF tree walking.
*/
struct pci_dev;
+struct of_irq;
extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
extern void of_instantiate_rtc(void);
+/* These includes are put at the bottom because they may contain things
+ * that are overridden by this file. Ideally they shouldn't be included
+ * by this file, but there are a bunch of .c files that currently depend
+ * on it. Eventually they will be cleaned up. */
+#include <linux/of_fdt.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
#endif /* __KERNEL__ */
#endif /* _POWERPC_PROM_H */
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 035ada5..c1fd0f9 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -4,6 +4,7 @@
#include <linux/serial_core.h>
#include <linux/console.h>
#include <linux/pci.h>
+#include <linux/of_address.h>
#include <linux/of_device.h>
#include <asm/io.h>
#include <asm/mmu.h>
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 5b38f6a..9021c4a 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -21,6 +21,7 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/bootmem.h>
+#include <linux/of_address.h>
#include <linux/mm.h>
#include <linux/list.h>
#include <linux/syscalls.h>
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 6d584f4..de55bc0 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>
#include <asm/time.h>
diff --git a/arch/powerpc/platforms/amigaone/setup.c b/arch/powerpc/platforms/amigaone/setup.c
index fb4eb0d..03aabc0 100644
--- a/arch/powerpc/platforms/amigaone/setup.c
+++ b/arch/powerpc/platforms/amigaone/setup.c
@@ -13,12 +13,13 @@
*/
#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/seq_file.h>
#include <generated/utsrelease.h>
#include <asm/machdep.h>
#include <asm/cputable.h>
-#include <asm/prom.h>
#include <asm/pci-bridge.h>
#include <asm/i8259.h>
#include <asm/time.h>
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index d2c1d49..33e5fc7 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -30,6 +30,7 @@
#include <linux/init.h>
#include <linux/completion.h>
#include <linux/delay.h>
+#include <linux/proc_fs.h>
#include <linux/dma-mapping.h>
#include <linux/bcd.h>
#include <linux/rtc.h>
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index 9e1b9fd..75eec03 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -21,6 +21,8 @@
#include <linux/delay.h>
#include <linux/kernel.h>
#include <linux/sched.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/spinlock.h>
#include <linux/adb.h>
#include <linux/pmu.h>
diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index 89d871e..9191713 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -23,6 +23,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
+#include <linux/fs.h>
#include <linux/module.h>
#include <linux/cdev.h>
#include <linux/list.h>
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index b4c41d7..f53f850 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -35,6 +35,7 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_mdio.h>
#include <linux/of_platform.h>
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index d04c5b2..b2c2f39 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -20,7 +20,7 @@
#include <linux/skbuff.h>
#include <linux/io.h>
#include <linux/slab.h>
-
+#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
#include <linux/of_mdio.h>
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 8acccd5..caf085d 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -21,6 +21,7 @@
#include <asm/io.h>
#if defined(CONFIG_OF) && (defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE))
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
diff --git a/drivers/spi/mpc512x_psc_spi.c b/drivers/spi/mpc512x_psc_spi.c
index 1bb4315..10baac3 100644
--- a/drivers/spi/mpc512x_psc_spi.c
+++ b/drivers/spi/mpc512x_psc_spi.c
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/interrupt.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/workqueue.h>
#include <linux/completion.h>
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index bd81ff9..66d1701 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -16,6 +16,7 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/interrupt.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/workqueue.h>
#include <linux/completion.h>
diff --git a/drivers/spi/xilinx_spi_of.c b/drivers/spi/xilinx_spi_of.c
index 87cda09..f53d3f6 100644
--- a/drivers/spi/xilinx_spi_of.c
+++ b/drivers/spi/xilinx_spi_of.c
@@ -29,6 +29,7 @@
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/of_device.h>
#include <linux/of_spi.h>
diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c
index 82506ca..9648b75 100644
--- a/drivers/usb/gadget/fsl_qe_udc.c
+++ b/drivers/usb/gadget/fsl_qe_udc.c
@@ -32,6 +32,7 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/moduleparam.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/dma-mapping.h>
#include <linux/usb/ch9.h>
diff --git a/drivers/video/controlfb.c b/drivers/video/controlfb.c
index 49fcbe8..c225dcc 100644
--- a/drivers/video/controlfb.c
+++ b/drivers/video/controlfb.c
@@ -40,6 +40,8 @@
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/pci.h>
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index 46dda7d..cb163a5 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -19,13 +19,14 @@
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/interrupt.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/pci.h>
#include <asm/io.h>
-#include <asm/prom.h>
#ifdef CONFIG_PPC64
#include <asm/pci-bridge.h>
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index cc567df..8aea06f 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -8,5 +8,37 @@ extern int of_address_to_resource(struct device_node *dev, int index,
struct resource *r);
extern void __iomem *of_iomap(struct device_node *device, int index);
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern const u32 *of_get_address(struct device_node *dev, int index,
+ u64 *size, unsigned int *flags);
+
+#ifndef pci_address_to_pio
+static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
+#define pci_address_to_pio pci_address_to_pio
+#endif
+
+#ifdef CONFIG_PCI
+extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+ u64 *size, unsigned int *flags);
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r);
+#else /* CONFIG_PCI */
+static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r)
+{
+ return -ENOSYS;
+}
+
+static inline const u32 *of_get_pci_address(struct device_node *dev,
+ int bar_no, u64 *size, unsigned int *flags)
+{
+ return NULL;
+}
+#endif /* CONFIG_PCI */
+
+
#endif /* __OF_ADDRESS_H */
^ permalink raw reply related
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Wolfgang Denk @ 2010-07-29 21:20 UTC (permalink / raw)
To: galak, Kim Phillips; +Cc: linuxppc-dev, Ilya Yanok
In-Reply-To: <4C48B384.1020006@emcraft.com>
Dear Kumar & Kim,
any comments on this issue?
Thanks.
In message <4C48B384.1020006@emcraft.com> Ilya Yanok wrote:
> Hi Kumar, Kim, Josh, everybody,
>
> I hope to disturb you but I haven't got any reply for my first posting...
>
> I've found that MSI work correctly with older kernels on my MPC8308RDB
> board and don't work with newer ones. After bisecting I've found that
> the source of the problem is commit 3da34aa:
>
> commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> Author: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue May 12 15:51:56 2009 -0500
>
> powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
>
> Its feasible based on how the PCI address map is setup that the region
> of PCI address space used for MSIs differs for each PHB on the same
> SoC.
>
> Instead of assuming that the address mappes to CCSRBAR 1:1 we read
> PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx
> neigher in the kernel nor in U-Boot (that makes me think that all 83xx
> can be affected).
> I'm not actually an PCI expert so I've just tried to write IMMR base
> address to the BAR0 register from the U-Boot to get the correct address
> but this doesn't help.
> Please direct me how to init 83xx PCIE controller to make it compatible
> with this patch.
>
> Kim, I think MPC8315E is affected too, could you please test it?
>
> Thanks in advance.
>
> Regards, Ilya.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A good aphorism is too hard for the tooth of time, and is not worn
away by all the centuries, although it serves as food for every
epoch. - Friedrich Wilhelm Nietzsche
_Miscellaneous Maxims and Opinions_ no. 168
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Michael Neuling @ 2010-07-30 0:08 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <4C511216.30109@ozlabs.org>
In message <4C511216.30109@ozlabs.org> you wrote:
> 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.
There are a lot of cleanups in this patch. The change you are making
would be a lot clearer without all the additional cleanups in there. I
think I'd like to see this as two patches. One for cleanups and one for
the addition of wake_offline_cpus().
Other than that, I'm not completely convinced this is the functionality
we want. Do we really want to online these cpus? Why where they
offlined in the first place? I understand the stuck problem, but is the
solution to online them, or to change the device tree so that the second
kernel doesn't detect them as stuck?
Mikey
>
> Signed-off-by: Matt Evans <matt@ozlabs.org>
> ---
> v2: Added FIXME comment noting a possible problem with incorrectly
> started secondary CPUs, following feedback from Milton.
>
> arch/powerpc/kernel/machine_kexec_64.c | 55 ++++++++++++++++++++++++++++--
-
> 1 files changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/mac
hine_kexec_64.c
> index 4fbb3be..37f805e 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -15,6 +15,8 @@
> #include <linux/thread_info.h>
> #include <linux/init_task.h>
> #include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/cpu.h>
>
> #include <asm/page.h>
> #include <asm/current.h>
> @@ -181,7 +183,20 @@ 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.
> + *
> + * FIXME: There is a (slim) chance of a problem if not all of the CPUs
> + * are correctly onlined. If somehow we start a CPU on boot with RTAS
> + * start-cpu, but somehow that CPU doesn't write callin_cpu_map[] in
> + * time, the boot CPU will timeout. If it does eventually execute
> + * stuff, the secondary will start up (paca[].cpu_start was written) an
d
> + * get into a peculiar state. If the platform supports
> + * smp_ops->take_timebase(), the secondary CPU will probably be spinnin
g
> + * in there. If not (i.e. pseries), the secondary will continue on and
> + * try to online itself/idle/etc. If it survives that, we need to find
> + * these possible-but-not-online-but-should-be CPUs and chaperone them
> + * into kexec_smp_wait().
> + */
> for_each_online_cpu(i) {
> if (i == my_cpu)
> continue;
> @@ -189,9 +204,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 +214,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 sc
an
> + * 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 a
s 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 thread
s.
> + */
> +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 +253,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 mod
e */
> + /*
> + * Before removing MMU mappings make sure all CPUs have entered real
> + * mode:
> + */
> kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
>
> put_cpu();
> @@ -284,6 +325,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
>
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 0:14 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100726231616.GA25342@suse.de>
Hi Greg:
We will change to a BSD 3 clause license header. Our legal counsel is
talking to Synopsis to make this change. We will resubmit once this
is in place. Please let me know if you have any additional concerns.
Feng Kan
Applied Micro
On Mon, Jul 26, 2010 at 4:16 PM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Jul 26, 2010 at 04:05:49PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> We are having our legal revisit this again. What would you advise us
>> to do at this point?
>
> I thought I was very clear below as to what is needed.
>
>> Disclose the agreement or have someone with legal authority reply this
>> thread.
>
> Neither will resolve the end issue, right?
>
>> Perhaps something in the header that states Applied Micro verified
>> with Synopsys to use this code for GPL purpose.
>
> No, that will just make it messier. =C2=A0Someone needs to delete all of =
the
> mess in the file, put the proper license information for what the code
> is being licensed under (whatever it is), and provide a signed-off-by
> from a person from Synopsys and APM that can speak for the company that
> they agree that the code can properly be placed into the Linux kernel.
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Matt Evans @ 2010-07-30 0:41 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <3296.1280448512@neuling.org>
Michael Neuling wrote:
> In message <4C511216.30109@ozlabs.org> you wrote:
>> 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.
>
> There are a lot of cleanups in this patch. The change you are making
> would be a lot clearer without all the additional cleanups in there. I
> think I'd like to see this as two patches. One for cleanups and one for
> the addition of wake_offline_cpus().
Okay, I can split this. Typofixy-add-debug in one, wake_offline_cpus in another.
> Other than that, I'm not completely convinced this is the functionality
> we want. Do we really want to online these cpus? Why where they
> offlined in the first place? I understand the stuck problem, but is the
> solution to online them, or to change the device tree so that the second
> kernel doesn't detect them as stuck?
Well... There are two cases. If a CPU is soft-offlined on pseries, it must be woken from that cede loop (in platforms/pseries/hotplug-cpu.c) as we're replacing code under its feet. We could either special-case the wakeup from this cede loop to get that CPU to RTAS "stop-self" itself properly. (Kind of like a "wake to die".)
So that leaves hard-offline CPUs (perhaps including the above): I don't know why they might have been offlined. If it's something serious, like fire, they'd be removed from the present set too (and thus not be considered in this restarting case). We could add a mask to the CPU node to show which of the threads (if any) are running, and alter the startup code to start everything if this mask doesn't exist (non-kexec) or only online currently-running threads if the mask is present. That feels a little weird.
My reasoning for restarting everything was: The first time you boot, all of your present CPUs are started up. When you reboot, any CPUs you offlined for fun are restarted. Kexec is (in this non-crash sense) a user-initiated 'quick reboot', so I reasoned that it should look the same as a 'hard reboot' and your new invocation would have all available CPUs running as is usual.
Cheers,
Matt
^ permalink raw reply
* Re: [PATCH 0/2 v1.04] Add support for DWC OTG driver.
From: David Daney @ 2010-07-30 0:42 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, linux-usb, gregkh
In-Reply-To: <12803633233020-git-send-email-fchen@apm.com>
On 07/28/2010 05:28 PM, Fushen Chen wrote:
> [PATCH 1/2 v1.04]
.
.
.
PATCH 1/2 seems to not have made it to linux-usb@vger.kernel.org. I
suspect that a spam filter got it.
Could you remove whatever there is in the patch that triggers the
filter? Or failing that, change the filter so we can all see the patch?
Thanks,
David Daney
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 0:50 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTikDpxcOj=TgD5697HOzPOanECGd4G6QaXZmoS98@mail.gmail.com>
On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We will change to a BSD 3 clause license header. Our legal counsel is
> talking to Synopsis to make this change.
Why BSD? You do realize what that means when combined within the body
of the kernel, right?
Are you going to be expecting others to contribute back to the code
under this license, or will you accept the fact that future
contributions from the community will cause the license to change?
> We will resubmit once this is in place. Please let me know if you have
> any additional concerns.
My main concern is that you, and everyone else involved in the driver,
never considered the license of the code in the first place and expected
the kernel community to accept it as-is, placing the problem on us.
What will be done in the future to prevent this from happening again?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 1:19 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730005045.GB22683@suse.de>
Hi Greg:
On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> We will change to a BSD 3 clause license header. Our legal counsel is
>> talking to Synopsis to make this change.
>
> Why BSD? =C2=A0You do realize what that means when combined within the bo=
dy
> of the kernel, right?
>
FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
Hil driver.
> Are you going to be expecting others to contribute back to the code
> under this license, or will you accept the fact that future
> contributions from the community will cause the license to change?
>
>> We will resubmit once this is in place. Please let me know if you have
>> any additional concerns.
>
> My main concern is that you, and everyone else involved in the driver,
> never considered the license of the code in the first place and expected
> the kernel community to accept it as-is, placing the problem on us.
FKAN: Please don't think this is the case, we gone through this exercise
with Denx. We had legal looking into the header before submission
to them and the kernel.
>
> What will be done in the future to prevent this from happening again?
FKAN: agreed, once bitten .... :)
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: David Gibson @ 2010-07-30 1:23 UTC (permalink / raw)
To: Matthew McClintock; +Cc: Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <1279211961.31679.11.camel@localhost>
On Thu, Jul 15, 2010 at 11:39:21AM -0500, Matthew McClintock wrote:
> On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
> > > Thanks for taking a look. My first thought was to just blow away all
> > the
> > > memreserve regions and start over. But, there are reserve regions
> > for
> > > other things that I might not want to blow away. For example, on
> > mpc85xx
> > > SMP systems we have an additional reserve region for our boot page.
> >
> > What is your starting point? Where does the device tree (and
> > memreserve list) come from
> > that you're passing to kexec? My first impression is that if you have
> > to scrub the memreserve list, then the source being used to
> > obtain the memreserves is either faulty or unsuitable to the task.
>
> I'm pulling the device tree passed in via u-boot and passing it to
> kexec. It is the most complete device tree and requires the least amount
> of fixup.
>
> I have to scrub two items, the ramdisk/initrd and the device tree
> because upon kexec'ing the kernel we have the ability to pass in new
> ramdisk/initrd and device tree. They can also live at different
> physical addresses for the second reboot.
> The initrd addresses are already exposed, so we can
> update/remove/reuse that entry, we just need a way for kexec to
> determine the current device tree address so it can replace the
> correct memreserve region for the kexec'ing kernels' device tree.
Ok, be careful with this. You do have the information you need, but
you might have to split an existing entry. Having a single reserve
entry to cover the initrd would be typical, but it doesn't have to
happen that way - e.g. if a firmware reserves a big region for its own
purposes, and places the initrd within that region.
Also, the latest specs do *not* require the device tree itself to be
mem reserved.
> The whole problem comes from repeatedly kexec'ing, we need to make
> sure we don't keep losing blobs of memory to reserve regions (so we
> can't just blindly add). We also need to make sure we don't lose
> other memreserve regions that might be important for other things
> (so we can't just blow them all away).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 1:26 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTikSH8_QXV2qsBR+vxsjvQwNdx2st3vfbRpfsMff@mail.gmail.com>
On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
> Hi Greg:
>
> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> >> Hi Greg:
> >>
> >> We will change to a BSD 3 clause license header. Our legal counsel is
> >> talking to Synopsis to make this change.
> >
> > Why BSD? You do realize what that means when combined within the body
> > of the kernel, right?
> >
>
> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
> Hil driver.
What specific driver is this?
And are you sure that all of the contributors to the code agree with
this licensing change? Are you going to require contributors to
dual-license their changes?
If so, why keep it BSD, what does that get you?
> > Are you going to be expecting others to contribute back to the code
> > under this license, or will you accept the fact that future
> > contributions from the community will cause the license to change?
You didn't answer this question, which is a very important one before I
can accept this driver.
> >> We will resubmit once this is in place. Please let me know if you have
> >> any additional concerns.
> >
> > My main concern is that you, and everyone else involved in the driver,
> > never considered the license of the code in the first place and expected
> > the kernel community to accept it as-is, placing the problem on us.
>
> FKAN: Please don't think this is the case, we gone through this exercise
> with Denx.
What is "Denx"?
> We had legal looking into the header before submission
> to them and the kernel.
Then what happened here? Just curious as to how the driver was public
for so long before someone realized this.
> > What will be done in the future to prevent this from happening again?
>
> FKAN: agreed, once bitten .... :)
That didn't answer the question :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: David Gibson @ 2010-07-30 1:38 UTC (permalink / raw)
To: Grant Likely
Cc: Mitch Bradley, Matthew McClintock, Kumar Gala, linuxppc-dev,
Timur Tabi
In-Reply-To: <AANLkTilDcYYbsH-6f0_HlX9WwaOwG24w1CfhRLplZKS7@mail.gmail.com>
On Thu, Jul 15, 2010 at 01:18:21PM -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@freescale.com> wrote:
> > On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
> >> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@freescale.com> wrote:
> >> > Yes. Where would we get a list of memreserve sections?
> >>
> >> I would say the list of reserves that are not under the control of
> >> Linux should be explicitly described in the device tree proper. For
> >> instance, if you have a region that firmware depends on, then have a
> >> node for describing the firmware and a property stating the memory
> >> regions that it depends on. The memreserve regions can be generated
> >> from that.
> >
> > Ok, so we could traverse the tree node-by-bode for a
> > persistent-memreserve property and add them to the /memreserve/ list in
> > the kexec user space tools?
Well.. I don't think it should be this way as a matter of spec. But
you could use a property as an interim stash for memreserve
information.
I agree that the precise defined semantics of the memreserve regions
is kind of fuzzy and non-obvious. Here's how I believe they need to
work:
memory in a reserved region must *never* be touched by the OS
(or subsequent kexec-invoked OSes) unless something else in the device
tree explicitly instructs it how
There already exist several mechanisms for instructing the OS to use
particular reserved regions for particular purposes: e.g. the initrd
properties, and the spin-table properties. More such mechanisms might
be added in future ePAPR (or whatever) revisions. But if the OS
version doesn't understand such a future mechanism, it must fall back
to assuming that the memory is reserved in perpetuity.
Now, some of these mechanisms (implicitly) permit the OS to re-use the
reserved memory after it's done using them as instructed (initrd is
the most obvious one). In that case the OS can re-add the reserved
space to it's general pools, and excise it from the reserved space for
subsequent kexec()-style boots. However that's (potentially) a more
complex process than just removing an entry - the initial firmware is
free to combine adjacent reserved regions into one reserve entry, or
even to cover a single reserved region with multiple entries. So in
order to do this manipulation you will need an allocator of sorts that
does the region reservation/dereservation correctly handling the
semantics on a byte-by-byte basis.
You should also be careful that the regions you're handling do
actually lie in memory space. Linux doesn't support this right now,
but I do have an experimental patch that allows the initrd properties
to point to (e.g.) flash instead of RAM. In that case the initrd
wouldn't have to lie in an explicitly reserved region, and obviously
could not be returned to the general pool after use.
> I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
> David Gibson, and other device tree experts on whether or not that
> exact property naming is a good one.
>
> Write up a proposed binding (you can use devicetree.org). Post it for
> review (make sure you cc: both devicetree-discuss and linuxppc-dev, as
> well as cc'ing the people listed above.)
>
> >> > Should we export
> >> > the reserve sections instead of the device tree location?
> >>
> >> It shouldn't really be something that the kernel is explicitly
> >> exporting because it is a characteristic of the board design. It is
> >> something that belongs in the tree-proper. ie. when you extract the
> >> tree you have data telling what the region is, and why it is reserved.
> >
> > Agreed.
> >
> >>
> >> > We just need a
> >> > way to preserve what was there at boot to pass to the new kernel.
> >>
> >> Yet there is no differentiation between the board-dictated memory
> >> reserves and the things that U-Boot/Linux made an arbitrary decision
> >> on. The solution should focus not on "can I throw this one away?" but
> >> rather "Is this one I should keep?" :-) A subtle difference, I know,
> >> but it changes the way you approach the solution.
> >
> > Fair enough. I think the above solution will work nicely, and I can
> > start implementing something if you agree - if I interpreted your idea
> > correctly. Although it should not require any changes to the kernel
> > proper.
>
> Correct.
>
> g.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 2:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730012650.GB24931@suse.de>
On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> We will change to a BSD 3 clause license header. Our legal counsel is
>> >> talking to Synopsis to make this change.
>> >
>> > Why BSD? =C2=A0You do realize what that means when combined within the=
body
>> > of the kernel, right?
>> >
>>
>> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hil driver.
>
> What specific driver is this?
FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> And are you sure that all of the contributors to the code agree with
> this licensing change? =C2=A0Are you going to require contributors to
> dual-license their changes?
>
> If so, why keep it BSD, what does that get you?
FKAN: for one thing, to make it future proof on other submissions.
>
>> > Are you going to be expecting others to contribute back to the code
>> > under this license, or will you accept the fact that future
>> > contributions from the community will cause the license to change?
>
>
> You didn't answer this question, which is a very important one before I
> can accept this driver.
FKAN: Yes, all of the above. Our legal is working on that. I thought by def=
ault
GPL defines the above statement.
>
>> >> We will resubmit once this is in place. Please let me know if you hav=
e
>> >> any additional concerns.
>> >
>> > My main concern is that you, and everyone else involved in the driver,
>> > never considered the license of the code in the first place and expect=
ed
>> > the kernel community to accept it as-is, placing the problem on us.
>>
>> FKAN: Please don't think this is the case, we gone through this exercise
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with Denx.
>
> What is "Denx"?
FKAN: U-Boot Denx.de
>
>> We had legal looking into the header before submission
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to them and the kernel.
>
> Then what happened here? =C2=A0Just curious as to how the driver was publ=
ic
> for so long before someone realized this.
>
FKAN: this was few years back. At the time we had the header changed
so it was BSD like to be accepted by Denx.
>> > What will be done in the future to prevent this from happening again?
>>
>> FKAN: agreed, once bitten .... :)
>
> That didn't answer the question :)
FKAN: we have a system of checks for every patch that goes out. I will send
out a guideline to all reviewer to make sure the header
follow kernel precedence.
Legal is quite aware of the issue now too.
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Michael Neuling @ 2010-07-30 3:15 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, kexec, Milton Miller
In-Reply-To: <4C521FD2.4050301@ozlabs.org>
(adding kexec list to CC)
In message <4C521FD2.4050301@ozlabs.org> you wrote:
> Michael Neuling wrote:
> > In message <4C511216.30109@ozlabs.org> you wrote:
> >> 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 runn
ing
> > ,
> >> and will declare them stuck. On pseries, there's also a soft-offline (ced
e)
> >> state that CPUs may be in; this can also cause problems as the kexeced ker
nel
> >> may ask RTAS if they're online -- and RTAS would say they are. Again, stu
ck.
> >>
> >> This patch kicks each present offline CPU awake before the kexec, so that
> >> none are lost to these assumptions in the subsequent kernel.
> >
> > There are a lot of cleanups in this patch. The change you are making
> > would be a lot clearer without all the additional cleanups in there. I
> > think I'd like to see this as two patches. One for cleanups and one for
> > the addition of wake_offline_cpus().
>
> Okay, I can split this. Typofixy-add-debug in one, wake_offline_cpus
> in another.
Thanks.
>
> > Other than that, I'm not completely convinced this is the functionality
> > we want. Do we really want to online these cpus? Why where they
> > offlined in the first place? I understand the stuck problem, but is the
> > solution to online them, or to change the device tree so that the second
> > kernel doesn't detect them as stuck?
>
> Well... There are two cases. If a CPU is soft-offlined on pseries, it
> must b e woken from that cede loop (in
> platforms/pseries/hotplug-cpu.c) as we're repla cing code under its
> feet. We could either special-case the wakeup from this ce de loop to
> get that CPU to RTAS "stop-self" itself properly. (Kind of like a "
> wake to die".)
Makes sense.
> So that leaves hard-offline CPUs (perhaps including the above): I
> don't know why they might have been offlined. If it's something
> serious, like fire, they'd be removed from the present set too (and
> thus not be considered in this restarting case). We could add a mask
> to the CPU node to show which of the threads (if any) are running, and
> alter the startup code to start everything if this mask doesn't exist
> (non-kexec) or only online currently-running threads if the mask is
> present. That feels a little weird.
>
> My reasoning for restarting everything was: The first time you boot,
> all of your present CPUs are started up. When you reboot, any CPUs
> you offlined for fun are restarted. Kexec is (in this non-crash
> sense) a user-initiated 'quick reboot', so I reasoned that it should
> look the same as a 'hard reboot' and your new invocation would have
> all available CPUs running as is usual.
OK, I like this justification. Would be good to include it in the
checkin comment since we're changing functionality somewhat.
Mikey
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 3:36 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTimiox6UbUnhSRLgC06S2kfcDOANA08gm3m++TXd@mail.gmail.com>
On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
> >> Hi Greg:
> >>
> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> >> >> Hi Greg:
> >> >>
> >> >> We will change to a BSD 3 clause license header. Our legal counsel is
> >> >> talking to Synopsis to make this change.
> >> >
> >> > Why BSD? ??You do realize what that means when combined within the body
> >> > of the kernel, right?
> >> >
> >>
> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
> >> ?? ?? ?? ?? ?? ??Hil driver.
> >
> > What specific driver is this?
>
> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
Ok, thanks.
Are you _sure_ that you didn't take any existing GPL code and put it
into this driver when making it? Did all contributors to the code
release their contributions under both licenses?
> > And are you sure that all of the contributors to the code agree with
> > this licensing change? ??Are you going to require contributors to
> > dual-license their changes?
> >
> > If so, why keep it BSD, what does that get you?
>
> FKAN: for one thing, to make it future proof on other submissions.
What do you mean by this? What can you do with this code other than use
it on a Linux system? You can't put it into any other operating system
with a different license, can you?
> >> > Are you going to be expecting others to contribute back to the code
> >> > under this license, or will you accept the fact that future
> >> > contributions from the community will cause the license to change?
> >
> >
> > You didn't answer this question, which is a very important one before I
> > can accept this driver.
>
> FKAN: Yes, all of the above. Our legal is working on that. I thought by default
> GPL defines the above statement.
The GPL does, but as you are trying to dual-license the code, you have
to be careful about how you accept changes, and under what license.
It's a lot more work than I think you realize. What process do you have
in place to handle this?
> >> >> We will resubmit once this is in place. Please let me know if you have
> >> >> any additional concerns.
> >> >
> >> > My main concern is that you, and everyone else involved in the driver,
> >> > never considered the license of the code in the first place and expected
> >> > the kernel community to accept it as-is, placing the problem on us.
> >>
> >> FKAN: Please don't think this is the case, we gone through this exercise
> >> ?? ?? ?? ?? ?? with Denx.
> >
> > What is "Denx"?
>
> FKAN: U-Boot Denx.de
Ah, thanks.
> >> We had legal looking into the header before submission
> >> ?? ?? ?? ?? ?? to them and the kernel.
> >
> > Then what happened here? ??Just curious as to how the driver was public
> > for so long before someone realized this.
> >
>
> FKAN: this was few years back. At the time we had the header changed
> so it was BSD like to be accepted by Denx.
>
> >> > What will be done in the future to prevent this from happening again?
> >>
> >> FKAN: agreed, once bitten .... :)
> >
> > That didn't answer the question :)
>
> FKAN: we have a system of checks for every patch that goes out. I will send
> out a guideline to all reviewer to make sure the header
> follow kernel precedence.
But you took this code from a different vendor, are you able to properly
identify the code contributions to this base and what license it is
under and where they got it from?
> Legal is quite aware of the issue now too.
As they should be :)
Please reconsider the dual licensing unless you really are ready to
handle the implications of it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Simon Horman @ 2010-07-30 3:25 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, kexec, Milton Miller, Matt Evans
In-Reply-To: <20694.1280459714@neuling.org>
On Fri, Jul 30, 2010 at 01:15:14PM +1000, Michael Neuling wrote:
> (adding kexec list to CC)
>
> In message <4C521FD2.4050301@ozlabs.org> you wrote:
> > Michael Neuling wrote:
> > > In message <4C511216.30109@ozlabs.org> you wrote:
> > >> 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 runn
> ing
> > > ,
> > >> and will declare them stuck. On pseries, there's also a soft-offline (ced
> e)
> > >> state that CPUs may be in; this can also cause problems as the kexeced ker
> nel
> > >> may ask RTAS if they're online -- and RTAS would say they are. Again, stu
> ck.
> > >>
> > >> This patch kicks each present offline CPU awake before the kexec, so that
> > >> none are lost to these assumptions in the subsequent kernel.
> > >
> > > There are a lot of cleanups in this patch. The change you are making
> > > would be a lot clearer without all the additional cleanups in there. I
> > > think I'd like to see this as two patches. One for cleanups and one for
> > > the addition of wake_offline_cpus().
> >
> > Okay, I can split this. Typofixy-add-debug in one, wake_offline_cpus
> > in another.
>
> Thanks.
>
> >
> > > Other than that, I'm not completely convinced this is the functionality
> > > we want. Do we really want to online these cpus? Why where they
> > > offlined in the first place? I understand the stuck problem, but is the
> > > solution to online them, or to change the device tree so that the second
> > > kernel doesn't detect them as stuck?
> >
> > Well... There are two cases. If a CPU is soft-offlined on pseries, it
> > must b e woken from that cede loop (in
> > platforms/pseries/hotplug-cpu.c) as we're repla cing code under its
> > feet. We could either special-case the wakeup from this ce de loop to
> > get that CPU to RTAS "stop-self" itself properly. (Kind of like a "
> > wake to die".)
>
> Makes sense.
>
> > So that leaves hard-offline CPUs (perhaps including the above): I
> > don't know why they might have been offlined. If it's something
> > serious, like fire, they'd be removed from the present set too (and
> > thus not be considered in this restarting case). We could add a mask
> > to the CPU node to show which of the threads (if any) are running, and
> > alter the startup code to start everything if this mask doesn't exist
> > (non-kexec) or only online currently-running threads if the mask is
> > present. That feels a little weird.
> >
> > My reasoning for restarting everything was: The first time you boot,
> > all of your present CPUs are started up. When you reboot, any CPUs
> > you offlined for fun are restarted. Kexec is (in this non-crash
> > sense) a user-initiated 'quick reboot', so I reasoned that it should
> > look the same as a 'hard reboot' and your new invocation would have
> > all available CPUs running as is usual.
>
> OK, I like this justification. Would be good to include it in the
> checkin comment since we're changing functionality somewhat.
FWIW, I do too. Personally I like to think of kexec as soft-reboot.
Where soft means, in software, not soft-touch.
^ permalink raw reply
* [PATCH 3/3 v2] mmc: Add ESDHC weird voltage bits workaround
From: Roy Zang @ 2010-07-30 3:52 UTC (permalink / raw)
To: linux-mmc; +Cc: linuxppc-dev, akpm
P4080 ESDHC controller does not support 1.8V and 3.0V voltage. but the
host controller capabilities register wrongly set the bits.
This patch adds the workaround to correct the weird voltage setting bits.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
This is the second version of patch
http://patchwork.ozlabs.org/patch/60106/
According to the comment, remove some un-necessary setting.
Together with patch
http://patchwork.ozlabs.org/patch/60111/
http://patchwork.ozlabs.org/patch/60116/
This serial patches add mmc support for p4080 silicon
drivers/mmc/host/sdhci-of-core.c | 4 ++++
drivers/mmc/host/sdhci.c | 8 ++++++++
drivers/mmc/host/sdhci.h | 4 ++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index 0c30242..1f3913d 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -164,6 +164,10 @@ 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_NO_VDD_180
+ |SDHCI_QUIRK_QORIQ_NO_VDD_300);
+
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..a667790 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1699,6 +1699,14 @@ int sdhci_add_host(struct sdhci_host *host)
caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+ /* Workaround for P4080 host controller capabilities
+ * 1.8V and 3.0V do not supported*/
+ if (host->quirks & SDHCI_QUIRK_QORIQ_NO_VDD_180)
+ caps &= ~SDHCI_CAN_VDD_180;
+
+ if (host->quirks & SDHCI_QUIRK_QORIQ_NO_VDD_300)
+ caps &= ~SDHCI_CAN_VDD_300;
+
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..389b58c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -243,6 +243,10 @@ 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 cannot support 1.8V */
+#define SDHCI_QUIRK_QORIQ_NO_VDD_180 (1<<28)
+/* Controller cannot support 3.0V */
+#define SDHCI_QUIRK_QORIQ_NO_VDD_300 (1<<29)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] powerpc/kexec: Fix orphaned offline CPUs, add comments/debug
From: Matt Evans @ 2010-07-30 4:44 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Michael Neuling, Milton Miller
Separated tidyup comments & debug away from the fix of restarting offline
available CPUs before waiting for them on kexec.
Matt Evans (2):
powerpc/kexec: Add to and tidy debug/comments in machine_kexec64.c
powerpc/kexec: Fix orphaned offline CPUs across kexec
arch/powerpc/kernel/machine_kexec_64.c | 55 ++++++++++++++++++++++++++++---
1 files changed, 49 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 1/2] powerpc/kexec: Add to and tidy debug/comments in machine_kexec64.c
From: Matt Evans @ 2010-07-30 4:47 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Michael Neuling, Milton Miller
In-Reply-To: <4C5258C8.1030305@ozlabs.org>
Tidies some typos, KERN_INFO-ise an info msg, and add a debug msg showing
when the final sequence starts.
Also adds a comment to kexec_prepare_cpus_wait() to make note of a possible
problem; the need for kexec to deal with CPUs that failed to originally start
up.
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/kernel/machine_kexec_64.c | 29 ++++++++++++++++++++++++-----
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 4fbb3be..aa3d5cd 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,7 @@
#include <linux/thread_info.h>
#include <linux/init_task.h>
#include <linux/errno.h>
+#include <linux/kernel.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -181,7 +182,20 @@ 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.
+ *
+ * FIXME: There is a (slim) chance of a problem if not all of the CPUs
+ * are correctly onlined. If somehow we start a CPU on boot with RTAS
+ * start-cpu, but somehow that CPU doesn't write callin_cpu_map[] in
+ * time, the boot CPU will timeout. If it does eventually execute
+ * stuff, the secondary will start up (paca[].cpu_start was written) and
+ * get into a peculiar state. If the platform supports
+ * smp_ops->take_timebase(), the secondary CPU will probably be spinning
+ * in there. If not (i.e. pseries), the secondary will continue on and
+ * try to online itself/idle/etc. If it survives that, we need to find
+ * these possible-but-not-online-but-should-be CPUs and chaperone them
+ * into kexec_smp_wait().
+ */
for_each_online_cpu(i) {
if (i == my_cpu)
continue;
@@ -189,9 +203,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;
}
}
@@ -215,7 +229,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 +301,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
^ permalink raw reply related
* [PATCH 2/2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Matt Evans @ 2010-07-30 4:49 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Michael Neuling, Milton Miller
In-Reply-To: <4C5258C8.1030305@ozlabs.org>
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. The CPU will
either appear stuck, or will cause a crash as we replace its cede loop beneath
it.
This patch kicks each present offline CPU awake before the kexec, so that
none are forever lost to these assumptions in the subsequent kernel.
Now, the behaviour is that all available CPUs that were offlined are now
online & usable after the kexec. This mimics the behaviour of a full reboot
(on which all CPUs will be restarted).
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/kernel/machine_kexec_64.c | 26 +++++++++++++++++++++++++-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index aa3d5cd..37f805e 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -16,6 +16,7 @@
#include <linux/init_task.h>
#include <linux/errno.h>
#include <linux/kernel.h>
+#include <linux/cpu.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -213,9 +214,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 */
--
1.6.3.3
^ permalink raw reply related
* Which microcode patch for MPC870?
From: Shawn Jin @ 2010-07-30 6:40 UTC (permalink / raw)
To: ppcdev
Hi,
Which microcode patch should be selected for MPC870? In the old 2.4
kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding
config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or
CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I
believe USB microcode is irrelevant here. So it comes down the other
two choices. Of course do I really need the patch? My board has I2C
and SMC1, but no SPI.
I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the
following compilation error:
CC arch/powerpc/sysdev/micropatch.o
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:629: error: expected '=', ',', ';',
'asm' or '__attribute__' before '*' token
arch/powerpc/sysdev/micropatch.c:629: error: 'spp' undeclared (first
use in this function)
arch/powerpc/sysdev/micropatch.c:629: error: (Each undeclared
identifier is reported only once
arch/powerpc/sysdev/micropatch.c:629: error: for each function it appears in.)
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c:630: warning: ISO C90 forbids mixed
declarations and code
arch/powerpc/sysdev/micropatch.c:671: error: 'spi_t' undeclared (first
use in this function)
arch/powerpc/sysdev/micropatch.c:671: error: expected expression
before ')' token
arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
Obviously there is no spi_t declaration in 2.6.33.5. So where is this
spi_t declared?
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: Which microcode patch for MPC870?
From: Anton Vorontsov @ 2010-07-30 6:45 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTimBP98EwRuvU_dj-RM2kaXZ-FSZ=GQxdod9VQeU@mail.gmail.com>
Hello,
On Thu, Jul 29, 2010 at 11:40:21PM -0700, Shawn Jin wrote:
> Hi,
>
> Which microcode patch should be selected for MPC870? In the old 2.4
> kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding
> config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or
> CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I
> believe USB microcode is irrelevant here. So it comes down the other
> two choices. Of course do I really need the patch? My board has I2C
> and SMC1, but no SPI.
>
> I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the
> following compilation error:
These errors were fixed by
http://patchwork.ozlabs.org/patch/58262/
and
http://patchwork.ozlabs.org/patch/58263/
Thanks,
> CC arch/powerpc/sysdev/micropatch.o
> arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
> arch/powerpc/sysdev/micropatch.c:629: error: expected '=', ',', ';',
> 'asm' or '__attribute__' before '*' token
> arch/powerpc/sysdev/micropatch.c:629: error: 'spp' undeclared (first
> use in this function)
> arch/powerpc/sysdev/micropatch.c:629: error: (Each undeclared
> identifier is reported only once
> arch/powerpc/sysdev/micropatch.c:629: error: for each function it appears in.)
> cc1: warnings being treated as errors
> arch/powerpc/sysdev/micropatch.c:630: warning: ISO C90 forbids mixed
> declarations and code
> arch/powerpc/sysdev/micropatch.c:671: error: 'spi_t' undeclared (first
> use in this function)
> arch/powerpc/sysdev/micropatch.c:671: error: expected expression
> before ')' token
> arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
> make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
>
> Obviously there is no spi_t declaration in 2.6.33.5. So where is this
> spi_t declared?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ 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