On Tue, Jul 6, 2010 at 3:54 PM, Andres Salomon <dilinger@xxxxxxxxxx> wrote: > On Tue, 6 Jul 2010 03:21:21 -0600 > Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > >> On Mon, Jun 28, 2010 at 8:00 PM, Andres Salomon <dilinger@xxxxxxxxxx> >> wrote: >> > >> > 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 <dilinger@xxxxxxxxxx> >> >> Some more comments below... >> > > Thanks for the review! > > > >> > 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.h >> > >> > diff --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_BUS >> > >> > config OF >> > def_bool y >> > + select OF_PROMTREE >> > >> > config ARCH_SUPPORTS_DEBUG_PAGEALLOC >> > def_bool y if SPARC64 >> > diff --git a/arch/sparc/include/asm/prom.h >> > b/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. > > [...] > >> > 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 #include >> > ordering */ >> >> 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. > > [...] > >> 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. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
