Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle

Rob Herring [off-list ref] writes:

On Wed, Apr 5, 2017 at 9:32 AM, Nicholas Piggin [off-list ref] wrote:

quoted

On Wed, 5 Apr 2017 08:35:06 -0500
Rob Herring [off-list ref] wrote:

quoted

On Wed, Apr 5, 2017 at 7:37 AM, Nicholas Piggin [off-list ref] wrote:

quoted

Introduce primitives for FDT parsing. These will be used for powerpc
cpufeatures node scanning, which has quite complex structure but should
be processed early.

Have you looked at unflattening the FDT earlier?

Hi, thanks for taking a look. Did you mean to trim the cc list?

Ugg, no. I've added everyone back.

quoted

It may be possible but I'd like to avoid it if we can. There might
turn out to be some errata or feature that requires early setup. And
the current cpu feature parsing code does it with flat dt.

Well, I'd like to avoid expanding usage of flat DT parsing in the
kernel. But you could just put this function into arch/powerpc and I'd
never see it, but I like that even less. Mainly, I just wanted to
raise the point.

Your argument works until you need that setup in assembly code, then
you are in the situation that you need to either handle the setup in
bootloader/firmware or have an simple way to determine that condition.

Where Nick does this FDT parsing is literally the first C code that runs
in the kernel. The MMU is off, we don't even know how much memory we
have, or where it is.

So it's basically impossible to do the unflattening earlier. What we
could do is move the CPU feature setup *later*.

As Ben & Nick said that would be a pretty intrusive change, and
definitely not something we want to do now.

What we could probably do is split some of the flat tree parsing, so
that we discover memory, even just some of it, then unflatten, and then
do more setup using the unflattened tree.

But that will require a lot of delicate work. So we'd definitely like to
do that separately from this series.

cheers