On 01/24/18 13:16, Frank Rowand wrote: > On 01/24/18 07:47, Rob Herring wrote: >> On Tue, Jan 23, 2018 at 3:17 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: >>> On 01/23/18 04:42, David Gibson wrote: >>>> On Mon, Jan 22, 2018 at 03:01:52PM -0600, Rob Herring wrote: >>>>> On Mon, Jan 22, 2018 at 2:09 AM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: < snip > >>> My first shot at the new format added a field to the FDT to indicate >>> that an overlay FDT was concatenated to the FDT (and the overlay FDT >>> in turn could set it's field to concatenate another overlay FDT). < snip > >>> For ease of typing, I'll call this "chaining" or "chained". For >>> Linux, I am envisioning no kernel use of data from a chained FDT >>> until after the tree is unflattened. I haven't done an exhaustive >>> search to determine all of the uses of data directly from the >>> flattened FDT, but I am optimistic that there will not be any such >>> access that would require data from a chained FDT (and we could >>> make this a rule). >> >> This would be a major downside to leaving it up to the kernel because >> what can't be touched is hard to enumerate and could change. For >> example, we added earlycon and now the uart node can't be modified. > > What you say makes sense. So I'll reverse myself and say that for > Linux, we should update the FDT read code to scan all chained > overlay FDT(s) as well as the base FDT. < snip > And I'll reverse myself again, so full circle. As David pointed out elsewhere, targeting overlay fragments to their actual position in the tree makes a function that scans the chained FDTs for a property value (as an example) very complex. Given that insight, I agreed with David. With that further background, I'm back here to reconsider devicetree data that is accessed by the kernel early in boot, before the devicetree is unflattened. The early boot time frame can be a difficult environment to code within. There are a lot of limitations to what features and services are available. We try to limit the amount of code in this window to as little as possible. Given that, is it reasonable to assume that we won't be adding a lot of code that accesses the devicetree before it is unflattened? I wouldn't say zero code, but I would hope very little code. *** I'm thinking out loud as I'm typing this, and it turns *** out that this following paragraph is not workable, *** so after this paragraph, I'll reject it. So don't *** take this paragraph as a serious proposal. If that premise is accepted, and if we added _either_ a specification restriction on overlays _or_ a warning or "don't come crying to us if you need to modify your existing base FDT and/or overlay FDT to take advantage of a _new_ early boot feature", how does that change things? The restriction would be something like (could take a different form that accomplishes the same goal): the base FDT must contain all data that is used by pre-unflatten code and overlay FDTs must not modify that data. And now I've wrapped myself info a tight little ball that will not work, because detecting (and preventing) an overlay from modifying this data is an unreasonable amount of complexity. The best that I could do would be to say: all data that is used by pre-unflatten code must be contained in the base FDT, if an overlay FDT modifies any of this data, the pre-unflatten feature has the option of ignoring the changes, or at some point after unflattening, re-reading the data from the expanded tree. That leaves a bad taste in my mouth, I don't like it. But it is a possible compromise. Another option would be to remove as much of the pre-unflatten data access as possible, moving the accesses to just after unflattening and accept that some features just won't be available until after unflattening. Can we reduce this set of data to data that is not modifiable by an overlay (such as mem_rsvmap) or is that too constricting? I'll continue to ponder this area... -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
