Prev: [PATCH 0/9] [GI PULL][2.6.36] tracing: various updates
Next: [PATCH 7/9] tracing: Remove open-coded __trace_add_event_call()
From: David Miller on 28 Jun 2010 23:20
From: Andres Salomon <dilinger(a)queued.net>
Date: Mon, 28 Jun 2010 22:00:37 -0400

>
> 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(a)queued.net>

Acked-by: David S. Miller <davem(a)davemloft.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Rothwell on 29 Jun 2010 02:20
Hi Andres,

On Mon, 28 Jun 2010 22:00:37 -0400 Andres Salomon <dilinger(a)queued.net> wrote:
>
> 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

Please put this select in CONFIG_SPARC instead as we want to move
CONFIG_OF to drivers/og/Kconfig

--
Cheers,
Stephen Rothwell sfr(a)canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: David Miller on 5 Jul 2010 22:30
From: Andres Salomon <dilinger(a)queued.net>
Date: Wed, 7 Jul 2010 04:07:34 +0000

> - For the pdt, calling into the prom once for each property/node to
> create a fdt, and then unflattening it. This is better than the
> previous option, but I don't think the prom->fdt code will be very
> nice.

I'll need this on sparc64 at some point to support kexec() anyways.

So at least for sparc you can assume that a something-->fdt translator
is going to exist at some point in the future regardless of what
happens here.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andres Salomon on 5 Jul 2010 23:30
On Mon, 05 Jul 2010 19:22:21 -0700 (PDT)
David Miller <davem(a)davemloft.net> wrote:

> From: Andres Salomon <dilinger(a)queued.net>
> Date: Wed, 7 Jul 2010 04:07:34 +0000
>
> > - For the pdt, calling into the prom once for each property/node to
> > create a fdt, and then unflattening it. This is better than the
> > previous option, but I don't think the prom->fdt code will be
> > very nice.
>
> I'll need this on sparc64 at some point to support kexec() anyways.
>
> So at least for sparc you can assume that a something-->fdt translator
> is going to exist at some point in the future regardless of what
> happens here.
>


Sounds like we have a winner. I'll concentrate on that, thanks for
the heads up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 6 Jul 2010 03:20
From: Grant Likely <grant.likely(a)secretlab.ca>
Date: Tue, 6 Jul 2010 01:00:06 -0600

> I'm curious... what are your plans here? Will you be keeping OF alive
> between kexec()? Will the new kernel get the entire device tree from
> fdt, or will it still be talking to OF? How will the fdt fragments as
> Andres described above fit into sparc kexec (as opposed to generating
> one big tree as in his first option)?

On certain sparc64 systems, I have to stop making PROM calls early
in the boot right after I fetch the device tree into the kernel.

So yes for a kexec() I'll have to pass an fdt or similar to the
child kernel.

It could be a big linear fdt buffer, or fragments, it really doesn't
matter all that much actually.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: [PATCH 0/9] [GI PULL][2.6.36] tracing: various updates
Next: [PATCH 7/9] tracing: Remove open-coded __trace_add_event_call()