Re: [PATCH v2 07/15] dtc: Move label-reference handling out of the grammar

[Herve Codina <herve.codina@bootlin.com>]

Hi Simon,

On Fri, 6 Nov 2026 06:05:52 -0700
Simon Glass <sjg@chromium.org> wrote:

...

> 
> It's only very minor. For example:
> 
> /plugin/;
> &foo { mine: x { a; }; };
> / { bar { }; };
> &mine { b; };
> &foo { c; };
> 
> This series will have bar between fragment@0 and fragment@1, but with
> this change it comes before both fragments. I think that is fine to do
> that, just that to my mind it fits better with step 2b of David’s
> plan, where each fragment is wrapped in fragment@N after the merge.
> There are a couple of other corner cases too, which I'm looking at.

I suppose fragment@0 and fragment@1 are the overlay output dts. If so, yes,
I think also it is fine.

Still need to be acked by David.

Otherwise the solution could be to have only fragments after parsing (the
root node is a fragment).

merge_fragments() merge fragments in previous one.

The fragment list in dt_info contains orphans + the root node.
The fragments order shouldn't be modified in that case.

Then overlay_convert_output_format() will have to deal with that.

Anyway, I don't think that adding this complexity is necessary to handle
this "bar in middle" use case.

In the end, nodes are not supposed to be ordered. Anything depending on
node ordering is not correct.

IHMO, internal fragments are obviously in an ordered list (same order as
input file) but nodes in the output file don't have any order requirements
except if '--sort' option is used but it should be already ok if you perform
the sort after the overlay_convert_output_format() call.

> 
> Anyway I've got a patch for your change and I'd like to put it at the
> end of the v3 series, since I am trying to move code largely unchanged
> out of the parser, avoiding behaviour changes as much as possible in
> this series. Does that sound OK?

No problem. Having it at the end of the series is ok on my side.

Best regards,
Hervé