Re: [PATCH 2/4] sparc: break out some prom device-tree building code out into drivers/of
From: Grant Likely <hidden>
Date: 2010-07-06 22:07:53
Also in:
lkml, sparclinux
On Tue, Jul 6, 2010 at 3:54 PM, Andres Salomon [off-list ref] wrote:
On Tue, 6 Jul 2010 03:21:21 -0600 Grant Likely [off-list ref] wrote:quoted
On Mon, Jun 28, 2010 at 8:00 PM, Andres Salomon [off-list ref] wrote:quoted
Stick code into drivers/of/pdt.c (Prom Device Tree) that other architectures with OpenFirmware resident in memory can make use of. Signed-off-by: Andres Salomon <redacted>Some more comments below...Thanks for the review!quoted
quoted
arch/sparc/Kconfig | 1 + arch/sparc/include/asm/prom.h | 15 +++- arch/sparc/kernel/prom.h | 14 --- arch/sparc/kernel/prom_common.c | 173 +------------------------------ drivers/of/Kconfig | 4 + drivers/of/Makefile | 1 + drivers/of/pdt.c | 225 +++++++++++++++++++++++++++++++++++++++ include/linux/of_pdt.h | 37 +++++++ 8 files changed, 282 insertions(+), 188 deletions(-) create mode 100644 drivers/of/pdt.c create mode 100644 include/linux/of_pdt.hdiff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 6f1470b..b4cb63b 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig@@ -150,6 +150,7 @@ config ARCH_NO_VIRT_TO_BUSconfig OF def_bool y + select OF_PROMTREE config ARCH_SUPPORTS_DEBUG_PAGEALLOC def_bool y if SPARC64diff --git a/arch/sparc/include/asm/prom.hb/arch/sparc/include/asm/prom.h index f845828..0834c2a 100644--- a/arch/sparc/include/asm/prom.h +++ b/arch/sparc/include/asm/prom.h@@ -18,6 +18,7 @@* 2 of the License, or (at your option) any later version. */ #include <linux/types.h> +#include <linux/of_pdt.h> #include <linux/proc_fs.h> #include <linux/mutex.h> #include <asm/atomic.h>@@ -65,8 +66,18 @@ extern struct device_node *of_console_device;extern char *of_console_path; extern char *of_console_options; -extern void (*prom_build_more)(struct device_node *dp, struct device_node ***nextp); -extern char *build_full_name(struct device_node *dp); +/* stuff used by of/pdt */ +extern void * prom_early_alloc(unsigned long size); +extern void irq_trans_init(struct device_node *dp); +extern char *build_path_component(struct device_node *dp); + +extern char *prom_firstprop(int node, char *buffer); +extern char *prom_nextprop(int node, const char *oprop, char *buffer); +extern int prom_getproplen(int node, const char *prop); +extern int prom_getproperty(int node, const char *prop, + char *buffer, int bufsize); +extern int prom_getchild(int node); +extern int prom_getsibling(int node);These become the API required by of/pdt. They should be defined in a arch-independent header file. Something like include/linux/of_pdt.h Right now only OLPC will be using this, so static function definitions are just fine. However, if there is ever more than one method for talking to OFW, then these hooks will need to be converted into an ops structure so the right one can be passed in at runtime.Note that sparc and OLPC actually use slightly different function signatures; OLPC uses phandles for nodes, while sparc uses ints. Not a huge difference, but enough that I didn't want to mess w/ a generic version of it early in the process.
phandle is simply defined as a u32. It probably wouldn't be difficult to change the sparc code to use phandle; redefining the type for sparc if need be.
I agree that op structs would be nicer, and will probably move towards that. [...]quoted
quoted
diff --git a/include/linux/of_pdt.h b/include/linux/of_pdt.h new file mode 100644 index 0000000..f62616e --- /dev/null +++ b/include/linux/of_pdt.h@@ -0,0 +1,37 @@ +#include <linux/of.h> /* linux/of.h gets to determine #includeordering */Do you really need this #include in this way? Can it be moved inside the #ifndef OF_PDT block below?Not sure, will try out different variants and see what breaks. [...]quoted
Another general comment, I'm still not thrilled with this code having its own independent method for building the tree, but I doubt the existing add/remove nodes and properties code is usable early enough to be suitable for sparc. How early do you extract the device tree on OLPC? How are you going to use the data?Not that early; very early code fetches information necessary to call into the PROM, and ensures that the kernel doesn't clobber OFW's memory. After that, we can build the dt at any point during init. The data is to be exported via proc for userspace to use in determining hardware (and firmware) info.
Okay, so it is only the userspace interface that you're interested in, correct? You have no needs/plans (as of yet) to register devices out of the device tree? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.