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

[Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html