Re: [PATCH 1/2] fdt: Allow stacked overlays phandle references

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]