* Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform
From: Wei Yang @ 2014-04-23 1:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: aik, linuxppc-dev, Gavin Shan
In-Reply-To: <1398212778.19682.129.camel@pasglop>
On Wed, Apr 23, 2014 at 10:26:18AM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2014-04-23 at 09:00 +1000, Gavin Shan wrote:
>> The side effect of holding pci_dev refcount is the pci_dev, eeh_dev,
>> eeh_pe instance can't be free'ed during fully hotplug though EEH can
>> survive. It's reasonable to remove it.
>
>Allright. Can you guys refresh that patch with an updated cset
>comment and shoot it upstream ?
Glad to do so.
>
>Thanks !
>
>Cheers,
>Ben.
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH v2 21/21] of: push struct boot_param_header and defines into powerpc
From: Rob Herring @ 2014-04-23 1:18 UTC (permalink / raw)
To: Grant Likely, linux-kernel, devicetree
Cc: Rob Herring, Paul Mackerras, linuxppc-dev
In-Reply-To: <1398215901-25609-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Now powerpc is the only user of struct boot_param_header and FDT defines,
so they can be moved into the powerpc architecture code.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
v2: no change
arch/powerpc/include/asm/prom.h | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/of_fdt.h | 37 -------------------------------------
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index d977b9b..74b79f0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -26,6 +26,45 @@
#include <linux/of_irq.h>
#include <linux/platform_device.h>
+#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
+#define OF_DT_END_NODE 0x2 /* End node */
+#define OF_DT_PROP 0x3 /* Property: name off, size,
+ * content */
+#define OF_DT_NOP 0x4 /* nop */
+#define OF_DT_END 0x9
+
+#define OF_DT_VERSION 0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+ __be32 magic; /* magic word OF_DT_HEADER */
+ __be32 totalsize; /* total size of DT block */
+ __be32 off_dt_struct; /* offset to structure */
+ __be32 off_dt_strings; /* offset to strings */
+ __be32 off_mem_rsvmap; /* offset to memory reserve map */
+ __be32 version; /* format version */
+ __be32 last_comp_version; /* last compatible version */
+ /* version 2 fields below */
+ __be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
+ /* version 3 fields below */
+ __be32 dt_strings_size; /* size of the DT strings block */
+ /* version 17 fields below */
+ __be32 dt_struct_size; /* size of the DT structure block */
+};
+
/*
* OF address retreival & translation
*/
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 1f882e1..5c0ab05 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -17,45 +17,8 @@
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
-#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
-#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off, size,
- * content */
-#define OF_DT_NOP 0x4 /* nop */
-#define OF_DT_END 0x9
-
-#define OF_DT_VERSION 0x10
#ifndef __ASSEMBLY__
-/*
- * This is what gets passed to the kernel by prom_init or kexec
- *
- * The dt struct contains the device tree structure, full pathes and
- * property contents. The dt strings contain a separate block with just
- * the strings for the property names, and is fully page aligned and
- * self contained in a page, so that it can be kept around by the kernel,
- * each property name appears only once in this page (cheap compression)
- *
- * the mem_rsvmap contains a map of reserved ranges of physical memory,
- * passing it here instead of in the device-tree itself greatly simplifies
- * the job of everybody. It's just a list of u64 pairs (base/size) that
- * ends when size is 0
- */
-struct boot_param_header {
- __be32 magic; /* magic word OF_DT_HEADER */
- __be32 totalsize; /* total size of DT block */
- __be32 off_dt_struct; /* offset to structure */
- __be32 off_dt_strings; /* offset to strings */
- __be32 off_mem_rsvmap; /* offset to memory reserve map */
- __be32 version; /* format version */
- __be32 last_comp_version; /* last compatible version */
- /* version 2 fields below */
- __be32 boot_cpuid_phys; /* Physical CPU id we're booting on */
- /* version 3 fields below */
- __be32 dt_strings_size; /* size of the DT strings block */
- /* version 17 fields below */
- __be32 dt_struct_size; /* size of the DT structure block */
-};
#if defined(CONFIG_OF_FLATTREE)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 14/21] of/fdt: create common debugfs
From: Rob Herring @ 2014-04-23 1:18 UTC (permalink / raw)
To: Grant Likely, linux-kernel, devicetree
Cc: Rob Herring, Michal Simek, Paul Mackerras, linuxppc-dev
In-Reply-To: <1398215901-25609-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Both powerpc and microblaze have the same FDT blob in debugfs feature.
Move this to common location and remove the powerpc and microblaze
implementations. This feature could become more useful when FDT
overlay support is added.
This changes the path of the blob from "$arch/flat-device-tree" to
"device-tree/flat-device-tree".
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
v2: move to after libfdt conversion
arch/microblaze/kernel/prom.c | 31 -------------------------------
arch/powerpc/kernel/prom.c | 21 ---------------------
drivers/of/fdt.c | 24 ++++++++++++++++++++++++
3 files changed, 24 insertions(+), 52 deletions(-)
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index c766306..68f0999 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -114,34 +114,3 @@ void __init early_init_devtree(void *params)
pr_debug(" <- early_init_devtree()\n");
}
-
-/*******
- *
- * New implementation of the OF "find" APIs, return a refcounted
- * object, call of_node_put() when done. The device tree and list
- * are protected by a rw_lock.
- *
- * Note that property management will need some locking as well,
- * this isn't dealt with yet.
- *
- *******/
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = initial_boot_params->totalsize;
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- of_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-device_initcall(export_flat_device_tree);
-#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f971134..03624ce 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -29,7 +29,6 @@
#include <linux/bitops.h>
#include <linux/export.h>
#include <linux/kexec.h>
-#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/memblock.h>
#include <linux/of.h>
@@ -924,23 +923,3 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
{
return (int)phys_id == get_hard_smp_processor_id(cpu);
}
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- powerpc_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-__initcall(export_flat_device_tree);
-#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 0b38a6a..4129f74 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -20,6 +20,7 @@
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/libfdt.h>
+#include <linux/debugfs.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#include <asm/page.h>
@@ -916,4 +917,27 @@ void __init unflatten_and_copy_device_tree(void)
unflatten_device_tree();
}
+#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
+static struct debugfs_blob_wrapper flat_dt_blob;
+
+static int __init of_flat_dt_debugfs_export_fdt(void)
+{
+ struct dentry *d = debugfs_create_dir("device-tree", NULL);
+
+ if (!d)
+ return -ENOENT;
+
+ flat_dt_blob.data = initial_boot_params;
+ flat_dt_blob.size = fdt_totalsize(initial_boot_params);
+
+ d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
+ d, &flat_dt_blob);
+ if (!d)
+ return -ENOENT;
+
+ return 0;
+}
+module_init(of_flat_dt_debugfs_export_fdt);
+#endif
+
#endif /* CONFIG_OF_EARLY_FLATTREE */
--
1.9.1
^ permalink raw reply related
* [PATCH v2 00/21] FDT clean-ups and libfdt support
From: Rob Herring @ 2014-04-23 1:18 UTC (permalink / raw)
To: Grant Likely, linux-kernel, devicetree
Cc: linux-mips, Aurelien Jacquiot, H. Peter Anvin, Max Filippov,
Paul Mackerras, linux, Jonas Bonn, Rob Herring, Russell King,
linux-c6x-dev, x86, Ingo Molnar, Mark Salter, linux-xtensa,
James Hogan, Thomas Gleixner, linux-metag, linux-arm-kernel,
Chris Zankel, Michal Simek, Vineet Gupta, Ralf Baechle,
linuxppc-dev
From: Rob Herring <robh@kernel.org>
This is a series of clean-ups of architecture FDT code and converts the
core FDT code over to using libfdt functions. This is in preparation
to add FDT based address translation parsing functions for early
console support. This series removes direct access to FDT data from all
arches except powerpc.
The current MIPS lantiq and xlp DT code is buggy as built-in DTBs need
to be copied out of init section. Patches 2 and 3 should be applied to
3.15.
Changes in v2 are relatively minor. There was a bug in the unflattening
code where walking up the tree was not being handled correctly (thanks
to Michal Simek). I re-worked things a bit to avoid globally adding
libfdt include paths.
A branch is available here[1], and I plan to put into linux-next in a few
days. Please test! I've compiled on arm, arm64, mips, microblaze, xtensa,
and powerpc and booted on arm and arm64.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git libfdt
Rob Herring (21):
mips: octeon: convert to use unflatten_and_copy_device_tree
mips: lantiq: copy built-in DTB out of init section
mips: xlp: copy built-in DTB out of init section
mips: ralink: convert to use unflatten_and_copy_device_tree
ARM: dt: use default early_init_dt_alloc_memory_arch
c6x: convert fdt pointers to opaque pointers
mips: convert fdt pointers to opaque pointers
of/fdt: consolidate built-in dtb section variables
of/fdt: remove some unneeded includes
of/fdt: remove unused of_scan_flat_dt_by_path
of/fdt: update of_get_flat_dt_prop in prep for libfdt
of/fdt: Convert FDT functions to use libfdt
of/fdt: use libfdt accessors for header data
of/fdt: create common debugfs
of/fdt: move memreserve and dtb memory reservations into core
of/fdt: fix phys_addr_t related print size warnings
of/fdt: introduce of_get_flat_dt_size
powerpc: use libfdt accessors for header data
x86: use FDT accessors for FDT blob header data
of/fdt: convert initial_boot_params to opaque pointer
of: push struct boot_param_header and defines into powerpc
arch/arc/include/asm/sections.h | 1 -
arch/arc/kernel/devtree.c | 2 +-
arch/arm/include/asm/prom.h | 2 -
arch/arm/kernel/devtree.c | 34 +--
arch/arm/mach-exynos/exynos.c | 2 +-
arch/arm/mach-vexpress/platsmp.c | 2 +-
arch/arm/mm/init.c | 1 -
arch/arm/plat-samsung/s5p-dev-mfc.c | 4 +-
arch/arm64/mm/init.c | 21 --
arch/c6x/kernel/setup.c | 4 +-
arch/metag/kernel/setup.c | 4 -
arch/microblaze/kernel/prom.c | 39 +--
arch/mips/cavium-octeon/setup.c | 20 +-
arch/mips/include/asm/mips-boards/generic.h | 4 -
arch/mips/include/asm/prom.h | 6 +-
arch/mips/kernel/prom.c | 2 +-
arch/mips/lantiq/prom.c | 15 +-
arch/mips/lantiq/prom.h | 2 -
arch/mips/mti-sead3/sead3-setup.c | 8 +-
arch/mips/netlogic/xlp/dt.c | 19 +-
arch/mips/ralink/of.c | 29 +-
arch/openrisc/kernel/vmlinux.h | 2 -
arch/powerpc/include/asm/prom.h | 39 +++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/epapr_paravirt.c | 2 +-
arch/powerpc/kernel/fadump.c | 4 +-
arch/powerpc/kernel/prom.c | 78 ++----
arch/powerpc/kernel/rtas.c | 2 +-
arch/powerpc/mm/hash_utils_64.c | 22 +-
arch/powerpc/platforms/52xx/efika.c | 4 +-
arch/powerpc/platforms/chrp/setup.c | 4 +-
arch/powerpc/platforms/powernv/opal.c | 12 +-
arch/powerpc/platforms/pseries/setup.c | 4 +-
arch/x86/kernel/devicetree.c | 12 +-
arch/xtensa/kernel/setup.c | 3 +-
drivers/of/Kconfig | 1 +
drivers/of/Makefile | 2 +
drivers/of/fdt.c | 398 ++++++++++------------------
drivers/of/of_reserved_mem.c | 4 +-
include/linux/of_fdt.h | 63 +----
40 files changed, 280 insertions(+), 598 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform
From: Benjamin Herrenschmidt @ 2014-04-23 0:26 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, Wei Yang, linuxppc-dev
In-Reply-To: <20140422230033.GA12208@shangw>
On Wed, 2014-04-23 at 09:00 +1000, Gavin Shan wrote:
> The side effect of holding pci_dev refcount is the pci_dev, eeh_dev,
> eeh_pe instance can't be free'ed during fully hotplug though EEH can
> survive. It's reasonable to remove it.
Allright. Can you guys refresh that patch with an updated cset
comment and shoot it upstream ?
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform
From: Gavin Shan @ 2014-04-22 23:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: aik, Wei Yang, linuxppc-dev, Gavin Shan
In-Reply-To: <1398155109.19682.89.camel@pasglop>
On Tue, Apr 22, 2014 at 06:25:09PM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2014-04-22 at 15:44 +0800, Wei Yang wrote:
>> So this patch(the 2nd one) doesn't contribute to clear the warning and
>> error.
>> Only the first patch did it. Please ignore this one.
>
>But is it correct ? It's not right to keep a refcount elevated if we
>don't have to.
>
>Gavin, can you get to the bottom of that refcount business ?
>
Ben, "struct pci_dn::pcidev" was used by EEH originally. We don't
use it any more. So it can be removed.
Currently, EEH has following 4 functions to do conversion from
one to another. None of them relies on "struct pci_dn::pcidev".
of_node_to_eeh_dev() device_node -> pci_dn -> eeh_dev
pci_dev_to_eeh_dev() pci_dev -> device -> archdata -> eeh_dev
eeh_dev_to_of_node() eeh_dev -> device_node
eeh_dev_to_pci_dev() eeh_dev -> pci_dev
The side effect of holding pci_dev refcount is the pci_dev, eeh_dev,
eeh_pe instance can't be free'ed during fully hotplug though EEH can
survive. It's reasonable to remove it.
Thanks,
Gavin
^ permalink raw reply
* Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS
From: Scott Wood @ 2014-04-22 22:37 UTC (permalink / raw)
To: shiva7; +Cc: Chris Friesen, linuxppc-dev
In-Reply-To: <1398205896.1694.252.camel@snotra.buserror.net>
On Tue, 2014-04-22 at 17:31 -0500, Scott Wood wrote:
> On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> > I have the same question as like above posted by Mr. Chirs.
>
> I had to google the subject to find what e-mail you were talking about
> -- it was posted a year ago:
>
> http://marc.info/?l=linuxppc-embedded&m=136572252330650&w=2
>
> Next time please quote the e-mail if you're trying to revive a thread,
> and keep the original poster on CC.
>
> I've quoted it here:
>
> > Sorry for the bunch of emails, I'm working on some new stuff and running
> > into issues.
> >
> > For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP
> > but not DBCR0_BRT. Is that just because none of the code paths
> > currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?
>
> Perhaps it was just an oversight. I've CCed Dave Kleikamp and Torez
> Smith, who added DBCR0_ACTIVE_EVENTS.
...and both of those e-mails bounced, so it may be that nobody who is
listening knows the answer. Feel free to submit a patch that adds it,
with the changelog explaining why it should be included.
-Scott
^ permalink raw reply
* Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS
From: Scott Wood @ 2014-04-22 22:31 UTC (permalink / raw)
To: shiva7; +Cc: Chris Friesen, linuxppc-dev, Dave Kleikamp, Torez Smith
In-Reply-To: <1398170592855-81732.post@n7.nabble.com>
On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> I have the same question as like above posted by Mr. Chirs.
I had to google the subject to find what e-mail you were talking about
-- it was posted a year ago:
http://marc.info/?l=linuxppc-embedded&m=136572252330650&w=2
Next time please quote the e-mail if you're trying to revive a thread,
and keep the original poster on CC.
I've quoted it here:
> Sorry for the bunch of emails, I'm working on some new stuff and running
> into issues.
>
> For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP
> but not DBCR0_BRT. Is that just because none of the code paths
> currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?
Perhaps it was just an oversight. I've CCed Dave Kleikamp and Torez
Smith, who added DBCR0_ACTIVE_EVENTS.
> Also, in sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return
> -EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set? Would it not be possible
> to use DBCR0_BRT?
Either nobody has gotten around to implementing it, or the semantics
are different in some way (if the semantics are even defined anywhere
-- I couldn't find any documentation).
-Scott
^ permalink raw reply
* Re: [PATCH 10/33] powerpc: Ignore TOC relocations
From: Anton Blanchard @ 2014-04-22 22:02 UTC (permalink / raw)
To: Alan Modra; +Cc: mikey, rusty, ulrich.weigand, mjw, paulus, linuxppc-dev
In-Reply-To: <20140326093602.GM18201@bubble.grove.modra.org>
Hi Alan,
> > The linker fixes up TOC. relocations, so prom_init_check.sh should
> > ignore them.
>
> Err, .TOC. you mean. Presumably something strips off the leading dot
> somewhere?
Yeah, the script strips them:
# On 64-bit nm gives us the function descriptors, which have
# a leading . on the name, so strip it off here.
UNDEF="${UNDEF#.}"
I'll modify the commit message to be less confusing.
Anton
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/powernv: Create OPAL sglist helper functions and fix endian issues
From: Anton Blanchard @ 2014-04-22 21:34 UTC (permalink / raw)
To: Vasant Hegde; +Cc: stewart, paulus, linuxppc-dev
In-Reply-To: <5356335A.1080704@linux.vnet.ibm.com>
Hi,
> Shouldn't we convert addr and id before passing to opal_dump_read()
> here ?
int64_t opal_dump_read(uint32_t dump_id, uint64_t buffer);
All arguments are passed via register, so byteswaping the arguments
would break it.
Anton
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/powernv: Fix little endian issues in OPAL dump code
From: Anton Blanchard @ 2014-04-22 21:31 UTC (permalink / raw)
To: Vasant Hegde; +Cc: stewart, paulus, linuxppc-dev
In-Reply-To: <53562921.6050300@linux.vnet.ibm.com>
Hi,
> -int64_t opal_dump_info(uint32_t *dump_id, uint32_t *dump_size);
> -int64_t opal_dump_info2(uint32_t *dump_id, uint32_t *dump_size, uint32_t *dump_type);
> +int64_t opal_dump_info(__be32 *dump_id, __be32 *dump_size);
> +int64_t opal_dump_info2(__be32 *dump_id, __be32 *dump_size, __be32 *dump_type);
> int64_t opal_dump_read(uint32_t dump_id, uint64_t buffer);
> int64_t opal_dump_ack(uint32_t dump_id);
>
> Shouldn't we change above two functions as well ?
No, there are no endian issues here because we pass the values via
register. The only endian issues are for values we pass via pointer.
> Should we convert ID back to BE format in dump_send_ack() ?
Same as above.
Anton
^ permalink raw reply
* Re: [PATCH RFC v11 5/6] dma: mpc512x: add device tree binding document
From: Gerhard Sittig @ 2014-04-22 18:27 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Anatolij Gustschin, Arnd Bergmann,
Vinod Koul, dmaengine, Dan Williams, Andy Shevchenko,
linuxppc-dev
In-Reply-To: <CAF0T0X4TqhZ=niKRgArG-s1cD6uRH0UZDqGyTLpde_aHBFTVtw@mail.gmail.com>
On Fri, 2014-04-18 at 15:29 +0400, Alexander Popov wrote:
>
> 2014-04-17 0:44 GMT+04:00 Gerhard Sittig <gsi@denx.de>:
> > On Tue, 2014-04-15 at 14:54 +0400, Alexander Popov wrote:
> >>
> >> +- reg: Address and size of the DMA controller's register set
> >> +- interrupts: Interrupt for the DMA controller. Generic interrupt client node
> >> + is described in interrupt-controller/interrupts.txt
> >
> > 'interrupts' only works in combinations with 'interrupt-parent',
> > that actual .dts files don't have the latter in the nodes is an
> > implementation detail but not a binding's requirement
> Excuse me, I didn't understand your point.
>
> > and an alternative method of specifying interrupts was introduced
> > recently, a reference to the common binding without naming one
> > specific property name could be most appropriate
> Excuse me, I haven't found such an example.
The 'interrupts' property is not enough in itself, it always
needs the 'interrupt-parent' property, too. Because the parent
(the interrupt controller) often is the same for multiple
interrupts, it usually gets "factored out" into a parent node in
the tree, and thus often gets missed in discussions. Still the
'interrupt-parent' is strictly required for 'interrupts' to work.
Splitting both properties and putting them into nodes that are
rather distant from each other is just an implementation detail
of .dts files. This should not be reflected in bindings.
The 'interrupts-extended' property was introduced only recently.
See bindings/interrupt-controller/interrupts.txt for details.
Although the motivation was to reference several parents from one
client node, I very much like the idea of having all of the
interrupt spec within a single property. Being explicit is a
good thing, especially in setups with cascades. I consider this
approach an improvement in readability and maintenance.
You might just want to document in the binding that interrupt
specs are required (or optional), which interrupts these are (the
above text could be sufficient if there is only one interrupt for
this IP block), and refer to the common binding for the syntax.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
From: Leif Lindholm @ 2014-04-22 14:05 UTC (permalink / raw)
To: Grant Likely
Cc: Mark Rutland, devicetree@vger.kernel.org, Linaro Patches,
linux-kernel@vger.kernel.org, Rob Herring, linuxppc-dev
In-Reply-To: <20140422130829.CA29DC4042C@trevor.secretlab.ca>
On Tue, Apr 22, 2014 at 02:08:29PM +0100, Grant Likely wrote:
> > I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here.
>
> I completely agree.
OK. So do we keep this around on unaffected architectures in perpetuity?
Or can there be some cut-off date when the majority of DT-enabled
platforms can stop including this workaround which permits new incorrect
DTs to be implemented so long as they are incorrect in this particular
way?
> > Really, I would like to see quirks like this fixed up out of line from
> > the normal flow somewhat like how PCI quirks are handled. So in this
> > example, we would just add the missing property to the dtb for the
> > broken platform before doing the memory scan. That does then require
> > libfdt which is something I'm working on.
>
> In fact, for Leif's purposes, I would rather have a flag when booting via
> UEFI, and make the kernel skip the memory node parsing if the UEFI
> memory map is available. Then the stub doesn't need to do any munging of
> the DTB at all.
The reason for me doing that is because we (including you) agreed at
the discussion held during LCU13 that this was the safest way of
preventing "mischief" like userland trying to read information from
/proc/device-tree...
/
Leif
^ permalink raw reply
* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Grant Likely @ 2014-04-22 13:35 UTC (permalink / raw)
To: Leif Lindholm, Geert Uytterhoeven
Cc: Mark Rutland, devicetree@vger.kernel.org, patches, Lee Jones,
linux-kernel@vger.kernel.org, Rob Herring,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140418125924.GF5904@bivouac.eciton.net>
On Fri, 18 Apr 2014 13:59:24 +0100, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> Hi Geert,
>
> On Fri, Apr 18, 2014 at 10:04:15AM +0200, Geert Uytterhoeven wrote:
> > On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > > In order to deal with an firmware bug on a specific ppc32 platform
> > > (longtrail), early_init_dt_scan_memory() looks for a node called
> > > memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.
> >
> > This breaks backwards compatibilty with old DTSes (at least on ARM/MIPS,
> > where you added the missing property in patches 1 and 2 of the series)?
>
> As Rob said in response to 0/3, the MIPSs would likely not be affected,
> since they embed the DT.
>
> > For the Longtrail, I don't care much anymore, as mine died in 2004.
> > AFAIK, there have never been many users anyway.
>
> There are still a few mentions of it under arch/powerpc/, so I wouldn't
> want to be the one to kill it off...
>
> How about the below v2 3/3 to address the ARM platform?
The problem with this approach is that selecting one board that needs it
automatically makes it active for all boards. It would need to be
something more like the following:
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 399e242e1a42..55d65b2b4c74 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -887,12 +887,10 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
/* We are scanning "memory" nodes only */
if (type == NULL) {
- /*
- * The longtrail doesn't have a device_type on the
- * /memory node, so look for the node called /memory@0.
- */
if (depth != 1 || strcmp(uname, "memory@0") != 0)
return 0;
+ if (!of_flat_dt_match(dt_root, memory_quirk_list))
+ return 0;
} else if (strcmp(type, "memory") != 0)
return 0;
With a list of compatible properties for affected boards.
g.
^ permalink raw reply related
* Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
From: Grant Likely @ 2014-04-22 13:08 UTC (permalink / raw)
To: Rob Herring, Leif Lindholm
Cc: Mark Rutland, devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, Linaro Patches
In-Reply-To: <CAL_JsqKdFyhHfkcC1E9QuKjQTrXwoELYG+CFTpgf2-jqDvxGmA@mail.gmail.com>
On Fri, 18 Apr 2014 10:37:58 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > On Thu, Apr 17, 2014 at 07:43:13PM -0500, Rob Herring wrote:
> >> On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
> >> <leif.lindholm@linaro.org> wrote:
> >> > drivers/of/fdt.c contains a workaround for a missing memory type
> >> > entry on longtrail firmware. Make that quirk PPC32 only, and while
> >> > at it - fix up the .dts files in the tree currently working only
> >> > because of that quirk.
> >>
> >> But why do you need this?
> >
> > Apart from the current code permitting recreating a 15+ year old
> > firmware bug into completely new platform ports?
>
> I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here.
I completely agree.
> Really, I would like to see quirks like this fixed up out of line from
> the normal flow somewhat like how PCI quirks are handled. So in this
> example, we would just add the missing property to the dtb for the
> broken platform before doing the memory scan. That does then require
> libfdt which is something I'm working on.
In fact, for Leif's purposes, I would rather have a flag when booting via
UEFI, and make the kernel skip the memory node parsing if the UEFI
memory map is available. Then the stub doesn't need to do any munging of
the DTB at all.
g.
^ permalink raw reply
* Re: [PATCH v2] gpio: ge: Convert to platform driver
From: Linus Walleij @ 2014-04-22 13:03 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-gpio@vger.kernel.org, Martyn Welch,
linuxppc-dev@lists.ozlabs.org list, Alexandre Courbot
In-Reply-To: <1397281291-28694-1-git-send-email-shc_work@mail.ru>
On Sat, Apr 12, 2014 at 7:41 AM, Alexander Shiyan <shc_work@mail.ru> wrote:
> This patch converts GE I/O FPGA GPIO driver to platform driver.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
No further comments, so this v2 patch is applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS
From: shiva7 @ 2014-04-22 12:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5167457E.1050205@genband.com>
I have the same question as like above posted by Mr. Chirs.
Could someone help to understand why the debug BRT bit not handled in debug
context sys call? Intentional or need volunteer to finish up this part :)
--
View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p81732.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform
From: Wei Yang @ 2014-04-22 9:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: aik, linuxppc-dev, Gavin Shan
In-Reply-To: <1398155109.19682.89.camel@pasglop>
On Tue, Apr 22, 2014 at 06:25:09PM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2014-04-22 at 15:44 +0800, Wei Yang wrote:
>> So this patch(the 2nd one) doesn't contribute to clear the warning and
>> error.
>> Only the first patch did it. Please ignore this one.
>
>But is it correct ? It's not right to keep a refcount elevated if we
>don't have to.
The code refcount is introduced in commit 184cd4a3(powerpc/powernv: PCI
support for p7IOC under OPAL v2). To me, it looks not necessary.
>
>Gavin, can you get to the bottom of that refcount business ?
>
>Cheers,
>Ben.
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH v4 3/3] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
From: Valentin Longchamp @ 2014-04-22 9:30 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
In-Reply-To: <1398159031-10110-1-git-send-email-valentin.longchamp@keymile.com>
This patch introduces the support for Keymile's kmcoge4 board which is
the internal reference design for boards based on Freescale's
P2040/P2041 SoCs. This internal reference design is named kmp204x.
The peripherals used on this board are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
CPLD
- 2 I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design that is
necessary because of the lowmem option that must be set higher due to
the number of PCIe devices with big ioremapped mem ranges on the boad.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
Changes in v4:
- remove the partition layout for the NAND Flash as well as it was
forgotten
- Rebased on top of v3.15-rc1
Changes in v3:
- add the compatible strings for the localbus nodes
- remove the IRQ part of the board-control node as it is currently being
reworked
Changes in v2:
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
arch/powerpc/boot/dts/kmcoge4.dts | 152 +++++++++++++++++
arch/powerpc/configs/85xx/kmp204x_defconfig | 225 ++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
4 files changed, 380 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 0000000..89b4119
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,152 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longchamp@keymile.com
+ *
+ * Copyright 2011 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.
+ */
+
+/include/ "fsl/p2041si-pre.dtsi"
+
+/ {
+ model = "keymile,kmcoge4";
+ compatible = "keymile,kmcoge4", "keymile,kmp204x";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01008000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25fl256s1";
+ reg = <0>;
+ spi-max-frequency = <20000000>; /* input clock */
+ };
+
+ network_clock@1 {
+ compatible = "zarlink,zl30343";
+ reg = <1>;
+ spi-max-frequency = <8000000>;
+ };
+
+ flash@2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,m25p32";
+ reg = <2>;
+ spi-max-frequency = <15000000>;
+ };
+ };
+
+ i2c@119000 {
+ status = "disabled";
+ };
+
+ i2c@119100 {
+ status = "disabled";
+ };
+
+ usb0: usb@210000 {
+ status = "disabled";
+ };
+
+ usb1: usb@211000 {
+ status = "disabled";
+ };
+
+ sata@220000 {
+ status = "disabled";
+ };
+
+ sata@221000 {
+ status = "disabled";
+ };
+ };
+
+ rio: rapidio@ffe0c0000 {
+ status = "disabled";
+ };
+
+ lbc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x1000>;
+ ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
+ 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
+ 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
+ 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
+
+ nand@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0 0 0x40000>;
+ };
+
+ board-control@1,0 {
+ compatible = "keymile,qriox";
+ reg = <1 0 0x80>;
+ };
+
+ chassis-mgmt@3,0 {
+ compatible = "keymile,bfticu";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <3 0 0x100>;
+ interrupt-parent = <&mpic>;
+ interrupts = <6 1 0 0>;
+ };
+ };
+
+ pci0: pcie@ffe200000 {
+ reg = <0xf 0xfe200000 0 0x1000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe201000 {
+ status = "disabled";
+ };
+
+ pci2: pcie@ffe202000 {
+ reg = <0xf 0xfe202000 0 0x1000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8010000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
+
+/include/ "fsl/p2041si-post.dtsi"
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig
new file mode 100644
index 0000000..e9a81e5
--- /dev/null
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -0,0 +1,225 @@
+CONFIG_PPC_85xx=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MAC_PARTITION=y
+CONFIG_CORENET_GENERIC=y
+CONFIG_MPIC_MSGR=y
+CONFIG_HIGHMEM=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_BINFMT_MISC=m
+CONFIG_KEXEC=y
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+# CONFIG_PCIEASPM is not set
+CONFIG_PCI_MSI=y
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_LOWMEM_SIZE_BOOL=y
+CONFIG_LOWMEM_SIZE=0x20000000
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_XFRM_SUB_POLICY=y
+CONFIG_XFRM_STATISTICS=y
+CONFIG_NET_KEY=y
+CONFIG_NET_KEY_MIGRATE=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPIP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_INET_AH=y
+CONFIG_INET_ESP=y
+CONFIG_INET_IPCOMP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_IP_SCTP=m
+CONFIG_TIPC=y
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_CBQ=y
+CONFIG_NET_SCH_HTB=y
+CONFIG_NET_SCH_HFSC=y
+CONFIG_NET_SCH_PRIO=y
+CONFIG_NET_SCH_MULTIQ=y
+CONFIG_NET_SCH_RED=y
+CONFIG_NET_SCH_SFQ=y
+CONFIG_NET_SCH_TEQL=y
+CONFIG_NET_SCH_TBF=y
+CONFIG_NET_SCH_GRED=y
+CONFIG_NET_CLS_BASIC=y
+CONFIG_NET_CLS_TCINDEX=y
+CONFIG_NET_CLS_U32=y
+CONFIG_CLS_U32_PERF=y
+CONFIG_CLS_U32_MARK=y
+CONFIG_NET_CLS_FLOW=y
+CONFIG_NET_CLS_CGROUP=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/mdev"
+CONFIG_DEVTMPFS=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_PHRAM=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ECC_BCH=y
+CONFIG_MTD_NAND_FSL_ELBC=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=2
+CONFIG_BLK_DEV_RAM_SIZE=2048
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SYM53C8XX_2=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_VENDOR_ADAPTEC is not set
+# CONFIG_NET_VENDOR_ALTEON is not set
+# CONFIG_NET_VENDOR_AMD is not set
+# CONFIG_NET_VENDOR_ATHEROS is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_BROCADE is not set
+# CONFIG_NET_VENDOR_CHELSIO is not set
+# CONFIG_NET_VENDOR_CISCO is not set
+# CONFIG_NET_VENDOR_DEC is not set
+# CONFIG_NET_VENDOR_DLINK is not set
+# CONFIG_NET_VENDOR_EMULEX is not set
+# CONFIG_NET_VENDOR_EXAR is not set
+CONFIG_FSL_PQ_MDIO=y
+CONFIG_FSL_XGMAC_MDIO=y
+# CONFIG_NET_VENDOR_HP is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_MYRI is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NVIDIA is not set
+# CONFIG_NET_VENDOR_OKI is not set
+# CONFIG_NET_PACKET_ENGINE is not set
+# CONFIG_NET_VENDOR_QLOGIC is not set
+# CONFIG_NET_VENDOR_REALTEK is not set
+# CONFIG_NET_VENDOR_RDC is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SILAN is not set
+# CONFIG_NET_VENDOR_SIS is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SUN is not set
+# CONFIG_NET_VENDOR_TEHUTI is not set
+# CONFIG_NET_VENDOR_TI is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_NET_VENDOR_XILINX is not set
+CONFIG_MARVELL_PHY=y
+CONFIG_VITESSE_PHY=y
+CONFIG_FIXED_PHY=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_PPC_EPAPR_HV_BYTECHAN=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_DETECT_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+CONFIG_NVRAM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
+CONFIG_I2C_MPC=y
+CONFIG_SPI=y
+CONFIG_SPI_FSL_SPI=y
+CONFIG_SPI_FSL_ESPI=y
+CONFIG_SPI_SPIDEV=m
+CONFIG_PTP_1588_CLOCK=y
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_EDAC=y
+CONFIG_EDAC_MM_EDAC=y
+CONFIG_EDAC_MPC85XX=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS3232=y
+CONFIG_RTC_DRV_CMOS=y
+CONFIG_UIO=y
+CONFIG_STAGING=y
+# CONFIG_NET_VENDOR_SILICOM is not set
+CONFIG_CLK_PPC_CORENET=y
+CONFIG_EXT2_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=m
+CONFIG_CRC_ITU_T=m
+CONFIG_DEBUG_INFO=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_SCHEDSTATS=y
+CONFIG_RCU_TRACE=y
+CONFIG_UPROBE_EVENT=y
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_SHA512=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_FSL_CAAM=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..fb98fd6 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -263,7 +263,7 @@ config CORENET_GENERIC
help
This option enables support for the FSL CoreNet based boards.
For 32bit kernel, the following boards are supported:
- P2041 RDB, P3041 DS and P4080 DS
+ P2041 RDB, P3041 DS, P4080 DS and kmcoge4
For 64bit kernel, the following boards are supported:
T4240 QDS and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 8e4b1e1..ceb0dac 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -67,7 +67,7 @@ void __init corenet_gen_setup_arch(void)
swiotlb_detect_4g();
- pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
+ pr_info("%s board\n", ppc_md.name);
mpc85xx_qe_init();
}
@@ -122,6 +122,7 @@ static const char * const boards[] __initconst = {
"fsl,B4860QDS",
"fsl,B4420QDS",
"fsl,B4220QDS",
+ "keymile,kmcoge4",
NULL
};
--
1.8.0.1
^ permalink raw reply related
* [PATCH v4 0/3] Support of the kmcoge4 board
From: Valentin Longchamp @ 2014-04-22 9:30 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
This series adds support for Keymile's COGE4 board, called kmcoge4. This
board is the reference design for further designs at Keymile around the
P2040/P2041 SoCs from Freescale. This reference design is internally
called kmp204x.
Changes in v4:
- remove the addition of the KEYMILE vendor-prefix as it is already
picked by Rob
- Take Scott's and Rob's comments regarding the bindings for the
interrupt-cells into account
- remove the partition layout for the NAND Flash as well as it was
forgotten
- Rebased on top of v3.15-rc1
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
- add the compatible strings for the localbus nodes
- remove the IRQ part of the board-control node as it is currently being
reworked
Changes in v2:
- add a patch so that the Zarlink vendor prefix is defined
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
Valentin Longchamp (3):
devicetree: bindings: add Zarlink to the vendor prefixes
devcietree: bindings: add some MFD Keymile FPGAs
powerpc/mpc85xx: add support for Keymile's kmcoge4 board
Documentation/devicetree/bindings/mfd/bfticu.txt | 25 +++
Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/powerpc/boot/dts/kmcoge4.dts | 152 ++++++++++++++
arch/powerpc/configs/85xx/kmp204x_defconfig | 225 +++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
7 files changed, 423 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
--
1.8.0.1
^ permalink raw reply
* [PATCH v4 1/3] devicetree: bindings: add Zarlink to the vendor prefixes
From: Valentin Longchamp @ 2014-04-22 9:30 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
In-Reply-To: <1398159031-10110-1-git-send-email-valentin.longchamp@keymile.com>
Even though the company belongs to Microsemi, many chips are still
labeled as Zarlink. Among them is the family of network clock generators,
the zl3034x.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- add a patch so that the Zarlink vendor prefix is defined
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0f01c9b..93cc7dc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -119,3 +119,4 @@ wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
xes Extreme Engineering Solutions (X-ES)
xlnx Xilinx
+zarlink Zarlink Semiconductor
--
1.8.0.1
^ permalink raw reply related
* [PATCH v4 2/3] devcietree: bindings: add some MFD Keymile FPGAs
From: Valentin Longchamp @ 2014-04-22 9:30 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
In-Reply-To: <1398159031-10110-1-git-send-email-valentin.longchamp@keymile.com>
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
Changes in v4:
- remove the addition of the KEYMILE vendor-prefix as it is already
picked by Rob
- Take Scott's and Rob's comments regarding the bindings for the
interrupt-cells into account
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
Changes in v2: None
Documentation/devicetree/bindings/mfd/bfticu.txt | 25 ++++++++++++++++++++++++
Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++++++++++++++++
2 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 0000000..65c9077
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,25 @@
+KEYMILE bfticu Chassis Management FPGA
+
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+
+Required properties:
+- compatible: "keymile,bfticu"
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2 and their usage is compliant to the 2 cells variant
+ of Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to
+- reg: access on the parent local bus (chip select, offset in chip select, size)
+
+Example:
+
+ chassis-mgmt@3,0 {
+ compatible = "keymile,bfticu";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <3 0 0x100>;
+ interrupt-parent = <&mpic>;
+ interrupts = <6 1 0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 0000000..f301e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
+GPIO blocks.
+
+Required properties:
+- compatible: "keymile,qriox"
+- reg: access on the parent local bus (chip select, offset in chip select, size)
+
+Example:
+
+ board-control@1,0 {
+ compatible = "keymile,qriox";
+ reg = <1 0 0x80>;
+ };
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH 5/6] powerpc/powernv: Create OPAL sglist helper functions and fix endian issues
From: Vasant Hegde @ 2014-04-22 9:16 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, stewart; +Cc: linuxppc-dev
In-Reply-To: <1398142887-24109-5-git-send-email-anton@samba.org>
On 04/22/2014 10:31 AM, Anton Blanchard wrote:
> We have two copies of code that creates an OPAL sg list. Consolidate
> these into a common set of helpers and fix the endian issues.
>
> The flash interface embedded a version number in the num_entries
> field, whereas the dump interface did did not. Since versioning
> wasn't added to the flash interface and it is impossible to add
> this in a backwards compatible way, just remove it.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
> arch/powerpc/include/asm/opal.h | 14 ++--
> arch/powerpc/platforms/powernv/opal-dump.c | 81 +--------------------
> arch/powerpc/platforms/powernv/opal-flash.c | 106 +---------------------------
> arch/powerpc/platforms/powernv/opal.c | 63 +++++++++++++++++
> 4 files changed, 76 insertions(+), 188 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 1a752ac..afb0fed 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -41,14 +41,14 @@ struct opal_takeover_args {
> * size except the last one in the list to be as well.
> */
> struct opal_sg_entry {
> - void *data;
> - long length;
> + __be64 data;
> + __be64 length;
> };
>
> -/* sg list */
> +/* SG list */
> struct opal_sg_list {
> - unsigned long num_entries;
> - struct opal_sg_list *next;
> + __be64 length;
> + __be64 next;
> struct opal_sg_entry entry[];
> };
>
> @@ -929,6 +929,10 @@ extern int opal_resync_timebase(void);
>
> extern void opal_lpc_init(void);
>
> +struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
> + unsigned long vmalloc_size);
> +void opal_free_sg_list(struct opal_sg_list *sg);
> +
> #endif /* __ASSEMBLY__ */
>
> #endif /* __OPAL_H */
> diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
> index b9827b0..f0b4724 100644
> --- a/arch/powerpc/platforms/powernv/opal-dump.c
> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
> @@ -209,80 +209,6 @@ static struct kobj_type dump_ktype = {
> .default_attrs = dump_default_attrs,
> };
>
> -static void free_dump_sg_list(struct opal_sg_list *list)
> -{
> - struct opal_sg_list *sg1;
> - while (list) {
> - sg1 = list->next;
> - kfree(list);
> - list = sg1;
> - }
> - list = NULL;
> -}
> -
> -static struct opal_sg_list *dump_data_to_sglist(struct dump_obj *dump)
> -{
> - struct opal_sg_list *sg1, *list = NULL;
> - void *addr;
> - int64_t size;
> -
> - addr = dump->buffer;
> - size = dump->size;
> -
> - sg1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
> - if (!sg1)
> - goto nomem;
> -
> - list = sg1;
> - sg1->num_entries = 0;
> - while (size > 0) {
> - /* Translate virtual address to physical address */
> - sg1->entry[sg1->num_entries].data =
> - (void *)(vmalloc_to_pfn(addr) << PAGE_SHIFT);
> -
> - if (size > PAGE_SIZE)
> - sg1->entry[sg1->num_entries].length = PAGE_SIZE;
> - else
> - sg1->entry[sg1->num_entries].length = size;
> -
> - sg1->num_entries++;
> - if (sg1->num_entries >= SG_ENTRIES_PER_NODE) {
> - sg1->next = kzalloc(PAGE_SIZE, GFP_KERNEL);
> - if (!sg1->next)
> - goto nomem;
> -
> - sg1 = sg1->next;
> - sg1->num_entries = 0;
> - }
> - addr += PAGE_SIZE;
> - size -= PAGE_SIZE;
> - }
> - return list;
> -
> -nomem:
> - pr_err("%s : Failed to allocate memory\n", __func__);
> - free_dump_sg_list(list);
> - return NULL;
> -}
> -
> -static void sglist_to_phy_addr(struct opal_sg_list *list)
> -{
> - struct opal_sg_list *sg, *next;
> -
> - for (sg = list; sg; sg = next) {
> - next = sg->next;
> - /* Don't translate NULL pointer for last entry */
> - if (sg->next)
> - sg->next = (struct opal_sg_list *)__pa(sg->next);
> - else
> - sg->next = NULL;
> -
> - /* Convert num_entries to length */
> - sg->num_entries =
> - sg->num_entries * sizeof(struct opal_sg_entry) + 16;
> - }
> -}
> -
> static int64_t dump_read_info(uint32_t *id, uint32_t *size, uint32_t *type)
> {
> int rc;
> @@ -314,15 +240,12 @@ static int64_t dump_read_data(struct dump_obj *dump)
> }
>
> /* Generate SG list */
> - list = dump_data_to_sglist(dump);
> + list = opal_vmalloc_to_sg_list(dump->buffer, dump->size);
> if (!list) {
> rc = -ENOMEM;
> goto out;
> }
>
> - /* Translate sg list addr to real address */
> - sglist_to_phy_addr(list);
> -
> /* First entry address */
> addr = __pa(list);
>
> @@ -341,7 +264,7 @@ static int64_t dump_read_data(struct dump_obj *dump)
> __func__, dump->id);
>
Shouldn't we convert addr and id before passing to opal_dump_read() here ?
> /* Free SG list */
> - free_dump_sg_list(list);
> + opal_free_sg_list(list);
>
> out:
> return rc;
> diff --git a/arch/powerpc/platforms/powernv/opal-flash.c b/arch/powerpc/platforms/powernv/opal-flash.c
> index 714ef97..0ae9e5f 100644
> --- a/arch/powerpc/platforms/powernv/opal-flash.c
> +++ b/arch/powerpc/platforms/powernv/opal-flash.c
> @@ -79,9 +79,6 @@
> /* XXX: Assume candidate image size is <= 1GB */
> #define MAX_IMAGE_SIZE 0x40000000
>
> -/* Flash sg list version */
> -#define SG_LIST_VERSION (1UL)
> -
> /* Image status */
> enum {
> IMAGE_INVALID,
> @@ -268,93 +265,11 @@ static ssize_t manage_store(struct kobject *kobj,
> }
>
> /*
> - * Free sg list
> - */
> -static void free_sg_list(struct opal_sg_list *list)
> -{
> - struct opal_sg_list *sg1;
> - while (list) {
> - sg1 = list->next;
> - kfree(list);
> - list = sg1;
> - }
> - list = NULL;
> -}
> -
> -/*
> - * Build candidate image scatter gather list
> - *
> - * list format:
> - * -----------------------------------
> - * | VER (8) | Entry length in bytes |
> - * -----------------------------------
> - * | Pointer to next entry |
> - * -----------------------------------
> - * | Address of memory area 1 |
> - * -----------------------------------
> - * | Length of memory area 1 |
> - * -----------------------------------
> - * | ......... |
> - * -----------------------------------
> - * | ......... |
> - * -----------------------------------
> - * | Address of memory area N |
> - * -----------------------------------
> - * | Length of memory area N |
> - * -----------------------------------
> - */
> -static struct opal_sg_list *image_data_to_sglist(void)
> -{
> - struct opal_sg_list *sg1, *list = NULL;
> - void *addr;
> - int size;
> -
> - addr = image_data.data;
> - size = image_data.size;
> -
> - sg1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
> - if (!sg1)
> - return NULL;
> -
> - list = sg1;
> - sg1->num_entries = 0;
> - while (size > 0) {
> - /* Translate virtual address to physical address */
> - sg1->entry[sg1->num_entries].data =
> - (void *)(vmalloc_to_pfn(addr) << PAGE_SHIFT);
> -
> - if (size > PAGE_SIZE)
> - sg1->entry[sg1->num_entries].length = PAGE_SIZE;
> - else
> - sg1->entry[sg1->num_entries].length = size;
> -
> - sg1->num_entries++;
> - if (sg1->num_entries >= SG_ENTRIES_PER_NODE) {
> - sg1->next = kzalloc(PAGE_SIZE, GFP_KERNEL);
> - if (!sg1->next) {
> - pr_err("%s : Failed to allocate memory\n",
> - __func__);
> - goto nomem;
> - }
> -
> - sg1 = sg1->next;
> - sg1->num_entries = 0;
> - }
> - addr += PAGE_SIZE;
> - size -= PAGE_SIZE;
> - }
> - return list;
> -nomem:
> - free_sg_list(list);
> - return NULL;
> -}
> -
> -/*
> * OPAL update flash
> */
> static int opal_flash_update(int op)
> {
> - struct opal_sg_list *sg, *list, *next;
> + struct opal_sg_list *list;
> unsigned long addr;
> int64_t rc = OPAL_PARAMETER;
>
> @@ -364,30 +279,13 @@ static int opal_flash_update(int op)
> goto flash;
> }
>
> - list = image_data_to_sglist();
> + list = opal_vmalloc_to_sg_list(image_data.data, image_data.size);
> if (!list)
> goto invalid_img;
>
> /* First entry address */
> addr = __pa(list);
>
> - /* Translate sg list address to absolute */
> - for (sg = list; sg; sg = next) {
> - next = sg->next;
> - /* Don't translate NULL pointer for last entry */
> - if (sg->next)
> - sg->next = (struct opal_sg_list *)__pa(sg->next);
> - else
> - sg->next = NULL;
> -
> - /*
> - * Convert num_entries to version/length format
> - * to satisfy OPAL.
> - */
> - sg->num_entries = (SG_LIST_VERSION << 56) |
> - (sg->num_entries * sizeof(struct opal_sg_entry) + 16);
> - }
> -
> pr_alert("FLASH: Image is %u bytes\n", image_data.size);
> pr_alert("FLASH: Image update requested\n");
> pr_alert("FLASH: Image will be updated during system reboot\n");
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index 17cfc70..360ad80c 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -638,3 +638,66 @@ void opal_shutdown(void)
>
> /* Export this so that test modules can use it */
> EXPORT_SYMBOL_GPL(opal_invalid_call);
> +
> +/* Convert a region of vmalloc memory to an opal sg list */
> +struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
> + unsigned long vmalloc_size)
> +{
> + struct opal_sg_list *sg, *first = NULL;
> + unsigned long i = 0;
> +
> + sg = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!sg)
> + goto nomem;
> +
> + first = sg;
> +
> + while (vmalloc_size > 0) {
> + uint64_t data = vmalloc_to_pfn(vmalloc_addr) << PAGE_SHIFT;
> + uint64_t length = min(vmalloc_size, PAGE_SIZE);
> +
> + sg->entry[i].data = cpu_to_be64(data);
> + sg->entry[i].length = cpu_to_be64(length);
> + i++;
> +
> + if (i >= SG_ENTRIES_PER_NODE) {
> + struct opal_sg_list *next;
> +
> + next = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!next)
> + goto nomem;
> +
> + sg->length = cpu_to_be64(
> + i * sizeof(struct opal_sg_entry) + 16);
> + i = 0;
> + sg->next = cpu_to_be64(__pa(next));
> + sg = next;
> + }
> +
> + vmalloc_addr += length;
> + vmalloc_size -= length;
> + }
> +
> + sg->length = cpu_to_be64(i * sizeof(struct opal_sg_entry) + 16);
> +
> + return first;
> +
> +nomem:
> + pr_err("%s : Failed to allocate memory\n", __func__);
> + opal_free_sg_list(first);
> + return NULL;
> +}
> +
> +void opal_free_sg_list(struct opal_sg_list *sg)
> +{
> + while (sg) {
> + uint64_t next = be64_to_cpu(sg->next);
> +
> + kfree(sg);
> +
> + if (next)
> + sg = __va(next);
This for this fix..
-Vasant
> + else
> + sg = NULL;
> + }
> +}
>
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/powernv: Fix little endian issues in OPAL dump code
From: Vasant Hegde @ 2014-04-22 8:32 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, stewart; +Cc: linuxppc-dev
In-Reply-To: <1398142887-24109-6-git-send-email-anton@samba.org>
On 04/22/2014 10:31 AM, Anton Blanchard wrote:
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
> arch/powerpc/include/asm/opal.h | 4 ++--
> arch/powerpc/platforms/powernv/opal-dump.c | 13 +++++++++----
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index afb0fed..66ad7a7 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -868,8 +868,8 @@ int64_t opal_validate_flash(uint64_t buffer, uint32_t *size, uint32_t *result);
> int64_t opal_manage_flash(uint8_t op);
> int64_t opal_update_flash(uint64_t blk_list);
> int64_t opal_dump_init(uint8_t dump_type);
> -int64_t opal_dump_info(uint32_t *dump_id, uint32_t *dump_size);
> -int64_t opal_dump_info2(uint32_t *dump_id, uint32_t *dump_size, uint32_t *dump_type);
> +int64_t opal_dump_info(__be32 *dump_id, __be32 *dump_size);
> +int64_t opal_dump_info2(__be32 *dump_id, __be32 *dump_size, __be32 *dump_type);
> int64_t opal_dump_read(uint32_t dump_id, uint64_t buffer);
> int64_t opal_dump_ack(uint32_t dump_id);
Shouldn't we change above two functions as well ?
> int64_t opal_dump_resend_notification(void);
> diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
> index f0b4724..788a197 100644
> --- a/arch/powerpc/platforms/powernv/opal-dump.c
> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
> @@ -209,15 +209,20 @@ static struct kobj_type dump_ktype = {
> .default_attrs = dump_default_attrs,
> };
>
> -static int64_t dump_read_info(uint32_t *id, uint32_t *size, uint32_t *type)
> +static int64_t dump_read_info(uint32_t *dump_id, uint32_t *dump_size, uint32_t *dump_type)
> {
> + __be32 id, size, type;
> int rc;
> - *type = 0xffffffff;
>
> - rc = opal_dump_info2(id, size, type);
> + type = cpu_to_be32(0xffffffff);
>
> + rc = opal_dump_info2(&id, &size, &type);
> if (rc == OPAL_PARAMETER)
> - rc = opal_dump_info(id, size);
> + rc = opal_dump_info(&id, &size);
> +
> + *dump_id = be32_to_cpu(id);
> + *dump_size = be32_to_cpu(size);
> + *dump_type = be32_to_cpu(type);
>
Should we convert ID back to BE format in dump_send_ack() ?
-Vasant
> if (rc)
> pr_warn("%s: Failed to get dump info (%d)\n",
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform
From: Benjamin Herrenschmidt @ 2014-04-22 8:25 UTC (permalink / raw)
To: Wei Yang; +Cc: aik, linuxppc-dev, Gavin Shan
In-Reply-To: <20140422074437.GB6431@richard>
On Tue, 2014-04-22 at 15:44 +0800, Wei Yang wrote:
> So this patch(the 2nd one) doesn't contribute to clear the warning and
> error.
> Only the first patch did it. Please ignore this one.
But is it correct ? It's not right to keep a refcount elevated if we
don't have to.
Gavin, can you get to the bottom of that refcount business ?
Cheers,
Ben.
^ 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