Rob Herring <robh+dt@xxxxxxxxxx> writes: > On Wed, Apr 5, 2017 at 9:32 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: >> On Wed, 5 Apr 2017 08:35:06 -0500 >> Rob Herring <robh+dt@xxxxxxxxxx> wrote: >> >>> On Wed, Apr 5, 2017 at 7:37 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: >>> > 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
