Re: [PATCH v3 00/15] fdtfactor: Introduce fdtfactor to auto-factor overlays

From: Doug Anderson

Date: Fri Nov 06 2026 - 21:43:13 EST


Hi Simon,

On Wed, Nov 4, 2026 at 7:14 AM Simon Glass <sjg@xxxxxxxxxxxx> wrote:
>
> Hi Doug,
>
> On 2026-11-01T22:01:07, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> > Before introducing `fdtfactor` itself, the series starts with a few
> > preparatory patches: adding a `DeviceTree` live-tree abstraction in
> > `devicetree.py`, and teaching `libfdt`'s `fdt_overlay_apply()` to update
> > `/__local_fixups__` on the base tree so overlays can be applied in
> > multiple stages.
>
> Just to check, is this still the motivation? Stacked overlays work
> without it, since fdt_overlay_apply() does not read the base tree's
> /__local_fixups__ when resolving an overlay, and the stacked_overlay
> tests pass in a -Doverlay-local-fixups=0 build. The commit message
> gives a different reason (keeping phandle metadata in merged trees).

That phrasing in the cover letter was a leftover from earlier versions.
I've updated the cover letter in my draft v4 so it matches the commit
message motivation:

Before introducing `fdtfactor` itself, the series starts with a few
preparatory patches: adding a `DeviceTree` live-tree abstraction in
`pylibfdt/devicetree.py` (with supporting `Property` and `FdtSw`
enhancements), and teaching `libfdt`'s `fdt_overlay_apply()` to update
`/__local_fixups__` on the base tree so merged trees retain complete and
accurate phandle location metadata (for runtime consumers, composite
`.dtb`s built by `fdtoverlay` that are later fed into `fdtfactor`, and
round-trip verification against `dtc -L`).


-Doug