[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100630173218.2bdd18d4@dev.queued.net>
Date: Wed, 30 Jun 2010 17:32:18 -0400
From: Andres Salomon <dilinger@...ued.net>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: devicetree-discuss@...ts.ozlabs.org, sparclinux@...r.kernel.org,
x86@...nel.org, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, cjb@...top.org, Mitch Bradley <wmb@...top.org>,
pgf@...top.org, linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH 4/4] x86: OLPC: add OLPC device-tree support
On Wed, 30 Jun 2010 15:13:26 -0600
Grant Likely <grant.likely@...retlab.ca> wrote:
> On Tue, Jun 29, 2010 at 8:23 AM, Andres Salomon <dilinger@...ued.net>
> wrote:
> > On Tue, 29 Jun 2010 01:12:36 -0700
> > Grant Likely <grant.likely@...retlab.ca> wrote:
[...]
> >> > +extern void prom_build_devicetree(void);
> >> > +
> >> > +extern void *prom_early_alloc(unsigned long size);
> >> > +
> >> > +extern char *prom_firstprop(phandle node, char *buf);
> >> > +extern char *prom_nextprop(phandle node, const char *prev, char
> >> > *buf); +extern int prom_getproplen(phandle node, const char
> >> > *prop); +extern int prom_getproperty(phandle node, const char
> >> > *prop,
> >> > + char *buffer, int bufsize);
> >> > +extern phandle prom_getchild(phandle node);
> >> > +extern phandle prom_getsibling(phandle node);
> >> > +
> >> > +#endif /* __KERNEL__ */
> >> > +#endif /* _X86_PROM_OLPC_H */
> >> > diff --git a/arch/x86/include/asm/prom.h
> >> > b/arch/x86/include/asm/prom.h new file mode 100644
> >> > index 0000000..7b561b2
> >> > --- /dev/null
> >> > +++ b/arch/x86/include/asm/prom.h
> >> > @@ -0,0 +1,5 @@
> >> > +#ifdef CONFIG_OLPC_OPENFIRMWARE
> >> > +# include <asm/olpc_prom.h>
> >> > +#else
> >> > +# error "No OFW prom defined for x86!"
> >> > +#endif
> >>
> >> Personally, I wouldn't bother with the header file redirection.
> >
> > The reason for the header file redirection is because this is
> > OLPC-only; the x86 folks don't want me claiming this to be the One
> > True x86 OFW.
>
> However, the #ifdef/#elseif/#else/#endif approach also makes the
> assumption that only one kind of OFW will be supported by any given
> kernel. Or for that matter, both OFW and the flattened tree also
> become mutually exclusive due to the default behaviour override.
>
> Besides, aren't the function declarations just the interface defined
> by the prom extraction code? Is there any need to #ifdef that API? I
> would think those function prototypes should be defined by the header
> for the prom extraction code.
Mm, both are good points; I suppose for now it doesn't hurt to lose the
#ifdefs, and deal w/ additional x86 proms support if it comes up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists