[arthokal]

Issue:
drop_unreachable_pl_nodes() dropped every PL child whose first reg base was absent from the target cluster's address-map. This is correct for peripherals wired exclusively to another cluster, but it also dropped nodes whose addresses fall within a reg range of a sibling that the target cluster can reach.

Fix:
Collect all reg ranges from nodes whose first base is reachable by the target cluster. Before dropping a node, check whether its base falls within any of those ranges. If it does, keep the node, its address is covered by a device the cluster can already access.
Nodes that are genuinely unreachable (mapped only by other clusters and not covered by any reachable sibling range) are still excluded as before.

[arthokal]

@onkarharsh , please review.

[onkarharsh]

Looks good to me. Fixes the regression issue created with the first patch.

[zeddii]

There is a behaviour change in here that the title does not cover, and I would
like to know whether it is deliberate.

accessible_by() returns an empty list when no cluster can reach the address
at all. The old test was

if cpu_cluster not in sdt.tree.accessible_by(base):
    ... drop

so a node that nothing could reach failed that test and was dropped, with the
warning. The new form splits it into

if cpu_cluster in reachable_by:        # keep, and record its ranges
elif reachable_by:                     # drop candidate

and a node whose reachable_by is empty now matches neither branch. It is kept,
and nothing is said about it.

If that is part of what you are fixing from b224d46 -- a PL node that no
address-map entry mentions at all should stay rather than being excluded --
then the outcome is right, but it is a separate rule from "within reachable
sibling reg ranges" and it would be worth a line in the commit message. If it
is a side effect of the restructuring, it wants an else that drops as before.

Smaller thing, take it or leave it. The containment test looks at the candidate's
base only

if any(rb <= base < rb + rs for rb, rs in reachable_ranges)

so a node starting inside a reachable sibling's range but extending past the end
of it is kept in full. That is probably what you want here, I am noting it in
case you meant containment rather than the start landing inside.

[arthokal]

Hi @zeddii ,

Thank you for reviewing.

a PL node that no
address-map entry mentions at all should stay rather than being excluded --
then the outcome is right, but it is a separate rule from "within reachable
sibling reg ranges" and it would be worth a line in the commit message.

A node that nothing could reach is kept and I added this point in latest commit description.

so a node starting inside a reachable sibling's range but extending past the end
of it is kept in full

Acknowledged. The current check is sufficient for the known use cases. Keeping it as-is for now.

[zeddii]

Thanks for the answers. merging!