Re: [PATCH 0/7] of: overlay: Add support for export-symbols node feature

[Ayush Singh <ayush@beagleboard.org>]

On 10/01/25 09:56, David Gibson wrote:
> On Wed, Jan 08, 2025 at 10:47:19AM +0100, Herve Codina wrote:
>> Hi Ayush,
>>
>> On Wed, 8 Jan 2025 13:58:04 +0530
>> Ayush Singh <ayush@beagleboard.org> wrote:
>>
>> ...
>>>
>>> I will experiment with adding support to dtc and see how things look.
>>> Hopefully, 2025 is the year of addon board support.
>>>
>>
>> Also one point different between fdtoverlay an runtime loading is
>> that runtime loading allows to set the target node of the overlay
>> at runtime.
> 
> I'm not really sure what you mean by "runtime loading".  Do you mean
> the kernel's implementation of loading dtbo overlays?
> 
> While that is a different implementation from the one in fdtoverlay
> (AIUI), they're both working from the same dtb format.  As we
> discovered attempting Ayush's proposal, it turns out that the dtbo
> simply doesn't have the information we need to correctly path
> substitutions; and it's not at all easy to add it.

Ahh, I think there is a misunderstanding. `export-symbols` only seems to 
support phandles, not paths. So no resizing involved.

It's closer to the phandle support in `__symbols__`, just local in scope.

> 
> So, the problem of the encoding format needs to be solved regardless
> of which implementation is actually processing the overlays.
> 

So there is no problem with the encoding format.

The questions I have are more regarding weather `export-symbols` or 
something close to it can be made part of spec instead of the custom 
linux thing.


Ayush Singh