Match nested model keys against a node's own compatible list (fixes #13)

[TheArkadiuszGrzelka]

Problem

renode_model_overlay()'s nested-key match notation (used e.g. by the "st,stm32-ethernet" entry in models.json) only checks the SoC/board root compatible strings returned by get_overlays(). It never looks at the generating node's own compatible property.

This silently mis-resolves any device whose node compat list reuses another SoC family's identifier for a shared IP block. STM32H5's Ethernet MAC is the same Synopsys DWC EQOS IP as STM32H7's, and Zephyr's H5 binding reflects that by listing "st,stm32h7-ethernet" alongside the node's own "st,stm32h5-ethernet" / "st,stm32-ethernet" compat strings. Since the H5 SoC/root compat never contains "st,stm32h7", the nested key in models.json's "st,stm32-ethernet" entry never matched, and every non-H7 STM32 with this Ethernet IP silently fell through to the "_" default model, Network.SynopsysEthernetMAC — the wrong model — with no PHY at all. The platform loads fine; the guest simply never gets a link.

Reported as #13.

Fix

Match nested keys against the generating node's own compatible list too, in addition to the SoC/root overlays. compatible/compats was already in scope at every renode_model_overlay() call site, so this only threads it through as an extra parameter — no call site had to look anything up that it didn't already have.

Blast radius

I enumerated every nested-key entry in models.json (all entries whose value is a dict keyed by compat-substrings rather than type/irq_mappings) and checked whether the node-own-compat lookup could flip resolution for anything besides Ethernet. The only way this fix changes behavior is if a node's own compatible list contains a nested-key substring that the SoC/root overlay does not already contain — i.e. the "borrowed cross-family IP" pattern Ethernet exhibits. I did not find that pattern anywhere else that I could check.

I then validated this empirically instead of just by inspection: I generated .repl files for every .dts in the current production zephyr_sim dashboard replkit (17436 board/sample combinations) with and without this patch and diffed all pairs.

• 145 files differ, across exactly 5 boards: nucleo_h563zi, stm32h573i_dk, stm32h5f5j_dk (H5), stm32n6570_dk/nucleo_n657x0 (N6), stm32mp135f_dk (MP1) — all STM32 families that share this Ethernet IP.
• Every diff is the same one-line change in the expected direction: Network.SynopsysEthernetMAC → Network.SynopsysDWCEthernetQualityOfService plus its MTL/DMA BusMultiRegistration regions and systemClockFrequency: 50000000 (already the correct config declared for st,stm32h7 in models.json — only the resolution was broken).
• Zero other differences anywhere in the corpus.
• The current dashboard baseline itself already ships Network.SynopsysEthernetMAC for all 5 of these boards, confirming this is a live, currently-shipping defect, not a hypothetical one.

Testing

• python3 -m py_compile dts2repl/dts2repl.py
• Ran the generate+diff portion of the .ci.yml "compare repls" job manually against the real zephyr_sim dashboard replkit (see above) — this is the part of that job that does not require building/downloading Renode.
• I did not run the Renode-based renode-test .../load_repls_with_diffs.robot re-verification step that job runs when diffs are found (needs a full Renode + dotnet-sdk-8.0 build, out of scope for what I could stand up here). Flagging this explicitly rather than implying coverage I don't have.
• Also spot-checked the unrelated 96b_aerocore2-hello_world sample from the CI's own smoke test path: output is byte-identical before/after this patch (the one diff line versus the dashboard reference there is pre-existing systickFrequency drift, unrelated to this change).
• No physical hardware was used or needed — dts2repl is a pure source-to-source translator and this is fully testable in software.

Related: I also looked at #12 (st,stm32-fdcan has no models.json entry at all) but concluded it needs actual code (to synthesize a sized messageRam child object from bosch,mram-cfg), which a declarative models.json entry cannot express, so I'm not including it here.