Ethernet problems with ax88796

    Hi,


    I have some problems with PICOMOD7A ax88796 ethernet controller. We have one site installation where PICOMOD7A connected to site router shows these messages:



    [ 37.734816] PHY: ax88796-0:10 - Link is Down
    [ 39.749825] PHY: ax88796-0:10 - Link is Up - 100/Full
    [ 41.764837] PHY: ax88796-0:10 - Link is Down
    [ 44.779840] PHY: ax88796-0:10 - Link is Up - 100/Full
    [ 48.789805] PHY: ax88796-0:10 - Link is Down
    [ 54.804854] PHY: ax88796-0:10 - Link is Up - 100/Full
    [ 66.814861] PHY: ax88796-0:10 - Link is Down
    [ 70.829943] PHY: ax88796-0:10 - Link is Up - 100/Full
    [ 72.839903] PHY: ax88796-0:10 - Link is Down
    [ 73.854831] PHY: ax88796-0:10 - Link is Up - 100/Full
    [ 77.864861] PHY: ax88796-0:10 - Link is Down


    After a certain period of time, retries cease and, of course, ethernet communications are impossible.


    We have tried various boards to test if ti's a matter of a HW failure, but it is not. however, all tested boards connect correctly to a PC with direct crossed cable o in our corporate network.


    Also, comms are running OK against the mentioned router with another ethernet link we have installed in our board (a DAVICOM DM9010 industrial type) connected to FS expansion bus.


    Any idea of what can be happenning?


    Best regards,

    As we have found out, this problem only happens when connecting to a 10 MBit Hub. The AX88796 is an ethernet controller with integrated MAC and PHY. When the PHY connects to a link, it performs Autonegotiation to test what capabilities the remote peer has. These remote capabilities are stored in a PHY register, let's call it the "remote capabilities register". A second register holds the capabilities of the AX88796 itself. When Linux detects a new link, it performs a logical AND of these two register values and assumes that the link was established with these settings that represent the maximum capabilities that both sides support.


    This seems to work correctly, when used with 100 MBit or GBit switches. When exchanging the cable between two such switches that advertise different capablities, the remote capabilities register is updated accordingly. But when the cable is inserted back into the 10 MBit Hub, the remote capabilities register is *not* updated. Probably the Hub does not support autonegotiation at all. But then the PHY should reset the register to zero in this case. But it does not. This is why Linux assumes the wrong connection type. It just sees the old capabilities of the previous remote peer in this register and tries to connect with 100 MBit/Full.


    The first connection to the 10 MBit hub after the system is booted succeeds because at boot time, the PHY is reset, which clears the remote capabilities register. Then a 10 MBit/Half connection will be assumed and is correctly established.


    The applied patch solves this problem. Everytime when the link goes down, for example when the cable is unplugged, the PHY is reset now. This clears the remote capabilities register. And when you plug the cable into a new device, the link will come up correctly again.


    Go to the top directory of the kernel source and apply the patch with the following command:


    Code
    1. patch -p 1 < 0001-Fix-AX88796-ethernet-link-handling-on-fss5pv210.patch


    Please note the '<' for the input redirection. Then rebuild the kernel.


    Your F&S Support Team