Re: [PATCH v2] xen/dt-overlay: support phandle-based targeting in overlay_get_nodes_info

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2026-04-28 12:22, Orzel, Michal wrote:
> On 28-Apr-26 10:20, Nicola Vetrini wrote:
>> On 2026-04-28 10:02, Michal Orzel wrote:
>>> overlay_get_nodes_info() is called before fdt_overlay_apply() to
>>> extract
>>> target paths from the overlay. This fails for overlays using
>>> phandle-based
>>> targeting (target = <&label>) because DTC compiles these as 
>>> unresolved
>>> fixups (target = <0xffffffff>), causing fdt_overlay_target_offset() 
>>> to
>>> return -FDT_ERR_BADPHANDLE. Prior to this change users were forced to
>>> manually modify the dtbo (even for hwdom) to switch from target to
>>> target-phandle by manually inspecting also the host DTB.
>>> 
>>> Introduce overlay_get_target_path() which directly handles the two
>>> targeting cases that occur before fixup resolution:
>>>  - target-path: the string property is returned directly.
>>>  - target = <&label>: the label is found in the overlay's __fixups__
>>>    node, then resolved to a path via the base DTB's __symbols__ node.
>>> 
>>> Libfdt fdt_for_each_property_offset() violates MISRA R20.7. Despite
>>> libfdt being excluded from the analysis, this causes ECLAIR scan to
>>> report a regression because the violation introduced by a macro is
>>> reported at the call site. Deviate R20.7 for libfdt.h.
>>> 
>>> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
>>> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
>>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>>> ---
>>> In my pre-push testing I realized ECLAIR allcode reported a violation
>>> related to
>>> the use of fdt_for_each_property_offset. Libfdt is excluded from
>>> analysis but
>>> this does not apply to e.g. macros used in other places.
>>> 
>>> Changes in v2:
>>>  - strip out from series that is ready to be committed
>>>  - deviate 20.7 for libfdt.h. Discussed with Nicole.
>>> 
>>> https://gitlab.com/xen-project/people/morzel/xen/-/pipelines/2484326830
>>> ---
>>>  .../eclair_analysis/ECLAIR/deviations.ecl     |  1 +
>>>  xen/common/device-tree/dt-overlay.c           | 65 
>>> +++++++++++++++++--
>>>  2 files changed, 60 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> index 30c323906924..5f0b73062474 100644
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -631,6 +631,7 @@ not in scope for compliance are allowed, as that 
>>> is
>>> imported code."
>>>  -file_tag+={acpi_cpu_idle, "^xen/arch/x86/acpi/cpu_idle\\.c$"}
>>>  -config=MC3A2.R20.7,reports+={safe,
>>> "any_area(any_loc(file(gnu_efi_include)||any_exp(macro(^NextMemoryDescriptor$))))"}
>>>  -config=MC3A2.R20.7,reports+={safe,
>>> "any_area(any_loc(file(acpi_cpu_idle)))"}
>>> +-config=MC3A2.R20.7,reports+={safe,
>>> "any_area(any_loc(any_exp(file(^xen/include/xen/libfdt/libfdt.h$))))"}
>>>  -doc_end
>>> 
>> 
>> Nit: I think using a file_tag as above is better, but in any case use
>> libfdt\\.h in the regex
> Ok. Provided I will do this on commit, may I convert this as your 
> Rb/Ab?
> 
> ~Michal

Yes, sure

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253