xPhyCheckLinkStatus Triggering Re-Autonegotiations When Not All Ports Are Connected

I’ve been having issues with the phyHandling triggering unneeded autonegotiation restart. I wanted to check the code I think is the problem and see that I’m not missing something obvious.

I’m running a board with 4 external ports on the switch, but must be able to operate with only one of them connected to an external device (the other 3 ports will not have a link established). This seems to run afoul of the xPhyCheckLinkStatus()'s logic for triggering a recheck (or re-autonegotiation) when xHadReception > 0

for( xPhyIndex = 0; xPhyIndex < pxPhyObject->xPortCount; xPhyIndex++, ulBitMask <<= 1 )
{
    if( ( pxPhyObject->ulLinkStatusMask & ulBitMask ) == 0UL )
    {
        pxPhyObject->ulLinkStatusMask |= ulBitMask;
        FreeRTOS_printf( ( "xPhyCheckLinkStatus: PHY LS now %02lX\n", pxPhyObject->ulLinkStatusMask ) );
        xNeedCheck = pdTRUE;
    }
}

The code seems to be iterating over the 4 physical ports and checking if any bit in the pxPhyObject->ulLinkStatusMask is low (meaning the link is not established or autonegotiated). And forcing a recheck if any link is down. In my case of 1 port connected and 3 not connected, this always forces recheck as 3 of my links will never successfully autonegotiate.

I do see a latching effect of this if pxPhyObject->ulLinkStatusMask is not cleared (so it will only trigger a recheck once, then stay latched up). But I think that may be an integration error on my part of not clearing the link status mask on autonegotiation. For my current uses I’ve simply deleted this for loop and it clearly takes a long time to detect a link has gone down (as expected).

Am I right in my understanding of this code? It seems odd to me the phyHandling assumes all ports of the switch will be connected at all times!

phyHandling is a pretty good and valuable reference implementation which has to rely on certain assumptions.
So the assumption that all ethernet ports are connected to something is fine for many use cases (I bet most have just 1 PHY) and not applicable for others. Feel free to tailor it to your needs or roll your own (as I did).
It’s not too complicated and the interface is small.

Thanks Hartmut, I’m relatively new to embedded ethernet so I didn’t realize that multiple ports would be out of norm!

I’ll modify it for my needs then.