On 07/25/17 21:55, David Gibson wrote: > On Mon, Jul 24, 2017 at 11:06:49AM -0700, Frank Rowand wrote: >> On 07/14/17 00:21, Pantelis Antoniou wrote: >> >> Keeping in mind that this thread was originally about libfdt, >> not the Linux kernel, I am mostly talking about the Linux >> kernel implementation in this email. >> >> >>> Hi Frank, >>> >>> On Thu, 2017-07-13 at 14:40 -0700, Frank Rowand wrote: >>>> On 07/13/17 14:22, Phil Elwell wrote: >>>>> On 13/07/2017 21:07, Frank Rowand wrote: >>>>>> On 07/13/17 12:38, Phil Elwell wrote: >>>>>> >>> >>> [snip] >>> >>>>> hope an inability to solve the problem posed by this advanced usage won't >>>>> prevent a solution to a simpler problem from being accepted. >>> >>> I have waited until people started commenting on this patchset before >>> replying. >>> >>> I think we agree on a few things to keep the discussion moving forward. >>> >>> 1. Stacked overlays are useful and make overlays easier to use. >> >> Stacked overlays are required to handle an add-on board that >> contains physical connectors to plug in yet more things. >> >> I'm not sure what you mean when you say they "make overlays >> easier to use". Can you elaborate on that a little bit? >> >> >>> 2. Changing the overlay symbols format now would be unwise. >> >> I strongly disagree. I would say that it is desirable to maintain >> the current overlay format (not just __symbols__), and that there >> will be pain (for bootloaders???) if the format changes. But >> the Linux implementation is not locked in if there is a good >> reason to change the format. >> >> >>> 3. A number of extensions have been put forward/requested. >>> >>> 3.1. There should be a method to place a symbol on a node that didn't >>> have one originally (due to vendor supplying broken DTB or being >>> generated by firmware at runtime). >> >> You saw my reaction of what to do about a broken vendor DTB in that >> thread. I do not think this method is a good idea. >> >> I don't know why a DTB generated by firmware would be missing a symbol. >> Was that discussed in that thread, and I'm just forgetting it? > > Because 9 times out of 10, firmware is crap? Which is part of why I want access to, ability to modify, and ability to update device trees in the hands of the user, not just the vendor. -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
