[PATCH] of/fdt: add kernel command line option for dtb_compat string

[Grant Likely]

On Mon, Dec 06, 2010 at 01:50:47PM -0800, Stephen Neuendorffer wrote:
> 
> 
> > -----Original Message-----
> > From: Dirk Brandewie [mailto:dirk.brandewie at gmail.com]
> > Sent: Monday, December 06, 2010 11:03 AM
> > To: Stephen Neuendorffer
> > Cc: linux-kernel at vger.kernel.org; Randy Dunlap;
> devicetree-discuss at lists.ozlabs.org; linux-
> > doc at vger.kernel.org; grant.likely at secretlab.ca
> > Subject: Re: [PATCH] of/fdt: add kernel command line option for
> dtb_compat string
> > 
> > On 12/06/2010 11:01 AM, Dirk Brandewie wrote:
> > > On 12/06/2010 10:37 AM, Stephen Neuendorffer wrote:
> > >>
> > >>
> > >>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > >>> index c1360e0..ca1318c 100644
> > >>> --- a/drivers/of/fdt.c
> > >>> +++ b/drivers/of/fdt.c
> > >>> @@ -15,6 +15,8 @@
> > >>> #include<linux/of_fdt.h>
> > >>> #include<linux/string.h>
> > >>> #include<linux/errno.h>
> > >>> +#include<asm-generic/vmlinux.lds.h>
> > >>> +
> > >>>
> > >>> #ifdef CONFIG_PPC
> > >>> #include<asm/machdep.h>
> > >>> @@ -604,3 +606,49 @@ void __init unflatten_device_tree(void)
> > >>>
> > >>> pr_debug("<- unflatten_device_tree()\n");
> > >>> }
> > >>> +
> > >>> +extern uint8_t __dtb_start[];
> > >>> +extern uint8_t __dtb_end[];
> > >>> +static void __init *of_flat_dt_find_compatible_dtb(char *name)
> > >>> +{
> > >>> + void *rc = NULL;
> > >>> + unsigned long root, size;
> > >>> + struct boot_param_header *orig_initial_boot_params;
> > >>> + uint8_t *blob;
> > >>> +
> > >>> + orig_initial_boot_params = initial_boot_params;
> > >>> + blob = __dtb_start;
> > >>> + initial_boot_params = (struct boot_param_header *)blob;
> > >>
> > >> Oy... can you avoid the pointer dance by using
> of_fdt_is_compatible()
> > >> from my recent set of patches?
> > >
> > > I would like to get rid of the pointer dance. Is your patch set
> going to make it
> > > into .37? I didn't see any acks.
> > >
> > Obviously I meant .38 :-)
> 
> I'd like it too, but that's up to Grant.  I imagine some of the
> bottleneck is that I don't have
> an easy way to test on powerpc or microblaze at the moment, so it's not
> clear that the code doesn't
> break anything.

It's in my -next branch now.

g.