fdtoverlay does not support full path notion for a reference to another node in a cell array about dtc

[dgibson]

Sorry, I haven't replied in so long, I managed to miss this report.

As I recall the runtime overlays (as opposed to dtc compile time overlays) weren't really built to use non-symbol references. But I don't see any reason this shouldn't work.

Your patch looks correct, but isn't ideal. A reference starting with '/' must always be a path, not a symbol, so you should chek for that first, before attempting to resolve it as a symbol.

If you could send a patch to the mailing list, or make up a pull request with a proper commit message that would be great.

[usual-user]

I do not know much about the dtc code but this was the issue I wanted to solve:
I am tinkering in an environment of a Fedora LXQt desktop on an arm imx6 platform. The distribution kernels come with several hundred dtb files. Rightfully without symbols compiled in to keep the size as small as possible. The need by anyone to apply overlays is quite sparse if at all. So every time a kernel update came in, I had to pull in the kernel sources, apply some dts patch to enable e.g. an attached camera and compile the dtb. This step has to be repeated if you want to apply several components in variing combinations. Those dts patches can't even land in mainline cause there individual manner. Current overlays can also not land in mainline as they can't be always applied against a dtb without symbols.
With "target_path" I was able to compose some overlays that could be applied with fdtoverlay to a dtb without symbols. But as soon as a label notion for a reference to another node in a cell array came into play I had lost.
While researching some other aspect of dts syntax I stumbled over the full path notion and realized this could solve my issue. Compiling an overlay with this syntax let the dtbo earn exact the information that fdtoverlay tries to acquire with the symbol resolution. So it was a small step to short-circuit the resolution in fdtoverlay with my provided patch as the "/" as first symbol character marks this situation.
Nowadays, if a kernel update comes in, I have only to do "fdtoverlay -i imx6q-hummingboard.dtb -o imx6q-hummingboard.dtb imx6q-hummingboard-pcam5c.dtbo" and I am done. Doing several flavors with different overlays is also a no-brainer.
With this feature in mainline dtc such overlays have even potential to land in mainline for general consumption. The "included symbols" constraint is removed and they can always be applied against a base dtb without any prior overlay preparation. As you say it can potentially work also with runtime overlays, even better.
Unfortunately I don't have the skill to implement it the proper way, so don't hesitate to take my proposal forward and make the world a little easier. If there shows up some proper implementation I am willingly prepared to do testing and give feedback.