Add Versal SysMon support

[dileepkumarnagavarapu]

This patch series adds support for AMD/Xilinx Versal SysMon in Lopper.

The first patch updates the Zephyr supported compatibility list to
include the "xlnx,versal-sysmon" compatible entry, allowing proper
recognition of the SysMon node during device tree processing.

The second patch extends the gen_domain_dts assist script to handle
Versal SysMon nodes and generate appropriate domain-specific DTS
entries.

Tested on the vck190 platform with Lopper-generated dts

[zeddii]

Thanks for the patch. The zephyr_supported_comp.yaml half is the right mechanism:
the required: list feeds delete_unused_props() as a keep-list, so adding
xlnx,versal-sysmon there is what strips the sixty-odd xlnx,sat-* properties off
the node. That part looks good to me.

I ran the suites locally against this branch and they are clean: 1099 passed / 4
skipped under pytest, and 124 passed / 0 failed in the sanity suite. AI assisted with
the digging below, I checked the results.

One question on the xlnx,numchannels normalization. The comment says the SDT may
encode it as /bits/ 8, but that is the case that gets skipped. propval() returns
the empty-string sentinel for a zero-valued byte array, so it is indistinguishable
from the property being absent:

xlnx,numchannels = [00];     propval -> ['']    guard is False, skipped
xlnx,numchannels = [0a];     propval -> [10]    normalized
xlnx,numchannels = <0x0>;    propval -> [0]     normalized
(property absent)            propval -> ['']    guard is False

Every sysmon node in device-trees/system-device-tree-versal-vck190.dts is
xlnx,numchannels = [00], so on vck190 the normalization never fires and the property
is emitted as a one-byte array rather than a four-byte cell. If your Zephyr consumer
reads it as a u32 that may not parse the way you expect. You report it tested and
working on vck190, so I may be missing something, but the code reads as though it
intends to normalize that case and currently does not.

Second thing, more about future-proofing than a defect. The vck190 sysmon nodes have
no child nodes, and xlnx,aie-temp does not appear in any SDT in the repo, so the
child-rewriting and the AIE-temp removal are not exercised by anything in tree. That
makes them easy to break later without noticing. Two spots I would look at while
adding coverage:

• int(reg_val[0]) is not guarded, so a string-encoded reg raises ValueError
  rather than being skipped, unlike the numchannels path above.
• child.name = rail_name takes the node name straight from xlnx,name. Nothing
  checks it for characters that are not legal in a node name, or for two children
  resolving to the same name.

A unit test in tests/ building a small sysmon node with a couple of supply children
and an AIE-temp child would cover all of it and is cheap to write.

[kedareswararao]

@dileepkumarnagavarapu : can you please address the bruce review comments

[zeddii]

Thanks for the updates: three of the four things I raised are fixed.

I checked the things the new code depends on and they're all in place: re, LopperProp and delete_unused_props are imported, and node.delete(child) does remove a child node (I tested that one rather than assume it), since LopperNode.delete is documented for properties.

Three small things inline, all in the new code.

On the test: I still think this should have one, and unlike some other assists the scaffolding already exists here. tests/test_xlnx_gen_domain.py has the pattern: build a tree, wrap it in SimpleNamespace(tree=tree, outdir=...), call the generator. pull request #824 add two tests in that file this week doing exactly that. A sysmon node with two supply children and one xlnx,aie-temp child would cover the count, the AIE drop, the rename and the collision path in one go. That is the whole of this change, and none of it is exercised by anything in the tree today.

[zeddii]

The unnamed fallback gives the node a unit address while reg has just been removed on line 781 and replaced with xlnx,register. So the output carries supply@10 { xlnx,register = <0x10>; ... } — a unit address with no reg property, which is the case dtc flags as unit_address_vs_reg ("node has a unit name, but no reg or ranges property").

The named branch above gets this right by accident of naming: VCC_SOC has no @, and no reg, so it's consistent. It's only the fallback that ends up mismatched.

f"supply_{reg_val}" for both the node name and xlnx,name would keep the two branches consistent with each other and quiet the warning ... you already use that exact form for the property on the next line.

[zeddii]

used_names.add() sits inside the if reg_val ... block, so a supply child that has no reg (or whose reg failed the int() conversion and hit the continue on line 780) never registers its name.

That child also keeps its original SDT name, since the rename is in the same block. If that original name happens to match a rail name generated later in the loop, the collision check on line 788 won't see it and you get two siblings with the same node name.

Narrow, and it needs a malformed SDT to reach. Registering every child's final name, rather than only the renamed ones, would close it.

[zeddii]

This runs for every non-AIE child, including ones that took the continue on line 780 or never entered the if reg_val block at all. Those children never had xlnx,register created, so the keep-list strips them down to xlnx,name alone.

A supply child with nothing but a name is unlikely to be useful to the Zephyr driver, and it's silent ... the node stays in the output looking plausible. Either the reg-less case is worth skipping outright, or it's worth a warning, since reaching it means the SDT wasn't what this code expects.