Fix Ghost Nodes On Certain Node Orientation

[matt001k]

What changed?

If multiple link events occur at the same time,
handle them both individually,
rather than one or the other.

How does it make Bristlemouth better?

When node orientation is as follows, ADIN2111 port 2 downstream (towards the anchor) and port 1 is upstream (toward a sofar buoy), downstream nodes in a Bristlemouth network inconsistently appear properly in network topology and communicate on the network.

Why might this be happening in the first place?
During the link change callback registered to the driver (this is called when a link change event is detected), it only checks to see if one port or the other port has a link change event. Below is a snippet of that code:

static void link_change_callback_(void *device_handle, uint32_t event,
                                  void *status_registers_param) {
  (void)event;

  if (NETWORK_DEVICE.callbacks->link_change) {
    const adi_mac_StatusRegisters_t *status_registers =
        (adi_mac_StatusRegisters_t *)status_registers_param;

    if (status_registers->p1StatusMasked == ADI_PHY_EVT_LINK_STAT_CHANGE) {
      LINK_CHANGE.port_index = ADIN2111_PORT_1;
      LINK_CHANGE.device_handle = device_handle;
    } else if (status_registers->p2StatusMasked ==
               ADI_PHY_EVT_LINK_STAT_CHANGE) {
      LINK_CHANGE.port_index = ADIN2111_PORT_2;
      LINK_CHANGE.device_handle = device_handle;
    }
  }
}

Evaluating a weekend soak with a network in this improper orientation, port 2 facing Spotter, the first two nodes will always show up at the beginning of a sample interval, but every now and again only the first two show up.
Below is an example of that:

2025-07-25T14:59:06.359Z [BRIDGE_CFG] [INFO] Bridge topology in topology sampler:
2025-07-25T14:59:06.363Z [BRIDGE_CFG] [INFO] 5428d5d73b4e298a
2025-07-25T14:59:06.363Z [BRIDGE_CFG] [INFO] d9188504eff10d72
2025-07-25T14:59:06.367Z [BRIDGE_CFG] [INFO] 9d24ede22a7e7413
2025-07-25T15:00:06.378Z [BRIDGE_CFG] [INFO] Bridge topology in topology sampler:
2025-07-25T15:00:06.382Z [BRIDGE_CFG] [INFO] 5428d5d73b4e298a
2025-07-25T15:00:06.382Z [BRIDGE_CFG] [INFO] d9188504eff10d72
2025-07-25T15:00:06.394Z [BRIDGE_CFG] [INFO] Network configuration change detected! crc: 0x7df7e456 at UTC:1753455605
2025-07-25T15:00:06.398Z [BRIDGE_CFG] [INFO] Stored CRCs: 
0x7df7e456
0xbb048905
0x6fabc453
0xaf198780
0xfce28a2c
0x4875872d
0x5ff11913
0x6035f3eb
0x51e9cdce

Source: SPOT-ZACDEV_07282025/0002_BRIDGE_CFG.log

By changing this callback function to handle the link events if they happen at the same time, the device can now pass this information properly to L2:

static void link_change_callback_(void *device_handle, uint32_t event,
                                  void *status_registers_param) {
  (void)event;

  if (NETWORK_DEVICE.callbacks->link_change) {
    const adi_mac_StatusRegisters_t *status_registers =
        (adi_mac_StatusRegisters_t *)status_registers_param;

    if (status_registers->p1StatusMasked == ADI_PHY_EVT_LINK_STAT_CHANGE) {
      LINK_CHANGE.port_mask |= 1 << ADIN2111_PORT_1;
      LINK_CHANGE.device_handle = device_handle;
    }
    if (status_registers->p2StatusMasked == ADI_PHY_EVT_LINK_STAT_CHANGE) {
      LINK_CHANGE.port_mask |= 1 << ADIN2111_PORT_2;
      LINK_CHANGE.device_handle = device_handle;
    }
  }
}

I left a unit soaking for about 20 hours and did not experience any missing nodes with a 5 minute sample interval.
Below is the file I utilized to validate this:
0001_BRIDGE_CFG.log
SPOT-MJK_07302025.zip

Where should reviewers focus?

All changes are in bm_adin2111.c...

Checklist

• Add or update unit tests for changed code
• Ensure all submodules up to date. If this PR relies on changes in submodules, merge those PRs first, then point this PR at/after the merge commit
• Ensure code is formatted correctly with clang-format. If there are large formatting changes, they should happen in a separate whitespace-only commit on this PR after all approvals.

[towynlin]

Bravo!