On Wed, Jul 26, 2017 at 07:03:11AM -0700, Frank Rowand wrote: > 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. Couldn't agree more. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
